David Korn wrote:
>
> > > 2. I eliminate duplicates based on device,i-node.
> >
> > That's how this whole thing started. We're heavy AFS users, and AFS
> > doesn't guarantee dev+ino uniqueness. For a long time we suspected a
> > ksh bug, but it turned out to be due to a dev+ino collision between a
> > directory in PATH and one in FPATH, leading to extremely confusing
> > results.
> >
> > I don't suppose this de-dupe algorithm is up for consideration?
> Well I wasn't aware that any file system could return the same
> device,inode for different directories. I could add an addtional
> check for the mtime.
AFS is a bit of an enigma in this respect. It's a fully distributed
filesystem hiding under a single mount point (with very good reason).
I hate to use the word "impossible", but guaranteed dev+ino uniqueness
would be extremely impractical, and collisions are frequent in very
large installations.
> > > 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.
> >
> > Yes, that's what we observed. I'm still not sure how it can be
> > construed as anything other than a bug. :-) In any case, it doesn't
> > remotely match the documentation.
> Then, this is a documention bug. Could you point out what documentation
> you are referring to.
I'm looking at the second paragraph of the Execution section of
ksh(1). There's some mention of what happens if a directory is in both
PATH and FPATH, but the sixth sentence in this paragraph (starting
"Otherwise, each directory") suggests that the search algorithm looks
only for an "executable file", and if the file found is not
executable, then the rest of the paragraph should not apply.
The only other reference to FPATH is in the Parameter Expansion
section, under "The following variables are used by the shell", where
FPATH is defined as "The search path for function definitions". While
it doesn't explicitly say that the directories are searched in order,
I'd argue that it's implied. In any case, it never says anywhere that
the order in which FPATH entries are searched can be affected by PATH,
especially when the target file is not executable.
I still think this is a bug bug, not a doc bug! More below:
> > % mkdir /tmp/fp1 /tmp/fp2
> >
> > % echo 'foo() { echo fp1; }' > /tmp/fp1/foo
> > % echo 'FPATH=/tmp/fp1' > /tmp/fp1/.paths
> The directory that you put in FPATH will be placed immediately after
> the directory .paths is found in. However, in this case
> PATH contains /tmp/fp1, and the .paths files adds /tmp/fp1 which
> is then eliminated as a duplicated. The purpose of .paths
> is to add an FPATH directory to a directory containing executables
> that will follow the directory with executables.
> Thus,
> % echo 'FPATH=/tmp/fp1/fundir' > /tmp/fp1/.paths
> would have added /tmp/fp1/fundir right after /tmp/fp1.
Ok, I see. Also not covered in the documentation.
This has sort of wandered off the original point though, about this:
PATH=/a:/b
FPATH=/b:/a
yielding an effective FPATH of /a:/b. I think that's simply incorrect.
The rationale for this seems to be:
> > > 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
However, it seems to be entirely unrelated. If you want a function
with the same name as an existing command, the only way to do it is
with a .paths file. Once you have the .paths file, merging the two
lists no longer buys you anything.
So when you zip the two into a single linked-list, how does it help
with the above? And what would be wrong with this:
1. Search PATH in order
a. If an executable is found, then run it
b. If .paths has an FPATH= line, then search it immediately for
a function file, and load/run it if found
2. Search FPATH in order
?
--
Ron Isaacson
Morgan Stanley
[EMAIL PROTECTED] / (212) 276-1144
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
