csh-скрипт не находит исполняемый файл - PullRequest
Новая
       375

csh-скрипт не находит исполняемый файл

0 голосов
/ 11 ноября 2011

Для текущего проекта мне нужно запустить программу генетического алгоритма GENESIS, и профессор предоставил скрипт csh, который позволяет нам легко передавать функцию пригодности, а также внешнюю инициализацию и файлы шаблонов.

Сценарий вызывает make-файл для сборки исполняемого файла, добавляя в микс функцию пригодности и создает исполняемый файл ga.FIT, где FIT - имя исходного файла функции finess.

Вклмашины в школе работают под управлением Ubuntu 10.04, нет никаких проблем с этим скриптом.Однако, когда я пытаюсь запустить его на своем компьютере, я получаю следующий вывод: 

./go cancer2 ex0
Note: Genesis files modified for use on USM Linux cluster
Note2: ga.cancer2 is your executable (e.g., if you need to use the debugger)
making executables ...
make: `ga.cancer2' is up to date.
make: `report' is up to date.
running ga.cancer2 ex0 ...
ga.cancer2: Command not found.

Но исполняемый файл ЕСТЬ!Я могу вручную вызвать его отдельно через ga.cancer2 ex0, и он запускается как в приглашениях csh, так и в bash.Я проверил, что это не проблема с разрешениями, поскольку для исполняемого файла был установлен эквивалент chmod 755.

Это что-то специфическое для csh, и я должен посмотреть на изменение скрипта для bash или придерживатьсядистанционно в школьную систему?

Ответы [ 2 ]

2 голосов
/ 11 ноября 2011

Возможно, вам нужно добавить . к вашему $PATH.

И как только вы сдадите экзамен, расскажите своему профессору о знаменитой C-оболочке, считающейся вредной бумагойи предложите ему прочитать страницу Википедии «Считается вредной» .

1 голос
/ 11 ноября 2011

Похоже, ga.cancer2 находится в вашем текущем каталоге.Ответ Basile должен работать, но, вероятно, лучше изменить скрипт так, чтобы он вызывал ./ga.cancer2, а не ga.cancer2.

В общем, наличие . в вашем $PATH является потенциальной угрозой безопасности(независимо от того, какую оболочку вы используете).Представьте себе cd входящий в каталог, в котором кто-то посадил команду ls, которая совершает что-то плохое.Если вы убедитесь, что . отсутствует в вашем $PATH (и у вас есть привычка набирать ./command для выполнения команды в текущем каталоге), вы избежите этого риска.

Наличие . в конце из $PATH менее рискованно - но поскольку наиболее распространенное имя для тестовой программы - test, а test вызовет /bin/test, привычка ./commandвсе еще хороший.

И у Basile есть хорошее замечание, что csh не самая лучшая оболочка для написания сценариев - но, судя по выводу, выполняемый сценарий, вероятно, достаточно прост, чтобыэто не имеет большого значения.Тем не менее, хорошие привычки и все такое.

...