Re^2: spawning shell commands with aliases

Erm, if they use the full path that pretty much ensures what they're trying to have not happen happens.

The problem is that user A has ls aliased to, say, ls -FC; user B has it aliased to ls -lS (I don't even want to think what users C–Q have it aliased to, but you get the idea . . .). Many shells do not source the startup files which typically would contain the alias ls='ls -FC' lines if the shell is not an interactive shell. So when his wrapper mydiff calls system( $ARGV[0] ) the shell Perl execs (if it even does; in this simple case Perl will probably split on whitespace itself and call execvp directly, further complicating the issues since the user's shell doesn't even enter into the picture) is not expanding ls -1 a/ to ls -FC -1 a/ so the user doesn't get the output in the format they expect.

The underlying problem is that in all likelihood the users' shells are never entering into the picture, and even if they did they wouldn't have the aliases in question active.

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

Replies are listed 'Best First'.
Re^3: spawning shell commands with aliases by swampyankee (Parson) on Dec 19, 2006 at 22:26 UTC
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.	[reply] [d/l]
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]