On Tue, Sep 11, 2007 at 07:55:40PM +0300, Led wrote:
> > Это чистый #!/bin/sh скрипт, в котором досовские окончания строк \r\n.
> > Именно из-за этого шелл не может его распарсить.
> >
> > Раньше зависимости в этом скрипте не искались, потому что он не
> > исполняемый.  Теперь зависимости ищутся во всех шелл-скриптах -- как
> > исполняемых, так и не исполняемых (rationale: нельзя отличить скрипт
> > от библиотеки шелл-функций, которая подключается через "." или source).
> 
> Очень часто даже сейчас приходится указывать:
> Autoreq: yes, noshell
> потому как в "шеловских скриптах" часто, например, такое:
> if [ -x /usr/bin/foo1 ]; then
> 	/usr/bin/foo1 ....
> elif [ -x /usr/bin/foo2 ]; then
> 	/usr/bin/foo2
> 	....
> else
> 	....
> fi

Это всегда так было, и эта проблема по сути никак не связана с битом -x
на скриптах.  Нужен на порядок более мощный шелл-анализатор, чтобы
можно было хоть как-то справляться с условными зависимостями.  То есть
нужно что-то вроде дерева опкодов, как в перле, или sexp-дерева, и
стековый/рекурсивный проход по нему с фиксацией локального состояния.
Тогда можно обнаруживать ситуации типа

	проверка существования файла 				    <--------------\
		загрузка файла	[!]->--вверх по стеку есть проверка существования--'
	следующая команда	[!] pop локальное состояние

Ну долго объяснять.  В принципе такое возможно, хотя это и очень сложно
по сравнению с тем, что сейчас есть.  В первом приближении можно об этом
думать как о чем-то типа SAX.  То есть логику можно внедрять на чем-то
типа обработки xml дерева.

> По крайней мере, в моей практике "исключения" встречаются не реже, 
> чем "правила", и автоматическому find.req.shell стараюсь "не доверять".

Вместе с этим Вы лишаетесь проверки syntax check.
Warkaround давно известен -- заворачивать условные пути в переменные.

	f1=/usr/bin/foo1
	f2=/usr/bin/foo2
	if [ -x "$f1" ]; then
		"$f1"
	elif [ -x "$f2" ]; then
		"$f2"
	else
		...
	fi

В общем, не доверять по умолчанию это перебор, но зависимости приходится
проверять.