cc: [email protected]
Subject: Re: Re: [ast-users] PATH/FPATH ordering problem
--------
> 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?
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.
>
> > 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.
>
> > 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
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.
>
> % 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?
The .paths file doesn't dow anything in this case.
You didn't make the foo in /tmp/fp1 executable so it didn't find it.
>
> --
> Ron Isaacson
> Morgan Stanley
> [EMAIL PROTECTED] / (212) 276-1144
>
David Korn
[EMAIL PROTECTED]
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
