in reply to passing setup via pipeline

Shell aliases do not work, because system does not (always) invoke the shell. You will need to explicitly invoke the shell if you want shell aliases to work.

Replies are listed 'Best First'.
Re^2: passing setup via pipeline
by cdarke (Prior) on May 25, 2010 at 07:51 UTC
    As an addition to Corion's comments, it also depends on where your alias is specified, and which shell you are using. Even if system does invoke a shell it will be a Bourne shell (/bin/sh -c). So if, for example, your aliases are defined in ~/.kshrc then that will not be read. If you invoke your shell explicitly then you should carefully note which startup files are executed for non-login non-interactive sessions. For example, Korn shell 88, Korn shell 93, and Bash all have different rules for that.

    Personally I would discourage use of aliases anywhere except as an interactive keyboard productivity aid - they are a support nightmare when used in scripts.
Re^2: passing setup via pipeline
by Anonymous Monk on May 25, 2010 at 07:57 UTC
    hmmm

    I was thinking to use another pipeline, for example:
    open(MYPIPE,"source .aliases|");
    my $mypipe = <MYPIPE>;
    open(COM,"$mypipe | $run_cmd 2>&1 |") || die "Could not execute command\n";

    $_ = <COM>;
    do{
    $txt -> insert('end',$_);
    }

    while(<COM>);
    close(COM);


    what do you think, does it have a chance
    BR
    Michael
      First, 'source' is a c-shell or bash built-in, so you need to specify the shell.
      Second, that would just create the aliases in one child process. The second open will run a different process without the aliases.

      I think you want open3 or similar.

      open3(*TO_CHLD, *FR_CHLD, undef, 'bash')

      Then you can print out commands to TO_CHLD and collect the output from FR_CHLD. Then you can issue shell commands including aliases, and the state of the shell (incl current work dir and environment settings) will persist between commands.

      Hum, actually, you would need a pty instead of a pipe to get interactive behaviour. IPC::Run can do all of this pretty easily, so it's probably a better choice than open3

        ... Then you can print out commands to TO_CHLD and collect the output from FR_CHLD.

        I think one of the tricky things with open3 is how to correctly detect the end of multi-line responses, e.g. when issuing commands like ls -l (or the respective alias), as the pesistent shell won't close the pipe when done with the command.

      Your idea does not make any sense to me.