Hi David --
Thanks for the information. Incidentally:
> 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?
> 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.
> 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.
Actually, I'm not even able to make that work. I understand the
problem you've described here:
> 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
but with or without the use of .paths, I still can't seem to do that.
For example:
% mkdir /tmp/fp1 /tmp/fp2
% echo 'foo() { echo fp1; }' > /tmp/fp1/foo
% echo 'FPATH=/tmp/fp1' > /tmp/fp1/.paths
% cat > /tmp/fp2/foo
#!/bin/sh
echo fp2
% chmod +x /tmp/fp2/foo
% PATH=/tmp/fp1:/tmp/fp2
% FPATH=/tmp/fp1
% foo
fp2
Shouldn't I get the function in /tmp/fp1/foo here? /tmp/fp1 is first
in PATH and is also in FPATH, and it has a .paths file. Either or both
of these should make it a program-or-function directory, right?
--
Ron Isaacson
Morgan Stanley
[EMAIL PROTECTED] / (212) 276-1144
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
