On Tuesday, June 4, 2002, at 04:58 , David T-G wrote:
volks,
the reason that the grass is moving around, is
not that there is an earthquake, merely that the elephants
are dancing the polka here - nothing serious....
[..]
> % the fine person wanted something more on the order of
> %
> % my @pathElements = split(/:/, $ENV{PATH});
> %
> % foreach my $elem (@pathElements ) {
> % print "I see \$elem <$elem> in your PATH\n";
> % }
>
> How lovely. See, I knew there was someone here who could say it better.
> I said it first, though :-)
NEEEENEEER NEEENEEER NEEENEEER!!!![1]
> I'm just happy I came up with the right
> split grammar; it took me three tries!
yes - and you left the person with a REALLY UGLY piece
of slaven portage from /bin/sh to perl - without even so
much as a peek forward to where and how he can start thinking
about doing things better....
Raw Portage is fine for folks in the boundary water canoe area,
but we really should be trying to help grease the hump of the
camel so that they can slide right on through to module maintenance.
or did you mean this recent piece
foreach $p ( split(/:/,$ENV{PATH}) ){
print "$p\n"
}
once we unGlunge it from the 'perl -e'....
> ...
> % since the person clearly wants to effectively use this in a
> % real perl script and not merely....
>
> Well, yeah, probably, but we still haven't covered where he's getting the
> PATH and what he's doing with it...
we agree - the quality of beginners, is well, so beginning....
and this cat knows enough to grok that he can use split() - just
not how SICK playing with split() can get....
the concern is parsing out 'a users $PATH variable' - the scary
part is whether the cat is going to park the script in say
/usr/local/bin
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
foo
will be found in the path - as you noted I had to quickly clean
up to make sure it was there for the pingIt problem... Where I
merely pre-pend rather than worry about the fact that such a strategy
can park extra grot in the PATH environmental - hence obliging a
'rehash' sequence' etc, etc, when invoking the child shell...
> If it's, say, a single pass through
> to look for a particular directory (but why separate instead of just m//
> I wonder in that case, so ...) instead of something where he'll need to
> store the path dirs for later, then it seems quite valid to spit through
> the elements and iterate them without storing them in an array in the
> meantime.
>
> Doesn't it?
great closure point....
One idea I was thinking of would be something along the line of
cf - http://www.wetware.com/drieux/pbl/Sys/Admin/prependEnv.txt
so you are going to buy some overHead somewhere of some type....
this is life, there are no free lunches.....
[..]
david - i'll get back to you in a bit on the ENV path
dysfunctionality - the fact that it still has the 'sgi'
there tells you how old that .login is....
at least I commented out the uuwho/uupath aliases since
we are no longer maintaining the lat/longs......
ciao
drieux
---
[1] way techNoir alternative to:
"yeah, and your code smells funny too...."
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
