Por que o loop for POSIX permite um `for name in ; sintaxe do` (sem palavras na lista)?

É que isso wordlisté definido como:

wordlist         : wordlist WORD
                 |          WORD

Portanto, uma ou mais palavras, mas o for var in ...; do ...; doneloop pode passar por zero ou mais palavras, portanto, precisa For name linebreak in sequential_sep do_groupcobrir o caso de zero palavras .

Tendo wordlistdefinido como zero ou mais palavras :

wordlist         : wordlist WORD
                 | /* empty */

Provavelmente teria sido menos confuso.

Se você olhar para SUSv2 , havia:

 for_clause       : For name linebreak                            do_group
                  | For name linebreak in wordlist sequential_sep do_group

 wordlist         : wordlist WORD
                  |          WORD

Significando que uma lista vazia não era permitida. Parece que o que aconteceu foi que no SUSv3, eles corrigiram essa omissão adicionando:

For name linebreak in sequential_sep do_group

Em vez de mudar a definição de wordlist.

Observe que estamos falando da gramática da linguagem shell aqui, portanto não se trata for i in $var; do ...; donede for i in $(some cmd); do ...; doneonde $var/ $(some cmd)expansões podem resultar em uma lista vazia. Esses são $var, $(some cmd)cada um, um token WORD na formalização POSIX da linguagem shell.

Estamos falando de for i in; do ...; done, onde literalmente não há PALAVRA entre o ine o do.

Concordo que o código não é particularmente útil. Há poucos motivos para escrever um loop que faça um loop explicitamente sobre nada. Algumas razões que se poderia pensar:

Código gerado:

if ...; then
  list=' "foo" "bar baz" "$var" '
else
  list=
fi

eval '
  for i in '"$list"'; do
    printf "%s\n" "$i"
  done
'

Ou qualquer coisa que gere shscripts e construa um forloop sobre argumentos explícitos.

Ou para comentar algum código:

for commented_out in; do
  this code is commented out
done

Embora algo como:

:||:<<'EOF'
  this code is commented out and (harmless) even
  if it contains invalid syntax
EOF

Seria mais idiomático.

Não encontrei a solicitação de mudança que levou à modificação do padrão, mas suponho que eles o alteraram principalmente porque todas as implementações de shell existentes permitiam for i in; do ...; done, então não fazia sentido proibi-lo no padrão.

Você descobrirá que ele não permite if then ...; else ...; finem if; then ...; else ...; finem if ...; then;else ...; fi¹ (mas permite if $empty; then $empty; else $empty; fiobviamente), mesmo que não haja uma boa razão para proibi-lo, porque a maioria das implementações ( zshsendo uma exceção notável), começando com o shell Bourne que o introduziu e o Korn shell no qual a shespecificação POSIX é baseada, na prática, engasga com ele.

^{¹ Na verdade, no shell Bourne que não possuía a !palavra-chave para negar o status de saída de um pipeline, era necessário escrever if cmd; then :; else command if cmd fails; fino lugar de if ! cmd; then command if cmd fails; fi, ou seja, usar um :comando nulo explícito na thenparte, pois o shell Bourne não permitia um thenparte vazia .}

O raciocínio para esse comportamento é melhor ilustrado com um exemplo. Suponha que você tenha uma variável nomeada ${items}e precise chamar uma função em cada palavra dessa variável, mas ela pode ser avaliada como uma string vazia em alguns casos.

Com comportamento compatível com POSIX, você pode simplesmente usar:

for x in ${items} ; do
   do_something(x)
done

Aqui, não importa se é ${items}avaliado como uma string vazia ou não, porque se isso acontecer, o loop não terá nada para repetir e será simplesmente ignorado.

Mas se o shell tratasse o caso de uma lista de palavras vazias de maneira diferente (ou não, ou equivalente a um dos formulários sem o in), então você precisaria (no mínimo):

if [ -n "${items}" ]; then
    for x in ${items} ; do
        do_something(x)
    done
fi

Portanto, esse comportamento economiza (no mínimo) um nível de recuo e uma verificação condicional extra no caso relativamente comum de ter que iterar sobre uma lista potencialmente vazia de itens de comprimento desconhecido. Muitas outras linguagens que possuem loops for que iteram sobre uma coleção de itens (como Python ou JavaScript) também se comportam exatamente da mesma maneira, apenas exigem explicitamente que uma variável (ou literal) seja fornecida ao loop, enquanto o shell script faz não parece devido à forma como uma lista literal de itens a serem repetidos é definida (ou seja, uma lista vazia é apenas uma string vazia sem aspas).