[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