On Tuesday, June 4, 2002, at 07:36 , David T-G wrote:
> ...and then drieux said...
> % % On Tuesday, June 4, 2002, at 04:58 , David T-G wrote:
> %
[..]
> % much as a peek forward to where and how he can start thinking
> % about doing things better....
>
> I suppose I should do a better job of thinking forward; at the moment I'm
> still just getting the hang of this stuff :-)
and you are so well hung so far....
[..]
> Ah -- but part of the problem is that I can hardly find the hump myself!
> I'm scrounging around just as much as he is, and doubtless much less than
> many others here, not even counting you experts who are kindly here to
> shepherd us along...
Hence why I have opted to complain about whether your
solution - as close to the mark is a good trick...
I think it's been what two or three weeks since we debated
the merits of 'more readable code' over 'tight and cool'....
We just had someone question "but what if I know the code is OK,
can I take the 'use strict' out of it then????" - and I think
most of the OldGuys have agreed - yes, technically you could, as
long as you absolutely expect never to touch that piece of code
Ever Again in this life time or the next....
[..]
> % we agree - the quality of beginners, is well, so beginning....
>
> Don't *I* know that! :-)
Hence, where once you were quietly lurking on this list with
the intent to learn how to do it right, you are now up to the
space where you posit solutions to see if they will fly....
Then you will get grey in your beard and people will call YOU
'theOldGuy' in your organization, the sun will go nova, and
it will be bright briefly.....
[..]
> % and then ask them to run it - or is this our classical concern of
> % how to make sure that the PATH contains the elements we need to
> % make sure are there - so that the rest of the script will work
> % based upon our core coding assumption that
>
> Any reason, BTW, not to just prepend the path element(s) and move on?
This is a matter of religion.... As you will note from my resume,
there was a time when Super Computers were creatures in big steel
cages, and every cycle counted..... Some of us had to know about
how things were done at the kernel internal levels when forking off
new processes - Hence it was once both fashionable and mandated
that you check before you pre-pend....
OR that you simply fascistically assert
PATH=<YourOpinionHere>
or in perl
$ENV{PATH} = <yourDogmaHere>;
since this would save time on the opening of the fork as the
internals of the shell were rounded out....
[..]
> just because I'm lazy (oh, yes, I realize that not looking first is being
> quite lazy... but is there a cost?). When the subshell is spawned off by
> perl for whatever reason, it is handed the [new] $PATH and it has to
> build its path hash table from scratch anyway, right? So what does it
> matter that one puts stuff at the front of the path, then? [Or am I lost
> again?]
let's go back a step here and remember some of the early perl
propoganda about why perl rules and /bin/sh sucks....
we can go back to the basic Pid Grovelling Problem -
THINGIE=`ps -aef | grep thingie | egrep -v grep | awk '{print $2}'`
That requires not 'one subshell' event - since there are four processes
that got spawned there - each of which will exist in a shell context
inheriting the %ENV from their parent process....
Granted I was arguing for shell scripters
THINGIE=`ps -aef | awk '/ [Tt]hingie / {print $2}'`
{ cf footnote [1] below - since it would be rude to tag the
footnote 'in the code' and confuse folks... }
which would take us down to only TWO subshells that got spawned.
a 50% reduction in process generation noise....
So you will see that I take the next 'logical step' in perl and
argue for things like
open(PS, "ps $psArg |") or die "no grovel PS Grot:$!\n";
where we fork only one child..... and grovel that data locally
inside of ourselves...
We of course move along in that same theme with the process of
being able to do our own regular expression management internally
in our own Process - rather than forking a child for each sed/awk/grep
trick we would need to use to manage 'the information' - and you
start seeing a whole not of process generation that no longer exists
as part and parcel of the code formerly done in /bin/sh....
Now imagine that each of those Processes were being forked on a
CPU at 8Mhz clock rating.... By truncating the $PATH element, and
all the other detritus that would need to be passed in the ENV,
you are not wasting time grongellating around finding all possible
executables - including the failure to find directories that exist
only on [solaris|linux|darwin|unicos|hpux|aix|<YourKultFaveOsHere>]
when not on one of those OS's....
{ hum... why ever did uncle drieux WHINE about that skanky ugly long PATH.
.... }
We are seeing some of this coming back around again in the CGI/mod_perl
world as they start noticing that the %ENV gets cluttered up with
stuff which once was thought to be a cool solution - but is now
considered to be a dangerous security risk - hence the hot buzz about
$ENV{'NastyBit'} = '';
since the undef call would be slower and .....
{ when we have more time, clearly we will want to do the
'gee uncle drieux, which is heavier, the stack frame referencing
to call a sub function or forking for processes.....'
}
[..]
> % great closure point....
[..]
> Perhaps I could have written
>
> *whimper* Doesn't it? *whimper*
>
> to be more clear :-)
would mesieur like fries with his boiled tractor????
[..]
> % cf - http://www.wetware.com/drieux/pbl/Sys/Admin/prependEnv.txt
>
> Off to look at another script... I love that these are all there but
> this business of going off to the web is such a pain :-)
wish I could come up with a more elegant solution as to how to retain
information as well as present it....
[..]
> %
> % at least I commented out the uuwho/uupath aliases since
> % we are no longer maintaining the lat/longs......
>
> Hey, at least you're moving ahead! Maybe not in the current century, but
> back within the sliding window ;-)
just because you LIBERALS are marching off to the 21st Century
is no reason we have to follow you....
ciao
drieux
---
[1] note the test case here:
vladimir: 56:] ps -aef | awk '/rlogin/ { print $0}'
drieux 19914 19894 0 07:28:33 pts/1 0:00 awk /rlogin/ { print $0}
root 18038 123 0 May 24 ? 0:00 in.rlogind
root 19892 123 0 07:27:04 ? 0:00 in.rlogind
vladimir: 57:] ps -aef | awk '/[rR]login/ { print $0}'
root 18038 123 0 May 24 ? 0:00 in.rlogind
root 19892 123 0 07:27:04 ? 0:00 in.rlogind
vladimir: 58:]
because we use a 'regular expression' in the awk we will not
see ourselves in the proctable..... hence we can 'script'
the LIST here in the form
vladimir: 58:] sh
$ for pid in `ps -aef | awk '/[rR]login/ { print $2}'`
> do
> echo "we have pid $pid"
> done
we have pid 18038
we have pid 19892
$
since we KNOW that 'THINGIE' above would be a list of ELEMENTS
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
