[Pdx-pm] solved: job control (still got a question)

Michael R. Wolf MichaelRunningWolf at att.net
Tue Jun 3 18:38:26 CDT 2003


Randall Hansen <perl at sonofhans.net> writes:

> First, thanks for everyone's help.  I have one nagging question
> (immediately below) and then a brief explanation of what I was
> solving.
>
> At this point the only thing that confuses me is the output
> from:
> 	$ perl -e "print `jobs`"
>
> This does pass 'jobs' to the current shell *and* returns the data I
> need[1], but it appears that perl is trying to 'eval' that data before
> it passes it to 'print.'  If bash is passing that data into perl
> somehow I should be able to inspect or intercept it (I'd think), but I
> can't figure out how.  That's all curiosity, though, since I have a
> solution that works.
>
> As it turns out, Tom's earlier pipe suggestion did the trick (once I
> remembered to use <STDIN> instead of @ARGV).  The final solution (so
> to speak) was this:
>
>     PROMPT_COMMAND="PS1=\$(jobs | ~/bin/prompt_me.pl)"

Hey, foul! You lead us down (or we got faked down) a "do it in a
subshell" mindset. Just kiddin', though I think we all thought some
differnt, *normal*, calling sequence.

I can only figure that this works if the 'jobs' is being done in the
current shell (like dot-ing a file (ksh, sh) or sourc-ing a file
(csh)), either as a result of special PS1 processing or a special
optomization for command substitution. In certain cases, I bet it's
saved a subshell (i.e. an expensive fork/exec).

That's the only way I can think that this is working -- the command
substitution is not creating a subshell for evaluating 'jobs'.

So, I think you got away with one in this *specific* case, that won't
work in general.

-- 
Michael R. Wolf
    All mammals learn by playing!
        MichaelRunningWolf at att.net




More information about the Pdx-pm-list mailing list