Почему мне нужно поместить «do» в ту же строку, что и «for»?
Функция, доступная через fpath , не «существует» в том смысле, что ее можно вызвать. Сначала он должен быть загружен автоматически, после чего , который (и любой другой метод проверки существования функции) сообщит об определении заглушки, которое автоматически загружает реальное определение.
% zargs
zsh: command not found: zargs
% autoload zargs
% which zargs
zargs () {
# undefined
builtin autoload -X
}
which foo точно проверяет, можно ли использовать foo в качестве имени команды, за исключением того, что может сделать command_not_found_handler . Поскольку command_not_found_handler может содержать произвольный код, невозможно предсказать, что он будет делать; и поскольку он выполняет заменяющую команду, если она ее находит, невозможно проверить, что он будет делать, ничего не выполнив.
Если ваш код зависит от zsh, вы можете использовать где вместо which (или где -w , чтобы получить более сжатый вывод, нет возможности сделать его тихим), который является оберткой вокруг откуда .Если вы хотите, чтобы ваш код можно было использовать в других оболочках в стиле Bourne / POSIX, используйте тип , а не , который .
function exists {
whence -w $1 >/dev/null
}
Если ваше определение «существует» включает функции, которые могут быть загружены автоматически, но еще не загружены, тогда реализуйте код, который обнаруживает функции, которые могут быть автоматически загружены, но еще не загружены: traverse $ fpath явно.
Sintácticamente, los siguientes dos fragmentos de código son correctos y equivalentes:
for f in bash/*.sh; do
sashacommand "$f"
done
for f in bash/*.sh
do sashacommand "$f"
done
Este último podría posiblemente decirse que es más difícil de leer ya que doofusca ligeramente el comando en el cuerpo del ciclo. Si el bucle contiene varios comandos y el siguiente comando está en una nueva línea, la ofuscación se resaltará aún más:
for f in *
do cmd1
cmd2
done
... pero marcarlo como un "error" es en mi humilde opinión la opinión personal de alguien más que una verdad objetiva.
Diría que si desea anteponer el comando en el bucle con do, siéntase libre de hacerlo si eso hace que el código sea coherente y legible a los ojos de quien lo lea.
En general, casi cualquier ;puede ser reemplazado por una nueva línea. Tanto ;como la nueva línea son terminadores de comandos. does una palabra clave que significa "aquí sigue lo que debe hacerse (en este forbucle )".
for f in *; do...; done
es lo mismo que
for f in *
do
...
done
y como
for f in *; do
...
done
y
for f in *
do...
done
La razón para usar uno sobre otro es la legibilidad y las convenciones de estilo local/personal.
Opinión personal:
En los encabezados de bucle que son muy largos , creo que puede tener sentido poner doen una nueva línea, como en
for i in animals people houses thoughts basketballs bees
do
...
done
o
for i in \
animals \
people \
houses \
thoughts \
basketballs \
bees
do
...
done
Lo mismo ocurre con thenen una declaración if.
Pero nuevamente, esto se reduce a las preferencias personales de estilo, o al estilo de codificación que esté usando el equipo/proyecto.
TL;DR :No es necesario. Es solo la opinión de un tipo.
Como muchos otros, he estado escribiendo forbucles como este durante décadas:
for F in arg1 arg2 arg*
do
somecommand "$F"
done
Este diseño destaca el hecho de que do... donerodea el cuerpo del bucle,como llaves en C -como lenguajes, y permite nuevas líneas para separar los componentes de la construcción del bucle.
Por supuesto, también hay guerras religiosas sobre dónde colocar las llaves, por lo que se podría decir que el jurado todavía está deliberando sobre este. En mi humilde opinión, así es claramente como fue diseñado para funcionar; A Bourne le gustaban los delimitadores emparejados, cf. if... fi, case... esac, y la necesidad de un punto y coma en la versión más corta revela que lo está haciendo más corto de lo que se diseñó originalmente. Nada de malo con eso; la tecnología avanza y muchas cosas que antes parecían una buena idea ahora están mal vistas, como goto. Pero hasta que toda la comunidad de scripts de shell -adopte las preferencias del bashateautor (s ), no tiene que hacer nada.
Me sorprende que nadie haya mencionado esta sintaxis válida y portátil aún:
set alfa bravo charlie
for q do
echo "$q"
done
Nótese cuidadosamente que fory doestán en la misma línea, sin punto y coma. Resultado:
alfa
bravo
charlie