-----Original Message-----
From: Jay Savage [mailto:[EMAIL PROTECTED]
Sent: Friday, January 13, 2006 11:35 AM
To: Grant Jacobs; beginners perl
Subject: Re: CLOSING Re: Obtaining complete Unix command line that evoked
script as string
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!
Grant, Jay,
I am not a perl expert but know a little about unix. Unix provides tools to
track significantly more than suggested, without the need for the expertise of
using truss like tools. The ps command itself provides significantly more than
implied. If the command is not a daemon or does not spawn another command and
die than you can probably find the information you need via the ps command with
the right flags. Most unix varieties also provide some proc tools like ptree,
pmap, etc. Start with man ps. There are usually two versions (though some
implementations combine them) of ps. They both provide similar information but
have different flags. Both offer a -o for specifying fields to display. For
most unixes you will probably get what you need from (ps -e -o
uid,pid,ppid,args):
$ perl -e 'print `ps -e -o uid,pid,ppid,args`;'
UID PID PPID COMMAND
0 0 0 sched
...
905404 15635 14030 perl -e print `ps -e -o uid,pid,ppid,args`;
You will also get a bunch stuff to filter (-e is every process running). The
ppid is the parent pid so you can climb the tree to the highest level process
still active.
------------------------------------------------------------------------------
This email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else,
unless expressly approved by the sender or an authorized addressee, is
unauthorized.
If you are not the intended recipient, any disclosure, copying, distribution or
any action omitted or taken in reliance on it, is prohibited and may be
unlawful. If you believe that you have received this email in error, please
contact the sender, delete this e-mail and destroy all copies.
==============================================================================
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
