Ho cercato noop in bash (:), ma non sono riuscito a trovare nessuna buona informazione. Qual è lo scopo esatto o il caso d'uso di questo operatore?

Ho provato a seguire e funziona così per me:

[mandy@root]$ a=11
[mandy@root]$ b=20
[mandy@root]$ c=30
[mandy@root]$ echo $a; : echo $b ; echo $c
10
30

Per favore fatemi sapere, qualsiasi caso d'uso di questo operatore in tempo reale o qualsiasi luogo in cui sia obbligatorio utilizzarlo.

C'è di più per ragioni storiche. I due punti incorporati :sono esattamente equivalenti a true. È tradizionale da utilizzare truequando il valore restituito è importante, ad esempio in un ciclo infinito:

while true; do
  echo 'Going on forever'
done

È tradizionale da usare :quando la sintassi della shell richiede un comando ma non hai nulla da fare.

while keep_waiting; do
  : # busy-wait
done

Il :builtin risale alla shell Thompson , era presente in Unix v6 . :era un indicatore di etichetta per l' gotoaffermazione della shell Thompson . L'etichetta potrebbe essere qualsiasi testo, quindi :raddoppiata come indicatore di commento (se non c'è goto comment, allora : commentè effettivamente un commento). Il guscio Bourne non aveva gotoma mantenuto :.

Un idioma comune che utilizza :è : ${var=VALUE}, che imposta varsu VALUEse non era impostato e non fa nulla se varera già impostato. Questo costrutto esiste solo nella forma di una sostituzione di variabile, e questa sostituzione di variabile deve in qualche modo far parte di un comando: un comando no-op serve bene.

Vedi anche A cosa serve il colon incorporato? .

Lo uso per le istruzioni if ​​quando commento tutto il codice. Ad esempio hai un test:

if [ "$foo" != "1" ]
then
    echo Success
fi

ma vuoi commentare temporaneamente tutto ciò che è contenuto all'interno:

if [ "$foo" != "1" ]
then
    #echo Success
fi

Che fa sì che bash dia un errore di sintassi:

line 4: syntax error near unexpected token `fi'
line 4: `fi'

Bash non può avere blocchi vuoti (WTF). Quindi aggiungi una no-op:

if [ "$foo" != "1" ]
then
    #echo Success
    :
fi

oppure puoi usare il no-op per commentare le righe:

if [ "$foo" != "1" ]
then
    : echo Success
fi

Se si utilizza, set- eallora || :è un ottimo modo per non uscire dallo script se si verifica un errore (lo fa passare esplicitamente).

Lo useresti :per fornire un comando che ha successo ma non fa nulla. In questo esempio il comando "verbosity" è disattivato per impostazione predefinita, impostandolo su :. L'opzione "v" lo attiva.

#!/bin/sh
# example
verbosity=:                         
while getopts v OPT ; do          
   case $OPT in                  
       v)        
           verbosity=/bin/realpath 
       ;;
       *)
           exit "Cancelled"
       ;;             
   esac                          
done                              

# `$verbosity` always succeeds by default, but does nothing.                              
for i in * ; do                   
  echo $i $($verbosity $i)         
done                              

$ example
   file

$ example -v
   file /home/me/file  

Ignora gli aliasargomenti

A volte vuoi avere un alias che non accetta argomenti. Puoi farlo usando ::

> alias alert_with_args='echo hello there'

> alias alert='echo hello there;:'

> alert_with_args blabla
hello there blabla

> alert blabla
hello there

Un utilizzo è come commenti su più righe o per commentare parte del codice a scopo di test usandolo insieme a un file here.

: << 'EOF'

This part of the script is a commented out

EOF

Non dimenticare di usare le virgolette in EOFmodo che qualsiasi codice all'interno non venga valutato, come $(foo). Inoltre potrebbe essere utile utilizzare un nome di terminazione intuitivo come NOTES, SCRATCHPADo TODO.

Due dei miei.

Incorpora commenti POD

Un'applicazione piuttosto originale di :è per incorporare commenti POD negli script bash , in modo che le pagine man possano essere generate rapidamente. Ovviamente, alla fine si riscriverà l'intera sceneggiatura in Perl ;-)

Associazione di funzioni in fase di esecuzione

Questa è una sorta di modello di codice per l'associazione di funzioni in fase di esecuzione. Fi, hai una funzione di debug per fare qualcosa solo se è impostato un determinato flag:

#!/bin/bash
# noop-demo.sh 
shopt -s expand_aliases

dbg=${DBG:-''}

function _log_dbg {
    echo >&2 "[DBG] $@"
}

log_dbg_hook=':'

[ "$dbg" ] && log_dbg_hook='_log_dbg'

alias log_dbg=$log_dbg_hook


echo "Testing noop alias..."
log_dbg 'foo' 'bar'

Ottieni:

$ ./noop-demo.sh 
Testing noop alias...
$ DBG=1 ./noop-demo.sh 
Testing noop alias...
[DBG] foo bar

A volte le clausole no-op possono rendere il tuo codice più leggibile.

Può essere una questione di opinione, ma ecco un esempio. Supponiamo che tu abbia creato una funzione che funziona prendendo due percorsi unix. Calcola il "percorso di modifica" necessario per passare da un percorso all'altro. Metti una restrizione sulla tua funzione in base alla quale i percorsi devono iniziare entrambi con una "/" OPPURE entrambi non devono.

function chgpath() {
    # toC, fromC are the first characters of the argument paths.
    if [[ "$toC" == / && "$fromC" == / ]] || [[ "$toC" != / && "$fromC" != / ]]
    then
        true      # continue with function
    else
        return 1  # Skip function.
    fi

Alcuni sviluppatori vorranno rimuovere il no-op ma ciò significherebbe negare il condizionale:

function chgpath() {
    # toC, fromC are the first characters of the argument paths.
    if [[ "$toC" != / || "$fromC" == / ]] && [[ "$toC" == / || "$fromC" != / ]]
    then
        return 1  # Skip function.
    fi

Ora, a mio parere, non è così chiaro dalla clausola if le condizioni in cui vorresti saltare facendo la funzione. Per eliminare il no-op e farlo chiaramente, dovresti spostare la clausola if dalla funzione:

    if [[ "$toC" == / && "$fromC" == / ]] || [[ "$toC" != / && "$fromC" != / ]]
    then
        cdPath=$(chgPath pathA pathB)   # (we moved the conditional outside)

Sembra migliore, ma molte volte non possiamo farlo; vogliamo che il controllo venga fatto all'interno della funzione.

Quindi quanto spesso accade questo? Non molto spesso. Forse una o due volte all'anno. Succede abbastanza spesso che dovresti esserne consapevole. Non esito a usarlo quando penso che migliori la leggibilità del mio codice (indipendentemente dalla lingua).

In qualche modo correlato a questa risposta , trovo questa no-op piuttosto conveniente per hackerare gli script poliglotti . Ad esempio, ecco un commento valido sia per bash che per vimscript:

":" #    this is a comment
":" #    in bash, ‘:’ is a no-op and ‘#’ starts a comment line
":" #    in vimscript, ‘"’ starts a comment line

Certo, potremmo averlo usato truealtrettanto bene, ma :essere un segno di punteggiatura e non una parola inglese irrilevante rende chiaro che si tratta di un segno di sintassi.

Per quanto riguarda il motivo per cui qualcuno dovrebbe fare una cosa così complicata come scrivere uno script poliglotta (oltre ad essere interessante): si rivela utile in situazioni in cui normalmente scriveremmo diversi file di script in diverse lingue, con file che si Xriferiscono a file Y.

In una tale situazione, combinare entrambi gli script in un unico file poliglotta evita qualsiasi lavoro Xper determinare il percorso a Y(è semplicemente "$0"). Ancora più importante, rende più comodo spostarsi o distribuire il programma.

• Un esempio comune. C'è un problema ben noto e di vecchia data con gli shebang: la maggior parte dei sistemi (inclusi Linux e Cygwin) consente il passaggio di un solo argomento all'interprete. La seguente faccenda:

  #!/usr/bin/env interpreter --load-libA --load-libB

  lancerà il seguente comando:

  /usr/bin/env "interpreter --load-libA --load-libB" "/path/to/script"

  e non il previsto:

  /usr/bin/env interpreter --load-libA --load-libB "/path/to/script"

  Quindi, finiresti per scrivere uno script wrapper, come:

  #!/usr/bin/env sh
  /usr/bin/env interpreter --load-libA --load-libB "/path/to/script"

  È qui che entra in scena la poliglossia.

• Un esempio più specifico. Una volta ho scritto uno script bash che, tra le altre cose, ha invocato Vim. Avevo bisogno di dare a Vim una configurazione aggiuntiva, che poteva essere eseguita con l'opzione --cmd "arbitrary vimscript command here". Tuttavia, quella configurazione era sostanziale, quindi incorporarla in una stringa sarebbe stata terribile (se mai possibile). Quindi, una soluzione migliore era scriverlo in extenso in qualche file di configurazione, quindi far leggere quel file a Vim con -S "/path/to/file". Quindi sono finito con un file bash / vimscript poliglotta.

Ho anche usato in esso script per definire le variabili predefinite.

: ${VARIABLE1:=my_default_value}
: ${VARIABLE2:=other_default_value}
call-my-script ${VARIABLE1} ${VARIABLE2}

supponi di avere un comando che desideri concatenare al successo di un altro:

cmd="some command..."
$cmd
[ $? -eq 0 ] && some-other-command

ma ora vuoi eseguire i comandi in modo condizionale e vuoi mostrare i comandi che verrebbero eseguiti (dry run):

cmd="some command..."
[ ! -z "$DEBUG" ] && echo $cmd
[ -z "$NOEXEC" ] && $cmd
[ $? -eq 0 ] && {
    cmd="some-other-command"
    [ ! -z "$DEBUG" ] && echo $cmd
    [ -z "$NOEXEC" ] && $cmd
}

quindi se imposti DEBUG e NOEXEC, il secondo comando non viene mai visualizzato. questo perché il primo comando non viene mai eseguito (perché NOEXEC non è vuoto) ma la valutazione di questo fatto ti lascia con un ritorno di 1, il che significa che il comando subordinato non viene mai eseguito (ma lo vuoi perché è un funzionamento a secco). quindi per risolvere questo problema puoi reimpostare il valore di uscita lasciato nello stack con un noop:

[ -z "$NOEXEC" ] && $cmd || :