Hi all --
I recently had occasion to dig into the innards of how PATH and FPATH
searches are handled in ksh, looking for a problem that turned out to
be in our environment. In the process though, I learned some very
interesting things. Upon summarizing the linked list + bitmask
arrangement used for PATH & FPATH traversal, one of my astute
colleagues suggested a possible bug, which I was able to confirm.
The problem is simple: if the same directories appear in both PATH and
FPATH but in a different order, the PATH order is applied when
searching FPATH. This is a direct consequence of the use of a single
linked list to store entries in both variables, and can lead to
incorrect behavior. For example:
% echo ${.sh.version}
Version M 1993-12-28 s+
% mkdir /tmp/fp1 /tmp/fp2
% echo 'foo() { echo fp1; }' > /tmp/fp1/foo
% echo 'foo() { echo fp2; }' > /tmp/fp2/foo
% PATH=/tmp/fp1:/tmp/fp2
% FPATH=/tmp/fp2:/tmp/fp1
% typeset -fu foo
% foo
fp1
Note that /tmp/fp2 comes before /tmp/fp1 in FPATH, so I'd expect foo
to print fp2. But it's clearly loading the wrong function.
This can ALMOST be called a feature and explained away by the
documentation, but not quite:
The shell variable PATH defines the search path for the
directory containing the command. ... [E]ach directory in the
path is searched for an executable file of the given name that
is not a directory. ... If found, and this directory is also
contained in the value of the FPATH variable, then this file is
loaded into the current shell environment as if it were the
argument to the . command except that only preset aliases are
expanded, and a function of the given name is executed as
described above.
I am thoroughly confused by the intention behind this, but in any
case, it shouldn't apply here, for two reasons: (1) the files I
created are not executable, and (2) the function is defined with
"typeset -fu", so PATH searches should not apply at all.
This bug hasn't actually affected us in a real-life situation, and I
recognize it would be less than trivial to fix, so I'm not expecting
any immediate follow-up. I thought this should be noted for the future
though. Thanks!
--
Ron Isaacson
Morgan Stanley
[EMAIL PROTECTED] / (212) 276-1144
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
