Re: Symlinks handled inconsistently by cd and wild card expansion

[Reuti]

Hi,

> Am 30.03.2017 um 09:13 schrieb Topi Mäenpää <topi.maenpaa@gmail.com>:
> 
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' 
> -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
> -DHAVE_CONFIG_H   -I.  -I../. -I.././include -I.././lib -D_FORTIFY_SOURCE=2 
> -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
> -Werror=format-security -Wall
> uname output: Linux topi 3.13.0-77-generic #121-Ubuntu SMP Wed Jan 20 
> 10:50:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
> 
> Bash Version: 4.3
> Patch Level: 11
> Release Status: release
> 
> Description:
> 
> The cd command remembers where I came from, and "cd .." from a
> symlinked directory comes back to the directory of the link. Wild card
> expansion works differently and always reads the link target. I
> understand the reason in general, but it would make sense that they
> behaved the same when used on the command line.
> 
> Repeat-By:
> 
> I have the following directory hierarchy (-> denotes a symlink)
> 
> .
> ./a
> ./a/1
> ./a/11
> ./a/2
> ./b
> ./b/11 -> ../a/11
> ./b/2 -> ../a/2
> ./b/3
> 
> $ cd b/2
> $ echo ../*       # I'd expect to see "../11 ../2 ../3"
> ../1 ../11 ../2
> $ cd ../*1*       # changes pwd to a/1, expected b/11
> $ cd ../..        # back to root
> $ cd b/2/../*3*   # should go to b/3
> bash: cd: b/2/../*3*: No such file or directory
> 
> Fix:
> 
> When expanding file names on the command line, don't use symlink
> targets but the actual paths (pwd or typed).

There are the options -P and -L to `pwd` and `cd`, i.e. and `cd -P ..` follows 
the path up, independent from the symlink, while the default is -L.

I don't think that changing it in general would be good, but agree that it 
might honor -P or -L. But this is hard to determine, as it depends on the 
specified command.

For now I get the impression, that both, the logical and the physical paths are 
checked.

$ tree a b
a
├── 1
├── 11
├── 2
└── in-A
b
├── 2 -> ../a/2
├── 3
├── b11 -> ../a/11
└── in-B

cd b/2
$ pwd -L
/home/reuti/b/2
$ pwd -P
/home/reuti/a/2

This is fine.

Now a)

$ cd
$ cd b/2
$ cd ../3
$ pwd -L
/home/reuti/b/3
$ pwd -P
/home/reuti/b/3

And b)

$ cd
$ cd b/2
$ cd ../11
$ pwd -L
/home/reuti/a/11
$ pwd -P
/home/reuti/a/11

Having both `cd` commands working is confusing:
Being in b/2 a "cd ../" can target both: the logical and the physical upper 
directory?

I can limit it by -P:

$ cd
$ cd b/2
$ cd -P ../3
-bash: cd: ../3: No such file or directory

This is ok, the 3 is not in a.

$ cd
$ cd b/2
$ cd -L ../11
$ pwd -L
/home/reuti/a/11
$ pwd -P
/home/reuti/a/11

This is not ok. -L should limit it to b and throw again an error and not change 
to a.

-- Reuti

signature.asc
Description: Message signed with OpenPGP using GPGMail