нужна помощь с системным вызовом из Java - PullRequest
0 голосов
/ 22 августа 2009

Я использую среду выполнения, чтобы позвонить в систему.

Когда я вызываю его с помощью "ls -l" и читаю то, что получает, он печатает содержимое каталога точно так, как ожидается.

Однако, когда я вызываю его с «which ffmpeg» или «ffmpeg -i FILENAME», возвращается сообщение о том, что ffmpeg не может быть найден, даже если я использую ffmpeg точно таким же образом в командной строке, он работает нормально. Точно так же он отказывается работать с «какими mysql» или «какими perl», которые существуют и прекрасно работают в системе.

Я предполагаю, что это что-то вроде разрешений, но я не знаю, как обойти это.

Есть мысли?

редактировать -

Некоторая дополнительная информация ... Я запускаю это как junit в Eclipse, так что, возможно, это проблема окружающей среды. Я никогда не настраивал Eclipse специально для этого ... может быть, мне нужно? Когда я передаю команду «echo $ PATH», она просто печатает «$ PATH», а не фактический путь; опять же, не уверен, что это значит. Наконец, я на OSX, так что вы можете рассматривать это как проблему Linux, если это поможет.

Ответы [ 6 ]

3 голосов
/ 22 августа 2009

Вы прибили это с вашей мыслью о настройке среды. Если щелкнуть правой кнопкой мыши на тесте JUnit, перейдите в «Запуск от имени ...», а затем перейдите к параметру «Запускать конфигурации ...». Во всплывающем окне вы увидите вкладку «Окружающая среда». Вот где ваш тест JUnit будет искать вашу среду, включая вашу переменную «PATH».

Если вы хотите, чтобы ваш тест обнаружил «ffmpeg», то вам нужно выполнить «which ffmpeg» в командной строке и получить результат. В Eclipse нажмите кнопку «Создать ...» на вкладке «Среда» и введите в качестве переменной имя PATH, а в качестве значения укажите каталог, содержащий «ffmpeg». Я считаю, что это работает.

ПРИМЕЧАНИЕ. Требуется путь к каталогу, содержащему ffmpeg, а не полный путь к ffmpeg

Так что, если 'which ffmpeg' возвращает '/ usr / bin / ffmpeg', тогда установите значение PATH в '/usr/bin'.

С другой стороны, если вы запускаете Eclipse таким образом, который поддерживает настроенную вами среду, он должен быть доступен. Это может быть сложнее, чем вы думаете, потому что сценарии запуска Eclipse, как правило, стирают большую часть вашей среды при загрузке. Я бы порекомендовал первый способ.

0 голосов
/ 22 августа 2009

Независимо от настроек PATH, вам необходимо различать двоичные файлы и команды, встроенные в оболочку.

, например

% which ls
/bin/ls

% which which
which: shell built-in command

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

0 голосов
/ 22 августа 2009

Я не уверен, что это так, но это помогло в прошлом .

0 голосов
/ 22 августа 2009

Вы пишете:

Когда я передаю команду "echo $ PATH", это просто печатает "$ PATH", а не фактический путь; опять же, не уверен, что это значит.

Это легко объяснить. Расширение «$ PATH» обычно выполняется командной оболочкой. Runtime запускает вашу команду напрямую, а не внутри командной оболочки. Если вы хотите расширить $ PATH, вам нужно явно запустить команду в оболочке; например,

exec (новая строка [] {"/ bin / sh", "-c", "echo $ PATH"});

Кстати, то же самое происходит в программе на C / C ++, которая запускает команду, используя fork() и exec(). Но библиотечная функция system() запускает команду в оболочке, как указано выше.

0 голосов
/ 22 августа 2009

Когда я запускаю «which ffmpeg» из x11 на OSX, он говорит:

нет ffmpeg в / usr / bin / bin / usr / sbin / sbin / usr / X11R6 / bin

это $ PATH, я думаю. Какой вывод у вашей программы?

0 голосов
/ 22 августа 2009

Я полагаю, что среда выполнения JVM работает не от вас, а по другому пути. «ls» находится в / bin, а «which» обычно находится в / usr / bin. Попробуйте запустить "/ usr / bin / which", чтобы проверить это. Не уверен в вашей ОС (и сам не пробовал), но быстрый поиск показал, что вы должны установить переменную LD_LIBRARY_PATH на желаемый путь в Unix.

...