Наш мудрый поисковик зависимостей следующие конструкции: if [ -d "/dev/elan" ] ; then FARCH="meiko" elif [ -f /usr/bin/uxpm ] && /usr/bin/uxpm ; then FARCH="UXPM" elif [ -f /usr/bin/uxpv ] && /usr/bin/uxpv ; then FARCH="uxpv" fi превращает в зависимости на /usr/bin/uxpm и на /usr/bin/uxpv, что совершенно не правильно.
(In reply to comment #0) > Наш мудрый поисковик зависимостей следующие конструкции: > > if [ -d "/dev/elan" ] ; then > FARCH="meiko" > elif [ -f /usr/bin/uxpm ] && /usr/bin/uxpm ; then > FARCH="UXPM" > elif [ -f /usr/bin/uxpv ] && /usr/bin/uxpv ; then > FARCH="uxpv" > fi > > превращает в зависимости на /usr/bin/uxpm и на /usr/bin/uxpv, что совершенно не > правильно. Что же тут неправильного? Он именно так он и должен работать.
Неправильного то, что и uxpm, и uxpv цепляются, а должно что-то одно.
(In reply to comment #2) > Неправильного то, что и uxpm, и uxpv цепляются, а должно что-то одно. Нет, в таком коде в зависимости должно попасть и то и другое.
Т.е. в любом нетривиальном коде такого рода "левые" зависимости будут наматываться в огромном количестве? PS: а где написано, "как должно быть"?
(In reply to comment #4) > Т.е. в любом нетривиальном коде такого рода "левые" зависимости будут > наматываться в огромном количестве? Такого рода проверки встречаются в небольшом количестве. > PS: а где написано, "как должно быть"? Как должно быть где?
(In reply to comment #5) > > PS: а где написано, "как должно быть"? > Как должно быть где? Как должно быть "вообще" - т.е. что есть The Right Thing для такой зависимостеискалки.
(In reply to comment #6) > (In reply to comment #5) > > > PS: а где написано, "как должно быть"? > > Как должно быть где? > > Как должно быть "вообще" - т.е. что есть The Right Thing для такой > зависимостеискалки. The Right Thing для такой зависимостеискалки недостижим. Всегда будут либо ложные срабатывания, либо пропуски, либо и то и другое. Если и написано, то только как работает нынешняя.
нет, так быть не должно. Если это сейчас исправить не возможно, то пусть остаётся на будущее. Одно время в perl цеплялись зависимости типа (код пишу не не перле ;)) if (system == windows) { require Win32 } Это приводило к тому что в Сизиф цеплялись win32 модули. Если это считалось ошибкой, и было в своё время исправлено, то не понимаю почему шелл такой особенный. В приведённом коде нигде не было явной зависимости на использование утилит ибо стояла проверка -f. Повторюсь ещё раз: Если текущий поисковик зависмостей даёт _надмножество_ возможных зависимостей, а не _подмножество_, то это неправильно.
(In reply to comment #4) > Т.е. в любом нетривиальном коде такого рода "левые" зависимости будут > наматываться в огромном количестве? Что особенно радует, когда код чужой и апстрим либо уже помер, либо не собирается понижать читабельность кода за счёт решения наших собственных проблем. > PS: а где написано, "как должно быть"? В devel@ упоминалось: x="/usr/sbin/x" [ -x "$x" ] && "$x" ||: Боюсь, на сейчас эта автоматизация будет приводить к возрастанию пакетов с AutoReq: yes, noshell, как вот в spt. За что боролись, на то пока и напарываемся :( Может, получается сделать какой-то регулятор, в котором текущее поведение будет равно "95%", а более раннее (год тому там) -- "80%"? Для своих скриптов может быть осмысленно стремиться к идеалу сильнее, чем для произвольных чужих.
Увы, сейчас поиск зависимостей в шелл-скриптах фактически диктует определённый стиль написания этих скриптов (нужно "скрывать" более условные команды и, наоборот, явно писать менее условные команды). Жертва очень большая, да и вообще автоматический поиск зависимостей в чисто интерпретируемых языках больше похож на авантюру. В менее интерпретируемых языках (где зависимости осуществляются через систему модулей) нежалательные зависимости хотя бы легче локализовать (и требуется поправить их более-менее "всего в одном месте"), а тут иногда получается, что весь код целиком нужно просматривать, имея в виду автоматический поиск зависимостей. Что тут можно сделать? Это может быть целый research: нужно научить /bin/sh дампить syntax tree в виде S-выражения и дальше match'ить это S-выражение по шаблону типа case analysis. Так что по идее можно отлавливать некоторые случаи типа "проверка существования перед использованием". Тут опять же есть два варианта, либо чисто лексический анализ, либо дополнительно ещё контролируемое частичное исполнение скрипта (c перехватом/запретом fork/exec/dup2). Но поскольку в шелле ничего нельзя сделать без форка и exec'а, то контролируемое частичное исполнение скрипта опять оборачиватеся авантюрой. Короче, мне в принципе интересно, есть ли в природе какие-нибудь research papaers на эту тему (анализ условных зависимостей). Кажется это по-научному называется Value Evolution Graph (VEG) -- http://www.google.com/search?q=%22Value+evolution+graph%22
*** Bug 14327 has been marked as a duplicate of this bug. ***
Я сомневаюсь в том, что этот вопрос будет решён в обозримом будущем.
Я тоже.
