On 1/12/06, Grant Jacobs <[EMAIL PROTECTED]> wrote:
> >So sorry to see you go.
>
> There's nothing bad about me unsubscribing (you're reading me very
> negatively!). Its just I get so much mail that I prefer to
> unsubscribe and browse HTML archives if I'm not actively asking
> something.
>
>
> >The only cross-platform, foolproof way of keeping track of the
> >command-line used to launch a program regardless of the complexity that
> >I can think of is to make a note of it in the program that launched the
> >command-line. If you really wanted to, you could even pass it as an
> >argument to your script.
>
> I'd need to think about that more, but this might lead to a more sane
> solution that the way I did it in my OP -)
>
>
> >BTW, JupiterHost didn't misunderstand you.
>
> There's no malice in my writing "misread" btw, I do it all the time
> too (as I did to your previous paragraph ["The only..."] at first,
> incidentally). It can be hard to make things clear via mail posts as
> you know.
>
> I'm used to helping the odd beginner myself, btw ;-)
>
> I only wrote on this list as there seemed to be no other "general"
> forum here; the others looked too specialised for this.
>
> Cheers,
>
>
> Grant
> --
Grant,
Unfortunately, there's a really simple answer here: you can't. This is
a feature of the unix environment, processes have limited information
about thier parents and children, and none at all about thier
siblings. A quick peek at something like
perl -e 'print `ps`' | less
will show that the OS isn't even tracking the relationship between
perl and less, much less passing that information along to either
process. Only shell that launched them is keeping track of the I/O
redirection. As far as they know they are getting STDIN from the
parent process and passing STDOUT back to the parent process. What the
parent does with it after that (like, say, passing perl's STDOUT to
less's STDIN) is nobody's business. As far as each individual process
in a pipe is concerned, it's launched in a vaccuum and given some
information that it then returns in a vaccuum. That's an
oversimplification of course, particularly in threaded environments,
but it's the basic conceptual model.
In some shells, the shell makes the command line available via a
special shell variable or escape that can be accessed before the
command is executed. This is how people put thier current command in
their X window title bars. zsh does this, I think; most of the common
shells don't. If you're using a shell that offers this functionality,
you can pass the variable to perl on the command line.
Your other option is to monitor the kernel and figure out what's what
on your own. This is extremely OS and implementation specific, and
non-portable. Start up trace, truss, systrace, or whatever the
equivalent on your OS is, and watch for what descriptors the shell and
it's child processes are opening. These utilities are designed to do
exactly what you want: trace execution and system and process I/O. Be
warned, though, the tools are designed primarily for kernel debuggers
and sysadmins tracing problems (exploits, memory leaks). They're not
for the faint of heart.
Another thing to keep in mind: if you're serious about this, make sure
you include a dump of %ENV, preferrably in a BEGIN block, too--or at
least the relevant parts. Consider a line like:
perl ./myscript ../../../data/bio/01132005-01/12345678767.txt
That's not going to make much sense unless you've grabbed at least
$ENV{USER} and $ENV{PWD}.
HTH,
-- jay
--------------------------------------------------
This email and attachment(s): [ ] blogable; [ x ] ask first; [ ]
private and confidential
daggerquill [at] gmail [dot] com
http://www.tuaw.com http://www.dpguru.com http://www.engatiki.org
values of β will give rise to dom!
