[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Symlinks handled inconsistently by cd and wild card expansion
From: |
Reuti |
Subject: |
Re: Symlinks handled inconsistently by cd and wild card expansion |
Date: |
Thu, 30 Mar 2017 17:55:55 +0200 |
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