cd"": Shouldn't it fail?

[jwo]

Hello,

(If you don't want to read through this stuff, see the end or grep for
 word ``opinion''.)

I started exploring details of file handling on Linux and similar
systems and wondered what ``cd ""'' will do.

I was experimenting with various shells. Let's start with some non-GNU
shells on one FreeBSD system. (The shell prompts were replaced with
``$'' to make the examples more readable.)

ksh93:

    $ ksh93 --version
      version         sh (AT&T Research) 93u+m/1.1.0-alpha+e2f62ff7/MOD 
2023-12-28h
    $ cd ""
    ksh93: cd: bad directory

tcsh (2 versions):

    $ tcsh --version
    tcsh 6.22.04 (Astron) 2021-04-26 (x86_64-amd-FreeBSD) options 
wide,nls,dl,al,kan,sm,rh,color,filec
    $ tcsh --version
    tcsh 6.18.01 (Astron) 2012-02-14 (x86_64-unknown-linux) options 
wide,nls,dl,al,kan,sm,rh,color,filec

    $ cd ""
    : No such file or directory.

    # Another one:

ksh:

    $ ksh --version
    GNU bash, verze 5.1.8(1)-release (x86_64-unknown-freebsd13.0)
    ~~snip~~

Whoa, It's bash! Let's try it later.

zsh:

    [user@host]/% pwd
    /
    [user@host]/% cd ""
    [user@host]/% pwd
    /
    [user@host]/% cd /tmp
    [user@host]/tmp% cd ""
    [user@host]/tmp% pwd
    /tmp

                               *   *   *

And now the behavior of the Bash. I tried these versions:

    GNU bash, version 4.2.46(2)-release (x86_64-redhat-linux-gnu)
    GNU bash, version 5.1.8(1)-release (x86_64-unknown-freebsd13.0)
    GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)
    GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu)
    GNU bash, version 5.2.21(1)-release (x86_64-pc-linux-gnu)
    GNU bash, version 5.2.26(0)-release (amd64-portbld-freebsd13.2)

The behavior is the same as for the zsh. It simply leaves the working
directory unchanged.

    $ cd /
    $ cd ""
    $ echo $?
    0
    $ pwd
    /

POSIX Programmer's Manual (cd(1p) manpage) says this:

      [9 unrelated special cases]

      10. The cd utility shall then perform actions equivalent to the
           chdir() function called with curpath as the path argument. If
           these actions fail for any reason, the cd utility shall
           display an appropriate error message and the remainder of
           this step shall not be executed. [...]

So, it should do the same thing a chdir(""). I interpret it as ``it
shall fail if chdir("") would fail''. Let's try that:

    $ >a.c cat
    int main(){chdir("");perror("uwu");}
    $ gcc a.c
    [gcc's warnings]
    $ ./a.out
    uwu: No such file or directory

(I've also checked it better. The error is really ENOENT.)

So, the chdir("") call fails. Have a look at
manpages. path_resolution(7) says:

    Empty pathname
        In the original UNIX, the empty pathname referred to the
        current directory.  Nowadays POSIX decrees that an empty
        pathname must not be resolved successfully.  Linux
        returns ENOENT in this case.

                                      [from Linux man-pages 6.05.01]

So, the behavior of Bash corresponds to the *old* behavior of chdir(2).

Why it is not the same? Let's explore:

    $ cd /tmp
    $ strace sh 2>&1 -c 'cd ""' | grep chdir
    chdir("/tmp")                           = 0

Well, the shell does some magic with the pathname before passing it
finally to the chdir(2). (After examining the source code of the current
bash version, it just concatenates the empty string to the working
directory path in this case.)

My opinion on this is that the ``cd ""'' command should fail with an
error in this case. The zsh is the only POSIX-compatible or
POSIX-shell-like shell that was available on machines to which I have
access that exhibits this behavior.

I think that the empty argument can be relatively frequently caused by
substitution with some undefined variable -- it's better to warn the
user than to perform actions in the wrong directory.

We risk that this will break some badly written scripts.

I propose to make Bash report an error when the user attempts to cd into
empty string, possibly with an shopt option that allows changing
behaviour of the cd back to the current one -- silently ignoring the
command.

                          Jiri Wolker.