On 1/13/06, Bliss, Kevin <[EMAIL PROTECTED]> wrote:
>
>
> -----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.
Kevin,
There are a couple of things to note here:
1) there was never any debate about simply seeing the perl command.
That info is readily available via ps, or can be reconstructed from
@ARGV.
2) the OP is pretty clearly interested in complex command lines, and
ps will only show the command that invokes perl. Something like
$ ps aux | perl my_perl_script | mail -x [EMAIL PROTECTED]
will have a ps entry for 'ps aux', 'perl my_perl_script', and 'mail -x
...'. The complete command line will not be available anywhere.
3) in tree view, or however you want to deal with parent processes,
all subprocesses appear at the same level. If you know what to expect,
you can possibly reconstruct the command line from the ps output. In
fact on systems that assign sequential PID, you can guess pretty
safely if you can be reasonably certain where the perl invokation
appeared on the line. On modern systems that assign random PID,
though, it's trickier. And consider the following:
$ perl_script | sort &
$ echo "perl"
The shell is going to have three children, and systrace/truss is going
to be the best way to sort them out.
4) all of this OS-dependant, and doesn't have much to do with perl,
which doesn't have built-in facilities to handle the OP's problem,
although he's proabaly going to need a perl script to parse the ps or
systrace output to find what he's looking for.
--j
--------------------------------------------------
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!
