in reply to spawning shell commands with aliases

One possibility would be to use the full path for the commands, e.g., /usr/bin/ls.

There is a Perl module which will, "Compute `intelligent' differences between two files / lists" (Algorithm::Diff). This may be a superior solution.

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: spawning shell commands with aliases

Replies are listed 'Best First'.
Re^2: spawning shell commands with aliases
by Fletch (Bishop) on Dec 19, 2006 at 18:08 UTC

    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.

      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!
      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.

        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".