Re: Notable bash $PATH behavior trivia
In a message dated: Fri, 03 Jan 2003 14:00:43 EST Derek Martin said: >It's even documented in the man page for Paul's beloved ksh 88: Two things: 1) it stands to reason that ksh, ksh88 and even pdksh would have this same behavior, since they're all direct descendants of the original 'sh. Also, the man page for 'ksh' under Linux DOES document this behavior. 2) I've been using bash at work for 9 months or so now :) (though I've had to re-implement via 'alias' what were previously ksh functions) >It's not a bug. Ben's description was dead-on. If you stick a null >path in front of a thing, you get the thing in the current >directory... And if you read the pdksh man page, it blatantly spells this out: PATH A colon separated list of directories that are searched when looking for commands and .'d files. An empty string resulting from a leading or trail ing colon, or two adjacent colons is treated as a `.', the current directory. Though I can't fault mod for not reading the ksh man page wrt a problem he thought he was having with bash :) Also, I've never encountered this behavior, since I've never had leading, trailing, or otherwise empty colons in my path, so I'd never considered it could be misleading :) -- Seeya, Paul -- Key fingerprint = 1660 FECC 5D21 D286 F853 E808 BB07 9239 53F1 28EE It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Notable bash $PATH behavior trivia
On Fri, 3 Jan 2003, at 2:00pm, [EMAIL PROTECTED] wrote: > It's not a bug. Or, at least, it is a documented bug. :-) -- Ben Scott <[EMAIL PROTECTED]> | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Notable bash $PATH behavior trivia
Useful, I didn't know that. Thanks. Erik Michael O'Donnell wrote: I just noticed that I was able to execute programs in the current directory without prefixing their names with ./ and without having . in my $PATH. After saying WTF? a number of times I finally figured out that it's related to my PATH being defined with a leading colon, sorta like this: export PATH=:/bin:/usr/bin:/usr:local/bin ...so those of you who (for security reasons) are careful to exclude "." from your $PATH need also be careful about leading colons, apparently... ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Notable bash $PATH behavior trivia
[EMAIL PROTECTED] writes: > IMNSHO, Bash breaks compatibility in so many ways Can you cite examples? I'm having difficulty recalling very many important incompatibilities. Thanks, --kevin -- Time? I've got nothing _but_ time. -- Buckaroo Banzai ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Notable bash $PATH behavior trivia
In a message dated: Fri, 03 Jan 2003 09:55:49 EST [EMAIL PROTECTED] said: > Knowing the way life works, I'm sure there are people who "do this all the >time" and "never had any trouble". Heck, just the other day, in another >forum, I got into a discussion with someone who has always used "0" instead >of "127.0.0.1" (because it was easier to type). Apparently, this actually >works with an astounding amount of software, due to the way the IP stack >gets implemented in many systems. However, it's not in any standard that I >know of, and it was causing a problem with some software he was trying to >run, but he "never had any trouble" before. *sigh* I do this all the time too :) Usually for testing things like apache: telnet 0 80 Works for simple things, but I wouldn't 'depend' upon it, IYKWIM... -- Seeya, Paul -- Key fingerprint = 1660 FECC 5D21 D286 F853 E808 BB07 9239 53F1 28EE It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Notable bash $PATH behavior trivia
IMNSHO.On Fri, 3 Jan 2003, at 9:41am, [EMAIL PROTECTED] wrote: >> Not unless the documented behavior is otherwise... this behavior is the >> normal, expected behavior of bourne-derivative shells. > > Is it that the bourne shell exhibited this seemingly buggy behavior and > bash maintained it for the sake of portability, or was this some kind of > "feature" of the original bourne shell? Both. :-) The original Bourne shell did it this way, so everything since inherited it. IMNSHO, Bash breaks compatibility in so many ways that adding one more to the list (i.e., check for and skip empty PATH components, possibly with a "set" option to re-enable the old behavior) wouldn't be such a big deal. But it ain't my call. :-) Knowing the way life works, I'm sure there are people who "do this all the time" and "never had any trouble". Heck, just the other day, in another forum, I got into a discussion with someone who has always used "0" instead of "127.0.0.1" (because it was easier to type). Apparently, this actually works with an astounding amount of software, due to the way the IP stack gets implemented in many systems. However, it's not in any standard that I know of, and it was causing a problem with some software he was trying to run, but he "never had any trouble" before. *sigh* -- Ben Scott <[EMAIL PROTECTED]> | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Notable bash $PATH behavior trivia
In a message dated: Thu, 02 Jan 2003 18:17:01 EST Derek Martin said: >Not unless the documented behavior is otherwise... this behavior is >the normal, expected behavior of bourne-derivative shells. Is it that the bourne shell exhibited this seemingly buggy behavior and bash maintained it for the sake of portability, or was this some kind of "feature" of the original bourne shell? -- Seeya, Paul -- Key fingerprint = 1660 FECC 5D21 D286 F853 E808 BB07 9239 53F1 28EE It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Notable bash $PATH behavior trivia
[EMAIL PROTECTED] (Michael O'Donnell) writes: > Interesting; I can't find such behavior specified > in the man page for BASH, so I wonder where would > such "documented" behavior actually be documented? SUSv2 says: # PATH # # The sequence of path prefixes that certain functions and utilities # apply in searching for an executable file known only by a # filename. The prefixes are separated by a colon (:) When a # non-zero-length prefix is applied to this filename, a slash is # inserted between the prefix and the filename. # A zero-length prefix # is a legacy feature that indicates the current working directory. Here's the relevant bit ^^^ # It # appears as two adjacent colons (::), as an initial colon preceding # the rest of the list, or as a trailing colon following the rest of # the list. A portable application must use an actual pathname (such # as .) to represent the current working directory in PATH. The list # is searched from beginning to end, applying the filename to each # prefix, until an executable file with the specified name and # appropriate execution permissions is found. If the pathname being # sought contains a slash, the search through the path prefixes will # not be performed. If the pathname begins with a slash, the specified # path is resolved (see pathname resolution ). If PATH is unset or is # set to null, the path search is implementation-dependent. Regards, --kevin -- The monkey-boys are evil. Lord Whorfin is supreme. ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Notable bash $PATH behavior trivia
> I'll agree this is a potential "gotcha", and I think it would, > perhaps, be better if the shell checked for and ignored empty PATH > components, but I'm sure there's somebody in the world who depends > on this behavior and would complain if it was changed. Doubtless. Nevertheless, I'd argue that if the $PATH variable has been defined, somebody (apparently) cares enough about the shell's search sequence to have specified explicit search domains and therefore, if they actually WANT a search to start in "." they have to actually mention it somewhere in the $PATH. I wasn't just hassling Derek (fun as that is) in my previous message; if anybody knows where such behavior is (ought to be) documented please do mention it. Gee, come to think of it, POSIX specifies shell behavior, doesn't it? Not that that's any guarantee this matter has been spelled out... ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Notable bash $PATH behavior trivia
On Thu, 2 Jan 2003, at 7:07pm, [EMAIL PROTECTED] wrote: > And why do you say that it's the "normal, expected" behavior? It makes sense if you think about it. The algorithm used by PATH is fairly simple: If a command you specify does not specify a path (i.e., does not contain a slash), the shell tries putting each component of the PATH variable in front of it. So, if you have an empty component, then it tries executing that command with nothing extra in front of it. That system, as always, treats that as relative to the current directory. An example may help. Say your PATH is "/bin::/usr/bin". Say you execute the command "foo". The shell will try these, in order: /bin/foo foo /usr/bin/foo I'll agree this is a potential "gotcha", and I think it would, perhaps, be better if the shell checked for and ignored empty PATH components, but I'm sure there's somebody in the world who depends on this behavior and would complain if it was changed. -- Ben Scott <[EMAIL PROTECTED]> | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Notable bash $PATH behavior trivia
>> I think this qualifies as a reportable bug... > >Not unless the documented behavior is otherwise... this behavior >is the normal, expected behavior of bourne-derivative shells. Interesting; I can't find such behavior specified in the man page for BASH, so I wonder where would such "documented" behavior actually be documented? And why do you say that it's the "normal, expected" behavior? Or do you mean that it's what YOU regard as normal and what YOU expect? I'm not exactly a newbie but I confess that I didn't expect this (though in retrospect I guess I can see some logic in it) and I don't know (authoritatively) what's "normal"... ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Notable bash $PATH behavior trivia
I offer the following snippet of code that you can stick in your
.profile -- among other things (*), I use this code to get around the
problem that you reported:
# clean up paths
if perl -e 'require 5' >/dev/null 2>&1 ; then
PATH=`perl -e 'print join ":", grep {-d && !$d{$_}++} split /:/, $ENV{'PATH'}'`
MANPATH=`perl -e 'print join ":", grep {-d && !$d{$_}++} split /:/,
$ENV{'MANPATH'}'`
fi
Place this near the end of your .profile .
* This also preserves the order of things in your path, removes
non-existent directories, and removes duplicates.
Regards,
--kevin
--
``It's a bivouac, man. They sleep here.''
- Perfect Tommy
___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Notable bash $PATH behavior trivia
I wrote: >I just noticed that I was able to execute >programs in the current directory without >prefixing their names with ./ and without >having . in my $PATH. After saying WTF? >a number of times I finally figured out that >it's related to my PATH being defined with >a leading colon, sorta like this: > > export PATH=:/bin:/usr/bin:/usr:local/bin ^ ^ I intended that to be a slash, not a colon... >...so those of you who (for security reasons) are >careful to exclude "." from your $PATH need also >be careful about leading colons, apparently... Further investigation indicates that ANY "empty" component of your $PATH definition causes this behavior, not just an "empty" first component, so this would cause it, too: export PATH=/bin:/usr/bin::/usr/local/bin I think this qualifies as a reportable bug... FYI, my $BASH_VERSION is: 2.05b.0(1)-release ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
