Hi Bruno,
my purpose is not to refactor the entire system. no even to change the
chdir()
function which has a good reason to behave as it does.
I am just saying that calling "realpath" on "." or on "$PWD" should always
have the same result. I face a case where it si not true. can you see it is
a bug ?
my gnulib patch-proposal fix that bug.
the coreutils patch-proposal test than fix.
can you help me publish those 2 patches ?
optionally, how can I add a bash test-script in gnulib ?
thank you for your help.
Patrick
On 02/11/2025 11:28, Bruno Haible wrote:
Hi,
Patrick GARCIA wrote:
example script :
{
mkdir -p /tmp/phisical_dir
ln -sf phisical_dir /tmp/logical_dir
cd -L /tmp/logical_dir
pwd
OK, now I see what you mean.
"cd -L" gives the user the impression that
1) file name resolution of ".." is a syntactic operation
(when in fact, in Unix, it is an operation on inodes),
2) the current directory is a file name (when in fact, it
is the inode of a directory).
And what you want is that tools like 'realpath' and others
follow this simplified world view.
While I do agree that this simplified world view is sometimes
useful, such as when a user needs to create a symlink to a
different partition:
$ ln -s /media/big-partition/Videos $HOME/Videos
$ cd Videos
$ cd ..
it also creates semantic problems.
$ mkdir -p /tmp/phisical_dir
$ ln -sf phisical_dir /tmp/logical_dir
$ echo > /tmp/phisical_dir/data
$ cd -L /tmp/logical_dir
$ pwd
/tmp/logical_dir
$ /bin/pwd
/tmp/phisical_dir
$ realpath .
/tmp/phisical_dir
$ ls data
data
$ mkdir -p /tmp/phisical_dir2
$ rm -f /tmp/logical_dir; ln -sf phisical_dir2 /tmp/logical_dir
$ pwd
/tmp/logical_dir
$ ls data
data
Here, in your world view, the file 'data' should not exist any more,
because /tmp/logical_dir/data does not exist. But the shell has not
noticed that /tmp/logical_dir was changed. If your force the shell to
notice it, it works:
$ cd -L /tmp/logical_dir
$ pwd
/tmp/logical_dir
$ ls data
ls: cannot access 'data': No such file or directory
Another way to view this is: chdir() is a system call, and the kernel
keeps track of the current directory as an inode, not as a file name.
In theory, Gnulib could override chdir() so that it keeps track of
both the file name (that you call "logical") and the inode. But when
they no longer agree, like in the case above, the semantic problem
remains.
So, in order to maintain that simplified world view, the entire
system should work with file names all over the place and resolve
all levels of a file name only when it is created/accessed.
This approach was rejected for efficiency reasons when Unix was
first implemented.
Bruno
