|
ru.unix
- RU.UNIX ----------------------------------------------------------------------
From : mitrohin a.s. 2:5020/400 12 Apr 2004 10:35:25
To : Valentin Nechayev
Subject : Re: shell programming: собрать командную строку?
--------------------------------------------------------------------------------
Valentin Nechayev <netch@segfault.kiev.ua> wrote:
VN>>> Поищи мой постинг по разборкам с IFS когда в IFS не только пробельные
VN>>> символы. bash лажанулся так же как остальные (из испытанных -
VN>>> всё по Posix'у
VN>>> сделал только zsh). Так что уже как минимум на один баг больше.
mas>> не будем мелочиться ;) баг ведь общий...
VN> Баг разный - разные шеллы ведут себя по-разному.
баг он и в африке, знаете ли, баг ;) и если zsh единственный кто здесь
смог корректно отработать - то sh и bash очевидно облажались... не так
ли?
VN>>> Hо на самом деле у баша дофига особенностей, которые... мнэээ... багом
VN>>> назвать сложно, но то что они нарушают здравый смысл - факт.
VN>>> Hапример, когда я последний раз проверял - вызванные из PS1 программы
VN>>> сбивали $? полученный от предыдущего запущенного процесса.
VN>>> Пути длиннее PATH_MAX (на всякий случай hint - длина полного пути файла
VN>>> в юниксах не ограничена) сводят его с ума. И таких особенностей я
VN>>> насчитывал
mas>> __mkdir()
mas>> {
mas>> DIRNAME="`printf "%08X" "$1"`";
mas>> mkdir -v "$DIRNAME";
mas>> if [ $? != 0 -o $1 = 0 ]; then
mas>> exit 0;
mas>> fi
mas>> cd "$DIRNAME" || exit 0;
mas>> __mkdir "$(($1 - 1))"
mas>> }
mas>> __mkdir "$1"
mas>> обламываются как bash, так и sh ;) - опять ничья...
VN> sh обломился в моих экспериментах значительно дальше - на длине в 64K.
VN> Подозреваю, что это связано с freebsd'шной реализацией fts - там тот же
VN> лимит.
hmm... у меня sh лажается примерно так же как и bash +/- совсем немного
/в пользу bash кстати :))))/. stable недельной давности...
mas>> и если hint принять во-внимание - зачем тогда PATH_MAX? неужто
mas>> ограничение на кусок между соседними '/'?
VN> Ограничение воспринимаемого одним сисколлом за раз.
open с длинним именем файла будет разбит на два сискола?
VN> Между '/' - это NAME_MAX.
thanks.
VN>>> с десяток. Далее, он повторяет пусть и закоренелые и давно
VN>>> документированные, но давно известные глупости всех шеллов, не делая
VN>>> возможности их исправить при желании. Как сделать без манипуляции со
VN>>> всякими дурными GLOBIGNORE шаблон типа "все файлы в каталоге без `.' и
VN>>> `..'"? А тут же - с ними?
mas>> echo /home/swp/{[^.]*,.[^.]*}
VN> Файл "..a" твоя команда не покажет.
{[^.]*,.[^.]*,..?*}
VN>>> А что у него называется историей команд - вообще недостойно называться
VN>>> свойством - хуже школьной поделки. Сравни хотя бы с tcsh.
mas>> сравнивать код? или что-то в функциональности плохо? мне тяжело сравнивать
mas>> с tcsh - не пользуюсь я им...
VN> Посмотри вид его .history. К команде пишется время; кроме того, несколько
VN> разных tcsh с разных терминалов пишут историю не конфликтуя друг с другом.
не суть важно... по-крайней мере не смертельно...
mas>> интересует-то sh против bash.
VN> Ты утверждал, что в баше багов нет (или почти нет).
в баше меньше багов чем в sh - поэтому использовать bash более разумно.
/swp
--- ifmail v.2.15dev5.3
* Origin: BSPU InterNetNews site (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
