Админам, пишущим на 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]

set -e
в начале скрипта помогает. А вообще код завершения команды cd не проверять бывает очень больно.

[qkowlew]

Всё верно.
Но тут прикол - что не так в САМОЙ КОМАНДЕ cd "${i}"

[vitus_wagner]

Неужели именно в самой? А не в вышележащей команде for?

Можно же написать for i in ./*; do

[filin]

Витус, можно, но так точно никто не пишет :)

[vitus_wagner]

Ну я по крайней мере так пишу в аргументе find. Привык уже, что пустой файлик с именем -rf где-то да существует, поэтому все пути в текущем поддереве должны начинаться с ./

[qkowlew]

именно в ней самой.

Ну чтобы избавить данный вопрос от претензии "почему не find" - та же самая недостача в такой же строке скрипта вида:

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

[vitus_wagner]

Тогда претензия "почему не прочитать man ls и не сделать это одной командой ls "$1""?

Ну и вообще, кто пишет скрипты на баше, тот сам себе буратина. Если тебе не хватает стандартного sh, то надо уже нормальный скриптовывй язык брать. Ты ж вроде BSD-шник. Откуда у тебя bash в /bin?

[qkowlew]

Тогда претензия "почему не прочитать man ls и не сделать это одной командой ls "$1""?

Хотя бы потому, что эта проблема точно так же вылазит и в ls "$1"

Так как Кир Злобин (в ЖЖ) уже озвучил суть, демонстрируем:

ns$ mkdir -- -x
ns$ ls "-x"
листинг текущего каталога, а не каталога -x/
ns$ mkdir -- -l
ns$ ls "-l"
листинг текущего каталога в -l виде.
ns$

с командами mv cp rm mkdir rmdir ессно всё это тоже заметно...

Если тебе не хватает стандартного sh
Это просто набор скриптов, который как тот поросёночек - рос-рос... из ~шести строк тривиального запуска wget'a... И дорос до того, чо умные люди называют "рефакторинг". :(

Откуда у тебя bash в /bin?

А почему ты решил, что проблема только во FreeBSD?
Вышеприведённый пример исполнялся в CentOS, а напоролся я в дебиане.
И разницы в поведении bash'ей по этому пункту пока не увидел.

[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

[filin]

Ты имел в виду ./?

Так сразу и говори: "в этом коде проблемы через строку, но я хочу, чтобы вы угадали некоторую конкретную именно в этой строке. Да, я знаю, что и в ней их тоже больше одной."

Или ты не знаешь, что в этой строке больше одной проблемы типа "не хватает"?

[qkowlew]

Нет, я вполне буду рад перечислению ВСЕХ проблем.
Забавно то, что пока - перечислили НЕ ВСЕ.
Даже для этой одной строки - НЕ ВСЕ.

[filin]

Четвертая проблема мне пока в голову не приходит. Но я еще попробую на свежую голову...