tags:

views:

214

answers:

6

I'm using Runtime to make a call to the system.

When I call it with "ls -l" and read in what it gets, it prints the directory contents exactly as expected.

However when I call it with "which ffmpeg" or "ffmpeg -i FILENAME" it comes back saying ffmpeg can't be located, even though when I use ffmpeg exactly the same way at the command line it works fine. Similarly it refuses to work with "which mysql" or "which perl" all of which exist and work fine on the system.

I'm assuming it's some sort of permissions thing, but I'm at a loss as to how to get around it.

Any thoughts?

edit--

Some additional info... I'm running this as a junit in Eclipse, so, perhaps it's all an environment problem. I've never configured Eclipse for this specifically... perhaps I need to? When I pass in command "echo $PATH" it just prints out "$PATH" rather than an actual path; again, not sure what that means. Lastly, I'm on OSX, so, you can treat this as a linux problem, if that helps.

A: 

My guess would be that the JVM runtime is running as someone other than you and has a different path. "ls" is in /bin, and "which" is generally in /usr/bin. Try running "/usr/bin/which" to verify this. Not sure of your OS (and haven't tried this myself) but a quick search mentioned that you should set the variable LD_LIBRARY_PATH to your desired path under Unix.

Nerdfest
`LD_LIBRARY_PATH` is used for loading dynamically linked libraries, not for running programs (well, unless those programs use dynamically linked libraries). You shouldn't need it for running simple things like `ls` or `which`.
David Zaslavsky
Aye, the variable PATH is what you would want to look at to make sure it includes the path to ffmpeg.
Matt Beldyk
+3  A: 

You nailed it with your thought about the environment setup. If right click on your JUnit test, go to "Run As..." and then go to the "Run Configurations..." option. On the popup, you'll notice a tab called "Environment". This is where your JUnit test is going to look for your environment, including your "PATH" variable.

If you're going to want your test to find "ffmpeg", then you should do a "which ffmpeg" on the command line and take the result. In Eclipse, click the "New..." button on the Environment tab and put in PATH as the variable name and the directory containing "ffmpeg" as the value. I believe that works.

NOTE: You want the path to the directory containing ffmpeg, not the full path to ffmpeg

So if 'which ffmpeg' returns '/usr/bin/ffmpeg', then set the value of PATH to '/usr/bin'.

Alternately, if you launch Eclipse in a way that maintains the environment you have set up, it should be accessible. This can be trickier than you think though because the Eclipse startup scripts tend to wipe a lot of your environment at boot. I'd recommend the first way.

Brent Nash
Yeah... I came back here to post the answer, but you nailed it, so, I'll give you the right answer... please add to your edit that since eclipse is generally not the end destination for our code, it's important to make sure that the environment in which this runs also has the path set correctly. In my case, I'm in jboss which is started at the shell, so, I have to create an environment variable and retrieve it in my java code and then everything works as expected.
Dr.Dredel
A: 

When I run "which ffmpeg" from x11 on OSX it says:

no ffmpeg in /usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin

which is the $PATH, i guess. What's the output of your program?

tulskiy
my guess is that you have not installed ffmpeg via the make install methodology... if you did, it would just print out the path as it does when you `which` anything else.
Dr.Dredel
That is the point, i do not have ffmpeg and "which" shows me where it looks for it. If your problem is the environment setup, then output of "which" will give you the $PATH.
tulskiy
I've never seen which work like that... when I type which looking for something that is nonexistent, it just prints a new line
Dr.Dredel
A: 

You write:

When I pass in command "echo $PATH" it just prints out "$PATH" rather than an actual path; again, not sure what that means.

That is easy to explain. Expansion of "$PATH" is normally done by a command shell. Runtime is running your command directly rather than running it inside a command shell. If you wanted to get $PATH expanded you would need to explicitly run the command in a shell; e.g.

exec(new String[]{"/bin/sh", "-c", "echo $PATH"});

Incidentally, the same thing happens in a C / C++ program that runs a command using fork() and exec(). But the system() library function runs the command in a shell, as above.

Stephen C
A: 

I'm not sure if this is the case, but this has helped in the past.

OscarRyz
A: 

Regardless of your PATH settings, you need to distinguish between binaries, and commands that are built into the shell.

e.g.

% which ls
/bin/ls

% which which
which: shell built-in command

so some commands you use are particular to the shell, and not actual commands directly available to other runtimes.

Brian Agnew