Por que preciso colocar “do” na mesma linha que “for”?

Sintaticamente, os dois trechos de código a seguir são corretos e equivalentes:

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

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

Pode-se dizer que o último é mais difícil de ler, pois doofusca ligeiramente o comando no corpo do loop. Se o loop contiver vários comandos e o próximo comando estiver em uma nova linha, a ofuscação será ainda mais destacada:

for f in *
    do cmd1
    cmd2
done

... mas sinalizá-lo como um "erro" é IMHO a opinião pessoal de alguém, e não uma verdade objetiva.

Eu diria que se você quiser preceder o comando no loop com do, sinta-se à vontade para fazê-lo se isso tornar o código consistente e legível aos olhos de quem estiver lendo o código.

Em geral, quase qualquer um ;pode ser substituído por uma nova linha. Ambos ;e nova linha são terminadores de comando. doé uma palavra-chave que significa "aqui segue o que precisa ser feito (neste forloop)".

for f in *; do ...; done

é o mesmo que

for f in *
do
   ...
done

e como

for f in *; do
   ...
done

e

for f in *
   do ...
done

A razão para usar um sobre o outro é a legibilidade e as convenções de estilo locais/pessoais.

Opinião pessoal:

Em cabeçalhos de loop muito longos , acho que pode fazer sentido colocar douma nova linha, como em

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

ou

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

O mesmo vale para o thenem uma ifdeclaração.

Mas, novamente, isso se resume às preferências de estilo pessoal ou a qualquer estilo de codificação que a equipe/projeto esteja usando.

Observe o que diz no topo da página:

bashate: Um equivalente pep8 para scripts bash

PEP8 é o Guia de Estilo para Código Python. Embora o pessoal do Python geralmente pareça levar seus problemas de estilo muito a sério ^{[citação necessária]} , é apenas isso, um guia. Poderíamos apresentar vantagens tanto para colocar o dona mesma linha que o for, quanto para colocá-lo em uma linha própria.

É a mesma discussão de onde colocar o {código C ao iniciar um bloco ou (ou algo parecido) if.while

Algumas linhas abaixo na documentação, há outra regra interessante:

E020: Declaração de função fora do formato^function name {$

Presumo que o ponto aqui é que o autor desse guia de estilo pensa que usar a functionpalavra-chave é necessário para que o leitor reconheça uma declaração de função. No entanto, function fooé uma forma não padronizada de definir uma função: a forma padrão é foo(). A única diferença entre os dois (no Bash) é que o outro é mais difícil de portar para um shell padrão, como /bin/shno Debian ou no Ubuntu.

Então, eu sugeriria pegar todos e quaisquer guias de estilo com um grão de sal ou três e decidir por si mesmo qual é o melhor estilo. Um bom verificador de estilo permite desabilitar algumas verificações (bashate tem bashate -i E010,E011que ignorar essas duas verificações). Um excelente verificador de estilo permitiria que você modificasse os testes, por exemplo, para verificar o oposto de E020, aqui.

TL;DR: Você não precisa. É só a opinião de um cara.

Como muitos outros, escrevo forloops como este há décadas:

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

Esse layout destaca o fato de do ... doneenvolver o corpo do loop, como chaves em linguagens semelhantes a C, e permite que novas linhas separem os componentes da construção do loop.

É claro que também existem guerras religiosas sobre onde colocar as chaves, então você pode dizer que o júri ainda não decidiu. IMHO, é claramente assim que isso foi projetado para funcionar; Bourne gostava de delimitadores combinados, cf. if ... fi, case ... esac, e a necessidade de um ponto e vírgula na versão mais curta revela que você está tornando-a mais curta do que originalmente projetada. Nada de errado com isso; avanços tecnológicos e muitas coisas que antes pareciam uma boa ideia agora são desaprovadas, como goto. Mas até que toda a comunidade de scripts de shell adote as preferências do bashate(s) autor(es), você não precisa fazer nada.

Várias boas respostas aqui. Sempre tome guias de estilo com um pouco de sal, e IMHO e experiência, esteja sempre tão leve a moderadamente preocupado com qualquer comunidade que esteja repleta de dogmas excessivos quando se trata de estilo. É quase como se eles acreditassem que, quando FINALMENTE conseguirem o último ponto pontilhado e o último T cruzado, o software funcionará. Às vezes é preciso mais do que um estilo perfeito para remover bugs...

Quando comecei a aprender shell, a maioria dos scripts e tutes usavam o formato de ponto e vírgula in-line

for i in "$@"; do
    stuff
done

mas como eu era inexperiente, tive um pouco de dificuldade em identificar o ; e fazer - ambos essenciais para confirmar a correção sintática. Então eu preferi o do na próxima linha sozinho. Eu não faço mais isso (trocadilho intencional)

Além disso, o comando 'while' é um excelente candidato para um pequeno truque:

while prep1; prep2; condition; do
    stuff
done

mas quando os comandos prep são um pouco volumosos e/ou a condição é complexa, é melhor formatá-los como

while
    prep1
    prep2
    condition
do
    stuff
done

e, em seguida, anexar o do como "; do" é positivamente fútil.

Você pode até ficar mais intenso do que isso:

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

porque cada declaração é uma expressão. Observe como ambos os estilos são usados ​​de forma oportunista. Mantenha-o limpo e é bastante legível. Compacte ou contorça em nome do estilo ou "economize espaço" e torna-se uma bagunça horrível.

Então! Dado o estilo bastante barroco dos scripts de shell em geral, qualquer coisa destinada a aumentar a clareza e facilitar o acesso visual a símbolos significativos é sempre uma coisa boa.

A forma em que 'do' é escrito em linha com o comando é agradável quando você tem um pequeno comando - não acho o 'do' visualmente oculto, nem o comando interno é realmente obscurecido:

for i in whatever
  do stuff
done

Acho isso bastante agradável de se ver e tem análogos com 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

Clareza e organização geral é tudo o que Codd* pede de você.

*Edgar F. Codd, pai da teoria de banco de dados relacional.

Estou surpreso que ninguém tenha mencionado essa sintaxe válida e portátil ainda:

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

Observe cuidadosamente que fore doestão na mesma linha, sem ponto e vírgula. Resultado:

alfa
bravo
charlie