Qual é o propósito de um comando que não faz nada, sendo pouco mais que um líder de comentários, mas na verdade é um shell embutido em si mesmo?

É mais lento do que inserir um comentário em seus scripts em cerca de 40% por chamada, o que provavelmente varia muito, dependendo do tamanho do comentário. As únicas razões possíveis que posso ver são:

# poor man's delay function
for ((x=0;x<100000;++x)) ; do : ; done

# inserting comments into string of commands
command ; command ; : we need a comment in here for some reason ; command

# an alias for `true' (lazy programming)
while : ; do command ; done

Acho que o que realmente estou procurando é qual aplicativo histórico ele poderia ter.

Historicamente , os reservatórios Bourne não tinham truee falsecomo comandos embutidos. trueera simplesmente um alias para :, e falsepara algo parecido let 0.

:é ligeiramente melhor do que truea portabilidade para conchas antigas derivadas de Bourne. Como um exemplo simples, considere não ter o !operador de pipeline nem o ||operador de lista (como foi o caso de algumas conchas Bourne antigas). Isso deixa a elsecláusula da ifdeclaração como o único meio de ramificação com base no status de saída:

if command; then :; else ...; fi

Como ifrequer uma thencláusula não vazia e os comentários não contam como não vazios, :serve como não operacional.

Hoje em dia (ou seja: em um contexto moderno), geralmente você pode usar um :ou outro true. Ambos são especificados pelo POSIX, e alguns acham truemais fácil de ler. No entanto, há uma diferença interessante: :é o chamado embutido especial POSIX , enquanto o embutidotrue é regular .

• É necessário que os embutidos especiais sejam incorporados ao shell; Os embutidos regulares são apenas "tipicamente" embutidos, mas não são estritamente garantidos. Normalmente, não deve haver um programa regular nomeado :com a função truePATH na maioria dos sistemas.

• Provavelmente a diferença mais crucial é que, com embutidos especiais, qualquer variável definida pelo embutido - mesmo no ambiente durante uma simples avaliação de comando - persiste após a conclusão do comando, conforme demonstrado aqui usando o ksh93:

  $ unset x; ( x=hi :; echo "$x" )
  hi
  $ ( x=hi true; echo "$x" )
  
  $

  Observe que o Zsh ignora esse requisito, assim como o GNU Bash, exceto quando opera no modo de compatibilidade com POSIX, mas todos os outros shells principais "derivados do POSIX sh" observam isso, incluindo dash, ksh93 e mksh.

• Outra diferença é que os embutidos regulares devem ser compatíveis com exec- demonstrado aqui usando o Bash:

  $ ( exec : )
  -bash: exec: :: not found
  $ ( exec true )
  $

• O POSIX também observa explicitamente que :pode ser mais rápido que true, embora esse seja, obviamente, um detalhe específico da implementação.

Eu o uso para ativar / desativar facilmente comandos variáveis:

#!/bin/bash
if [[ "$VERBOSE" == "" || "$VERBOSE" == "0" ]]; then
    vecho=":"     # no "verbose echo"
else
    vecho=echo    # enable "verbose echo"
fi

$vecho "Verbose echo is ON"

portanto

$ ./vecho
$ VERBOSE=1 ./vecho
Verbose echo is ON

Isso cria um script limpo. Isso não pode ser feito com '#'.

Além disso,

: >afile

é uma das maneiras mais simples de garantir que 'afile' exista, mas tenha 0 comprimento.

Uma aplicação útil para: é se você estiver interessado apenas em usar expansões de parâmetro para seus efeitos colaterais, em vez de realmente transmitir o resultado para um comando. Nesse caso, você usa o PE como argumento para: ou false, dependendo se você deseja um status de saída de 0 ou 1. Um exemplo pode ser : "${var:=$1}". Como :é um builtin, deve ser bem rápido.

:também pode ser para comentários em bloco (semelhante a / * * / no idioma C). Por exemplo, se você quiser pular um bloco de código no seu script, poderá fazer o seguinte:

: << 'SKIP'

your code block here

SKIP

Se você deseja truncar um arquivo para zero bytes, útil para limpar logs, tente o seguinte:

:> file.log

É semelhante ao passPython.

Um uso seria remover uma função até que ela seja gravada:

future_function () { :; }

Mais dois usos não mencionados em outras respostas:

Exploração madeireira

Veja este script de exemplo:

set -x
: Logging message here
example_command

A primeira linha set -x,, faz com que o shell imprima o comando antes de executá-lo. É uma construção bastante útil. A desvantagem é que o echo Log messagetipo usual de instrução agora imprime a mensagem duas vezes. O método do cólon contorna isso. Observe que você ainda terá que escapar de caracteres especiais como faria echo.

Cargos Cron

Eu já vi isso sendo usado em tarefas cron, assim:

45 10 * * * : Backup for database ; /opt/backup.sh

Este é um trabalho cron que executa o script /opt/backup.shtodos os dias às 10:45. A vantagem dessa técnica é que ela cria temas de e-mail com melhor aparência quando a /opt/backup.shimpressão é impressa.

Você pode usá-lo em conjunto com backticks ( ``) para executar um comando sem exibir sua saída, assim:

: `some_command`

Claro que você poderia fazer some_command > /dev/null, mas o: versão-é um pouco mais curta.

Dito isto, eu não recomendaria realmente fazer isso, pois apenas confundiria as pessoas. Apenas veio à mente como um possível caso de uso.

Também é útil para programas poliglotas:

#!/usr/bin/env sh
':' //; exec "$(command -v node)" "$0" "$@"
~function(){ ... }

Esta é agora tanto um shell-script executável e um programa JavaScript: o que significa ./filename.js, sh filename.jse node filename.jstodo o trabalho.

(Definitivamente um pouco de uso estranho, mas eficaz, no entanto.)

Alguma explicação, conforme solicitado:

• Os scripts de shell são avaliados linha por linha; e o execcomando, quando executado, finaliza o shell e substitui seu processo pelo comando resultante. Isso significa que, para o shell, o programa fica assim:

  #!/usr/bin/env sh
  ':' //; exec "$(command -v node)" "$0" "$@"

• Desde que não ocorra expansão ou alias de parâmetro na palavra, qualquer palavra em um shell-script pode ser colocada entre aspas sem alterar seu significado; isso significa que ':'é equivalente a :(apenas o colocamos entre aspas aqui para obter a semântica do JavaScript descrita abaixo)

• ... e, como descrito acima, o primeiro comando na primeira linha é um no-op (traduz para : //, ou se você preferir citar as palavras ':' '//',. Observe que o //termo não possui significado especial aqui, como ocorre no JavaScript; é apenas uma palavra sem sentido que está sendo jogada fora.)

• Finalmente, o segundo comando na primeira linha (após o ponto-e-vírgula) é a verdadeira essência do programa: é a execchamada que substitui o shell-script sendo invocado , com um processo Node.js invocado para avaliar o restante do script.

• Enquanto isso, a primeira linha, em JavaScript, analisa como uma string literal ( ':') e, em seguida, um comentário, que é excluído; assim, para JavaScript, o programa fica assim:

  ':'
  ~function(){ ... }

  Como o literal da cadeia de caracteres está em uma linha por si só, é uma instrução no-op e, portanto, é retirada do programa; isso significa que a linha inteira é removida, deixando apenas o código do programa (neste exemplo, o function(){ ... }corpo).

Funções de auto-documentação

Você também pode usar :para incorporar documentação em uma função.

Suponha que você tenha um script de biblioteca mylib.sh, fornecendo uma variedade de funções. Você pode originar a biblioteca ( . mylib.sh) e chamar as funções diretamente depois disso ( lib_function1 arg1 arg2) ou evitar sobrecarregar seu espaço de nome e chamar a biblioteca com um argumento de função (mylib.sh lib_function1 arg1 arg2 ).

Não seria bom se você também pudesse digitar mylib.sh --helpe obter uma lista de funções disponíveis e seu uso, sem precisar atualizar manualmente a lista de funções no texto de ajuda?

#! / bin / bash

# todas as funções "públicas" devem começar com esse prefixo
LIB_PREFIX = 'lib_'

# funções de biblioteca "públicas"
lib_function1 () {
    : Esta função faz algo complicado com dois argumentos.
    :
    : Parâmetros:
    : 'arg1 - primeiro argumento ($ 1)'
    : 'arg2 - segundo argumento'
    :
    : Resultado:
    : " é complicado"

    # código de função real começa aqui
}

lib_function2 () {
    : Documentação de funções

    # código de função aqui
}

# help function
--Socorro() {
    eco MyLib v0.0.1
    eco
    eco Uso: mylib.sh [nome_da_função [args]]
    eco
    eco Funções disponíveis:
    declarar -f | sed -n -e '/ ^' $ LIB_PREFIX '/, / ^} $ / {/ \ (^' $ LIB_PREFIX '\) \ | \ (^ [\ t] *: \) / {
        s / ^ \ ('$ LIB_PREFIX'. * \) () / \ n === \ 1 === /; s / ^ [\ t] *: \? ['\' '"] \? / / ; s / ['\' '"] \?; \? $ //; p}}'
}

# Código principal
if ["$ {BASH_SOURCE [0]}" = "$ {0}"]; então
    # o script foi executado em vez de originado
    # invoca a função solicitada ou exibe ajuda
    if ["$ (digite -t ​​-" $ 1 "2> / dev / null)" = função]; então
        "$ @"
    outro
        --Socorro
    fi
fi

Alguns comentários sobre o código:

1. Todas as funções "públicas" têm o mesmo prefixo. Somente estes devem ser invocados pelo usuário e listados no texto de ajuda.
2. O recurso de auto-documentação baseia-se no ponto anterior e usa declare -fpara enumerar todas as funções disponíveis, depois as filtra através do sed para exibir apenas funções com o prefixo apropriado.
3. É uma boa idéia colocar a documentação entre aspas simples, para evitar expansão indesejada e remoção de espaço em branco. Você também precisará ter cuidado ao usar apóstrofos / aspas no texto.
4. Você pode escrever um código para internalizar o prefixo da biblioteca, ou seja, o usuário só precisa digitar mylib.sh function1e é traduzido internamente para lib_function1. Este é um exercício deixado para o leitor.
5. A função de ajuda é denominada "--help". Essa é uma abordagem conveniente (preguiçosa) que usa o mecanismo de chamada da biblioteca para exibir a ajuda em si, sem a necessidade de codificar uma verificação extra $1. Ao mesmo tempo, o espaço para nome será confuso se você for fonte da biblioteca. Se você não gostar disso, poderá alterar o nome para algo como lib_helpou realmente verificar os argumentos --helpno código principal e chamar a função de ajuda manualmente.

Vi esse uso em um script e pensei que era um bom substituto para invocar o nome de base em um script.

oldIFS=$IFS  
IFS=/  
for basetool in $0 ; do : ; done  
IFS=$oldIFS  

... este é um substituto para o código: basetool=$(basename $0)