Админам, пишущим на bash..

[qkowlew]

Прикол для очень внимательных и опытных писателей на bash.

Однажды отец Онуфрий опытный админ написал кусок кода, обходящий окрестности онежского дерево каталогов, и стал его применять везде где ни попадя:

SqTree(){
[ -z "${1}" ] && return
for i in *.html
 do
 [ -s "${i}" ] && (тут обработка строк файла, не важно какая)
 done
for i in *
 do
 [ -d "${i}" ] || continue
 cd "${i}"
 SqTree "${1}"
 cd ..
 done
}

Скажите, собратия по написанию скриптов на bash и многих других шеллах - чего не хватает конкретно в выделенной полужирным строке, и почему? :)

UPD 2017-02-01 15:53 : пока из 6 участвующих в о[б|]суждении обнаружил "самую интересную" ошибку только один (в ирц, не здесь). :)

UPD 2017-02-01 19:05 : чтобы избавить данный вопрос от претензии "почему не find" - та же самая "недостача" в такой же выделенной строке скрипта вида:

#!/bin/bash
# Show subdirectory listing
[ -z "$1" ] && return
[ -d "$1" ] || return
cd "$1"
ls
cd ..

Comments

[vitus_wagner]

Ку, на табличке твоим же собственным голосом написано "Ты невнимателен"
Я тебе еще сколько комментариев назад предложил заменить * в for на ./*
Это решает все проблемы с именами файлов, начинающимися с минусов. И решает их на этапе генерации списка имен, а не на этапе его использования.

Человек, имеющий дело с FreeBSD, по крайней мере знает, что на свете бывает настоящий sh, который не баш.
В отличие от человека, который никаких POSIX-систем кроме GNU не видал, а GNU, как известно is not Unix.
FreeBSD в общем-то тоже is not Unix, поскольку там весть закопирайченный код AT&T давным-давно переписали,
но она хотя бы похожа. Более того, если мне не изменяет память, ты же сам с месяц назад в какой-то дискуссии утверждал что не надо полагаться на наличие в системе bash, а то вдруг /usr/local не смонтировался корректно, и надо залогиниться, чтобы это исправить.

Но вообще я специально держал виртуалку с solaris, чтобы тестировать кое-какие вещи в настоящем Unix, который на базе system V-вской codebase. Сейчас у меня все равно настоящий спарк под рукой есть, поскольку тестировать сишный код на big-endian со strict-alignment тоже крайне полезно.

Мое мнение (кстати, практически выстраданное, и много кем разделяемое) - шелловские скрипты надо писать на /bin/sh.
И его же в шебанг прописывать. И как только тебе неудержимо захотелось упоребить в скрипте башизм, это повод переписать его c shell на perl или python. bash - только для интерактивной работы. По поводу zsh у тех, кто его активно используют может быть другое мнение. Там вроде немножко поаккуратнее это сделано.

[qkowlew]

Я тебе еще сколько комментариев назад предложил заменить * в for на ./*

О том и речь, что этого самого for может и не оказаться! А каталог с минусом попасться.

bash - только для интерактивной работы

Интерактивной, да!

Так в том и дело, что "в этой истории началось всё с одной команды в интерактиве". То есть с wget -m, очередной попытки отзеркалить очередной сайт. Потом - поднимаемый из хистори for и длиннейший регексп на перле. И вот "пока я в интерактиве с удобственнейшим башем" - тут то и врастает в меня-погромизда набор неправильных шаблонов, часть из которых - именно "башизмы", а часть - "порождение всего пространства шеллов", для меня то начиная с command.com MSDOS 3.30 аж, а не то что POSIX!

Поэтому прикол в данном случае получился не чисто технический (хотя башизм в конкретной ситуации и есть), а больше психологический.

[dmarck]

for не может не оказаться, for -- это shell builtin!

[qkowlew]

Да, именно что может и не быть.
Но вот привык к башу.
Как когда-то к command.com, хехе

[dmarck]

не-не. for является непременно реализованной функцией любого korn-style POSIX шелла.

А chdir (cd) -- единственная функция, которая не может быть реализованной как внешний бинарник -- потому что внешний бинарник не может поменять working directory вызывающему. ;-P