cc: [EMAIL PROTECTED]
Subject: Re: [ast-users] PATH/FPATH ordering problem
--------
> 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
You have it mostly correct, but it is a bit more complex than this.
Let me give you a more complete story.
In ksh88, the shell first searched for commands in PATH and
then searched for functions in FPATH; both in the order specified
by the variable. Since this did not allow a function with
the same name as an existing command, I added
autoload=typeset -fu
which would bypass the PATH search and only look for functions.
In ksh93, I decided to have a unified search mechanism.
What would have been best would be if there was a way to distinguish
whether the name found in a PATH directory was a program or
a function. Since this was not possible, I did the following:
1. I concatonate PATH and FPATH to get the list of search
directories.
2. I eliminate duplicates based on device,i-node.
3. Any directory that is both in PATH and FPATH is considered
to be a function defintion directory.
4. In ksh93m, I introduced the .paths file. Any directory
in PATH that contains a file name .paths looks for a line
containing FPATH= and inserts the specified directory
into the PATH at this point. A relative value of FPATH=
is taken to be with respect to the directory containing
the .paths file.
5. autoload (typeset -fu) searches the subset of directories
that are function definition directories.
If PATH does not contain any directories that are also in FPATH
then ksh93 should be compatible with ksh88.
If there are directories from FPATH in PATH, then their order in PATH
will override their order in FPATH as far as searching for functions.
The ksh93 mechanism is more flexible and eliminates the need for autoload.
The addition in ksh93m allows developers to construct a collection
of programs and functions and advertise them as a single
directory that they need to add to their PATH.
The ksh93t version, soon to be released, adds to ability to
define and use types or classes. Each type definition creates
a new builtin declaration command named by the type.
The current search mechanism allows type definitions to be placed
in FPATH directories and loaded on first reference so that
libraries of types can be developed.
David Korn
[EMAIL PROTECTED]
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
