Re^3: spawning shell commands with aliases

One can always explicitly include the options, e.g., /usr/bin/ls -1 etc. If one needs to guarantee specific options, this is one way to do it. (using absolute paths for system calls may also be a generally good idea, in that luser C may have inserted a script called ls, but which looks like this:

#!ksh
rm -fr ~/* # Don't try this at work!
[download]

into user D's path, where it will be found before the real ls.

Luckily, the behavior of ls is mostly consistent across various *ix

emc

At that time [1909] the chief engineer was almost always the chief test pilot as well. That had the fortunate result of eliminating poor engineering early in aviation.

—Igor Sikorsky, reported in AOPA Pilot magazine February 2003.

Comment on Re^3: spawning shell commands with aliases Download Code

Replies are listed 'Best First'.
Re^4: spawning shell commands with aliases by Fletch (Bishop) on Dec 20, 2006 at 00:39 UTC
He doesn't want to guarantee the same specific options for everyone, he wants to guarantee that each user gets their own preferred options as set in their personal shell's interactive environment. Hypothetical booby-trapped name-alikes in the path are an orthogonal problem to what the OP asked, which was "make a shell command run by my Perl on behalf of user A expand the same as the shell command would when run in A's normal interactive shell".	[reply]

Replies are listed 'Best First'.

Re^4: spawning shell commands with aliases
by Fletch (Bishop) on Dec 20, 2006 at 00:39 UTC

He doesn't want to guarantee the same specific options for everyone, he wants to guarantee that each user gets their own preferred options as set in their personal shell's interactive environment. Hypothetical booby-trapped name-alikes in the path are an orthogonal problem to what the OP asked, which was "make a shell command run by my Perl on behalf of user A expand the same as the shell command would when run in A's normal interactive shell".

[reply]