Perché devo inserire "do" nella stessa riga di "for"?

1. Riepilogo

Non capisco, perché ho bisogno della regola E010 bashate .

2. Dettagli

Uso bashate per i .shfile di sfilacciatura . Regola E010:

fare non sulla stessa linea per

for bashate:

• Corretta:

  #!/bin/bash
  for f in bash/*.sh; do
      sashacommand "$f"
  done
  

• Errore:

  #!/bin/bash
  for f in bash/*.sh
      do sashacommand "$f"
  done
  

C'è qualche argomento valido, perché ho bisogno fore donella stessa linea?

3. Non utile

Non riesco a trovare una risposta alla mia domanda in:

1. Google
2. Articoli sulle migliori pratiche di codifica ( esempio )

3. documentazione di base . Trovo solo :

   Un insieme di regole che aiutano a mantenere le cose coerenti nei blocchi di controllo. Questi sono ignorati su lunghe file che hanno una continuazione, perché srotolarsi è un po '"interessante"

Sintatticamente, i seguenti due frammenti di codice sono corretti ed equivalenti:

for f in bash/*.sh; do
    sashacommand "$f"
done

for f in bash/*.sh
    do sashacommand "$f"
done

Si potrebbe forse dire che quest'ultimo è più difficile da leggere poiché dooffusca leggermente il comando nel corpo del loop. Se il ciclo contiene più comandi e il comando successivo si trova su una nuova riga, l'offuscamento sarebbe ulteriormente evidenziato:

for f in *
    do cmd1
    cmd2
done

... ma segnalarlo come un "errore" è l'opinione personale di IMHO piuttosto che una verità oggettiva.

In generale, quasi tutti ;possono essere sostituiti da una nuova riga. Entrambi ;e newline sono terminatori di comando. doè una parola chiave che significa "qui segue ciò che deve essere fatto (in questo forciclo)".

for f in *; do ...; done

equivale a

for f in *
do
   ...
done

e come

for f in *; do
   ...
done

Il motivo per utilizzare l'uno sull'altro è la leggibilità e le convenzioni di stile locale / personale.

Opinione personale:

Nelle intestazioni di loop che sono molto lunghe , penso che potrebbe avere senso mettere dosu una nuova linea, come in

for i in animals people houses thoughts basketballs bees
do
    ...
done

o

for i in        \
    animals     \
    people      \
    houses      \
    thoughts    \
    basketballs \
    bees
do
    ...
done

Lo stesso vale per l' thenin un ifcomunicato.

Ma di nuovo, ciò dipende dalle preferenze di stile personali o dallo stile di codifica utilizzato dal proprio team / progetto.

Nota cosa dice nella parte superiore della pagina:

bashate: un equivalente pep8 per gli script bash

PEP8 è la guida di stile per Python Code. Mentre le persone di Python sembrano spesso prendere molto sul serio i loro problemi di stile ^{[citazione necessaria]} , è proprio questo, una guida. Potremmo trovare degli aspetti positivi sia per mettere la dostessa linea che per quella fore per metterla su una linea a sé stante.

E 'la stessa discussione come dove mettere il {nel codice C all'avvio di ifo whileblocco (o simili).

Alcune righe di seguito nella documentazione, c'è un'altra regola interessante:

E020: Dichiarazione di funzione non in formato ^function name {$

Suppongo che il punto qui sia che l'autore di quella guida di stile pensi che l'uso della functionparola chiave sia necessario affinché il lettore riconosca una dichiarazione di funzione. Tuttavia, function fooè un modo non standard di definire una funzione: il modo standard è foo(). L'unica differenza tra i due (in Bash) è che l'altro è più difficile da portare su una shell standard, come /bin/shin Debian o Ubuntu.

Quindi, suggerirei di prendere tutte le guide di stile con un granello di sale o tre e decidere di persona quale sia lo stile migliore. Un buon controllo di stile consente di disabilitare alcuni controlli (bashate deve bashate -i E010,E011ignorare quei due controlli.) Un eccellente controllo di stile consentirebbe di modificare i test, ad esempio per verificare il contrario di E020, qui.

TL; DR: non è necessario. È solo l'opinione di un tizio.

Come molti altri, ho scritto forcicli come questo per decenni:

for F in arg1 arg2 arg*
do
    somecommand "$F"
done

Questo layout evidenzia il fatto che do ... donecirconda il corpo del loop, come parentesi graffe in linguaggi di tipo C, e consente alle nuove linee di separare i componenti del costrutto loop.

Naturalmente ci sono guerre di religione su dove posizionare anche le parentesi graffe, quindi potresti dire che la giuria è ancora fuori su questo. IMHO, questo è chiaramente il modo in cui è stato progettato per funzionare; Bourne amava i delimitatori abbinati, cfr. if ... fi, case ... esace la necessità di un punto e virgola nella versione più breve rivela che lo stai rendendo più corto di quanto originariamente progettato. Niente di sbagliato in questo; i progressi della tecnologia e un sacco di cose che una volta sembravano una buona idea sono ora disapprovate, come goto. Ma fino a quando l'intera comunità di shell-scripting non adotta le preferenze degli bashateautori, non devi fare nulla.

Sono sorpreso che nessuno abbia ancora menzionato questa sintassi valida e portatile:

set alfa bravo charlie
for q do
  echo "$q"
done

Notare attentamente che fore dosono sulla stessa riga, senza punto e virgola. Risultato:

alfa
bravo
charlie

Diverse buone risposte qui. Prendi sempre le guide di stile con un pizzico di sale, e IMHO ed esperienza, sii sempre così leggermente o moderatamente preoccupato per qualsiasi comunità che è piena di dogma eccessivo quando si tratta di stile. È quasi come se credessero che quando FINALMENTE avessero ottenuto l'ultimo punto punteggiato e quell'ultima T incrociata, il software funzionerà. A volte ci vuole più dello stile perfetto per rimuovere i bug ...

Quando ho iniziato a studiare shell, la maggior parte degli script e dei tutor disponibili utilizzava il formato punto e virgola in linea

for i in "$@"; do
    stuff
done

ma poiché ero inesperto, ho avuto un po 'di fatica a individuare; e fare - entrambi essenziali per confermare la correttezza sintattica. Quindi ho preferito il do sulla riga successiva da solo. Non lo faccio più (gioco di parole previsto)

Inoltre, il comando 'while' è un ottimo candidato per un piccolo trucco:

while prep1; prep2; condition; do
    stuff
done

ma quando i comandi di preparazione sono un po 'ingombranti e / o la condizione è complessa, è meglio formattata come

while
    prep1
    prep2
    condition
do
    stuff
done

e quindi aggiungere do come "; do" è decisamente fugace.

Puoi anche diventare più intenso di così:

while
    if con1; then
      cond2
    elif cond3; then
      cond4
    elif cond5; then
      cond6
    else
      cond7
    fi
do
    stuff
done

perché ogni affermazione è un'espressione. Notare come entrambi gli stili sono usati opportunisticamente. Tienilo pulito ed è abbastanza leggibile. Compattalo o contorcilo nel nome dello stile o "risparmiando spazio" e diventa un casino orribile.

Così! Dati gli stili piuttosto barocchi degli script di shell in generale, tutto ciò che mira ad aumentare la chiarezza e un facile accesso visivo a simboli significativi è sempre una buona cosa.

La forma in cui 'do' è scritta in linea con il comando è dolce quando hai un piccolo comando - Non trovo il 'do' visivamente nascosto, né il comando interno è davvero oscurato:

for i in whatever
  do stuff
done

Lo trovo abbastanza piacevole da guardare, e ha analoghi con while, if e case:

while condition
  do stuff
end

if condition
  then stuff1
  else stuff2
fi

case $blah in
  a) stuff1;;
  b) stuff2;;
  c) stuff3;;
  *) stuffInfinity;;
esac

Chiarezza e ordine generale sono tutto ciò che Codd * ti chiede.

* Edgar F. Codd, padre della teoria dei database relazionali.