I'm going to trial a simplistic shell-based solution initially and
later work on anything fancier (see at the end of the message).
Thanks for the excursions and excuse my using the wrong forum. I'll
just roll all my replies into one post and then stop taking over this
forum :-)
Im comming in a bit late to this thread but maybe this will help
In the users .profile add the line
script /tmp/cmdfile
Almost! In my hands, tail -1 on this file gives the _previous_
command line, not the current one; the command lines are obviously
added after they are completed (fair enough). It did sound good at
first, though :-) In fact when I first started on this thing I
thought of this, but couldn't for the life of me remember the
command, then promptly forgot all about it as I explored other ideas.
At 11:19 AM -0600 13/1/06, JupiterHost.Net wrote:
script.pl -p 100 -in foo -out foo.txt
now in side open foo and put it in foo.txt
Originally my previous post had an explanation of why I really did
want the pipes and redirects. I dropped it as I didn't want to be
long-winded. Short version: large intermediate data files can be
avoided by using pipes. Likewise, I frequently use multiple steps of
filtering if the intermediates aren't useful. Its just not practical
with the data I process to save every intermediary file. Many of the
files are one to several Gb in size. Pipes are nice things in my
book :-)
At 2:34 PM -0500 13/1/06, Jay Savage wrote:
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
I can see the logic; makes perfect sense from a process point of
view. User-level traceability is valuable from another point of view,
though ;-) , and philosophically at least can use slightly different
logical units.
Let's philosophise for a moment :-) If you think like a user (i.e.
not a Unix geek) the "|" and ">" in
more from | doStuff.pl > results
don't demarcate process boundaries, but are indicators of _how_ IO is
to work. So many users will perceive:
echo -n "Starting...." ; more infile | action.pl > results ; echo "done!"
as three logical actions, not five, which in at least one sense is
true. This argument comes slightly unstuck with pipes to pipes,
etc., but the point is its just another slant on the old virtual vs.
actual thing. The user more inclined to think in units of one source
-> action -> target activity, than the underlying processes the shell
achieves it with. My traces are aimed at users, so they have to work
at their level. But this philosophising is not going to solve this!
Philosophy does have its limits... :-)
At 2:06 PM -0600 13/1/06, Leif Ericksen wrote:
OK so this is to say:
$ phd.pl echo -n How am I going to get all this information to appear
is the ENTIRE command that you enter to run you program and you want all
that information to be able to appear on the screen?
Um (trying to be nice here), I know you mean well with your long post
and I appreciate it must have taken time to write all that (!), but
you're way off target Leif; others have got the right idea. You're
also misjudging me ;-)
At 2:34 PM -0500 13/1/06, Jay Savage wrote:
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}.
Thanks for the example and you're quite right of course. I was aware
of this, I just didn't want to cloud my question with too many other
issues (one question at a time and all that.). Strictly speaking I
might want some of the shell's arguments, if any where given. And of
course $ENV{SHELL} !
At 10:36 PM -0500 13/1/06, Jay Savage wrote:
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.
Thanks, that actually answers something I was going to look into!
Prescience... ;-)
I should explore ps more, looks as if it might be useful. It might
be a bit heavy-weight for my initial pass at it though; if possible I
prefer first attempts to be simple, even if clumsy, and work up the
more complex approaches against the simpler one(s).
At 8:54 AM -0500 13/1/06, zentara wrote:
Try the news access to the maillist at nntp.perl.org
Thanks for that, I'll keep it for the future. I started by looking at
the list of lists on http://lists.cpan.org/, FWIW.
Cheers,
Grant
Working solution (for now), if anyone cares for it. Details omitted, obviously!
1. alias the scripts you want in your .profile (etc) to always pass
"`history 1`" as the first parameter, e.g.
alias doStuff='doStuff -thiscmdline"`history 1`" '
2. have the scripts verify that the first argument leads off with
'-thiscmdline' to verify that things have been set up (or that it
leads with some argument that expressly switches this off). I have my
own module for argument processing already, so this can conveniently
hide this processing from the main bodies of the scripts. The scripts
can then call on the Unix/argument interface module to hand over the
current command-line without having to do anything in processing it.
3. Get %ENV and any other bits needed to complete the picture,
likewise via my Unix/argument interface module.
4. Write a module which filters input files by detecting and
stripping/recording the trace header. You need this if outputs are to
be used transparently as inputs without each script processing them
having to deal with the trace headers themselves. I'll put all the
functionality in here and have my Unix/arg module call on this to do
the real work.
--
-------------------------------------------------------------------
Grant Jacobs Ph.D. BioinfoTools
ph. +64 3 478 0095 (office, after 10am) PO Box 6129,
or +64 27 601 5917 (mobile) Dunedin,
[EMAIL PROTECTED] NEW ZEALAND.
Bioinformatics tools: deriving knowledge from biological data
Bioinformatics tools - software development - consulting - training
15 years experience in bioinformatics ready to solve your problem
Check out the website for more details: http://www.bioinfotools.com
The information contained in this mail message is confidential and
may be legally privileged. Readers of this message who are not the
intended recipient are hereby notified that any use, dissemination,
distribution or reproduction of this message is prohibited. If you
have received this message in error please notify the sender immed-
iately and destroy the original message. This applies also to any
attached documents.
