[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bash handling of ENOENT on missing files and directories

From: Bob Proulx
Subject: Re: Bash handling of ENOENT on missing files and directories
Date: Thu, 14 Sep 2017 19:57:20 -0600
User-agent: NeoMutt/20170609 (1.8.3)

Jonny Grant wrote:
> Please keep my email address in any replies
> Bob Proulx wrote:
> > Jonny Grant wrote:
> > > Yes, it's a known limitation of POSIX that it uses a shared error code for
> > > both files and directors, ENOENT. Which without programmers handling and
> > > checking the stat() flags, means the error isn't completely clear in the
> > > case where a file or dir does exist.
> > 
> > I don't see how POSIX is involved in this.  Blaming POSIX is a
> > complete non-sequitur here.
> Why do you feel it isn't?

The "No such file or directory" message I see in the Unix v7 code
circa 1979 and therefore appeared at least that early but probably was
there since the beginning.  That predates the first POSIX standard by
many years.

File errlst.c:
char    *sys_errlist[] = {
        "Error 0",
        "Not owner",
        "No such file or directory",

File errno.h:
#define ENOENT  2

> > > I imagine we have spoken already for longer about this, than it would have
> > > been to fix it.
> > 
> > I see no bug to fix here.  However I fear that trying to fix an
> > imaginary one would introduce a bug here.
> How can an easy update to clarify message "No such file or directory"
> introduce a bug?

Because "No such file or directory" is the exact error message that
corresponds to the error returned by the OS kernel as defined by the
system in the /usr/include definition file which is used by all
programs.  It is an important commonality.  All programs should say
the same thing for that error.

If every program created a different error message for that error then
it would be hard to learn what each and every program said for each
and every individual possible error.  OMG!  That would be horrible.
Changing it to make it something different would obscure the error
that is being returned by the OS.  It would make this one program say
something different for that error than other programs.  Different
makes it harder to understand.

Let's look at your cases again.

> $ cd missingdir
> bash: cd: missingdir: No such file or directory

Why do you think that is undesirable?  That is the system error.  The
requested "missingdir" to change directory to failed because there is
no entry by that name, uh, no such file or directory by that name. :-)

> Likewise, software that deals with directories, or in the case of
> "cd" in bash, trying to change directory, can very easily report "No
> such directory"

I think some of the problem might be that you are thinking that
directories are not files.  But in Unix like systems everything is a
file.  (And in a Linux like system everything is a file system.  It's
a joke but also with some truth to it.)

If I were writing that error message I may have said "No such entry"
since that is the literal error.  Meaning directory entry.  But I
could see having written "No such file", stopped there without the
directory hint, and defended it as being correct because everything is
a file.  But I forgive them for helping the user out a little by
hinting that no files, not even special files such as directories,
were found.  Directories are files.  They are special files.  But
files just the same.

  "The most common special file is the directory."

Let's try some other shells to see what error messages they produce.

$ ksh
$ cd nonexistent
ksh: cd: nonexistent: [No such file or directory]

$ mksh
$ cd nonexistent
mksh: cd: /home/rwp/nonexistent: No such file or directory
$ ^D

$ zsh
% cd nonexistent
cd: no such file or directory: nonexistent

$ csh
% cd nonexistent
nonexistent: No such file or directory.
% exit

We can also try a programming solution too just to double check what
error message is provided using a one-liner.

  $ perl -e 'chdir("doesnotexist") or die "$!\n";'
  No such file or directory

It is good that everyone uses the same error messages.

Let's look at your other case.

> $ ./main
> -bash: ./main: No such file or directory

$ ksh
$ ./nonexistent
ksh: ./nonexistent: not found [No such file or directory]

$ mksh
$ ./nonexistent
mksh: ./nonexistent: not found

$ zsh
% ./nonexistent
zsh: no such file or directory: ./nonexistent

$ csh
% ./non-existent
./non-existent: Command not found.
% exit

It looks like mksh and csh are the odd ones out here.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]