Re: Why system calls suck.

[xphase_work]

This illustrates, in addition to security issues, why all system commands in any script should be prefaced by their full path.

Another good example on solaris machines is the /usr/ucb directory. It contains the BSD versions of unix commands, which are different than the /bin and /usr/bin binaries.

me@hostname > alias ps
/usr/ucb/ps

This has completely different syntax and output than /usr/bin/ps

System calls are also not very portable, as ps -ef won't work on the BSD versions of ps and ps aux will fail on the solaris versions.

--xPhase

[no_slogan]

This illustrates, in addition to security issues, why all system commands in any script should be prefaced by their full path.

I used to be in that camp, but I've found that it causes portability problems. We have a pile of legacy code that runs on many different machines. Some of the system calls use absoulte paths, and this causes trouble when common programs migrate between /bin, /usr/bin, /usr/local/bin, and other places on various versions of Solaris, Linux, Irix, etc...

For a while, I tried to maintain a config section with the absolute paths to every executable I might want to use. That didn't seem to help matters, because the config has to be tweaked all the time. What I really want is to be able to drop my script on a random machine and have it work with the minimum of fuss.

I've been thinking that a better solution might be to set $ENV{PATH} explicitly (possibly to different value depending on the OS), and then avoid using absolute paths whenever possible. Has anyone been there and brought back some advice?

System calls are also not very portable, as ps -ef won't work on the BSD versions of ps and ps aux will fail on the solaris versions.

ps is just pathological. If you need that kind of information out of the system, you're in for pain one way or another.