Re: Bash handling of ENOENT on missing files and directories

[PePa]

On 10/09/2017 05:30 AM, Jonny Grant wrote:
Fair enough. I agree it has been around for longer, but meant that POSIX 
standardized on that limitation, and didn't offer a better solution that 
clarified, eg ENOENTF ENOENTD


I'm guessing not making the distinction saved a bit of CPU.

yes, a clearer errno value, for files, and separate for directories 
would be ideal.


Would have been better.


Has anyone ever wanted to "cd" into a file?


$ cd file
-bash: cd: file: Not a directory

In this case it tested whether 'file' is a directory. When trying 'cd' 
into 'missingdir', the result is that an entry 'missingdir' couldn't be 
found, whether file or directory. This is actually more informative.


Peter

Re: Bash handling of ENOENT on missing files and directories

[Jonny Grant]

Hello Bob
Thank you for your reply

On 15/09/17 02:57, Bob Proulx wrote:

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


Fair enough. I agree it has been around for longer, but meant that POSIX 
standardized on that limitation, and didn't offer a better solution that 
clarified, eg ENOENTF ENOENTD





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.


yes, a clearer errno value, for files, and separate for directories 
would be ideal.




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.


Most programs already use their own messages. eg GEdit :-
Could not find the file “/home/jonny/env.txt”.
Please check that you typed the location correctly and try again.
[Retry] [Cancel]



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. :-)


Has anyone ever wanted to "cd" into a file?


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.)


yes, I know directories are a kind of special file, but from a user's 
perspective, nowadays they are just folders.



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.

   https://en.wikipedia.org/wiki/Unix_file_types
   "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.


They are both clearer. Like you say "No 

Re: Bash handling of ENOENT on missing files and directories

[Jonny Grant]

On 17/09/17 06:25, Robert Elz wrote:

 Date:Mon, 11 Sep 2017 22:49:47 +0300
 From:Jonny Grant 
 Message-ID:  

   | How can an easy update to clarify message "No such file or directory"
   | introduce a bug?

That's easy ... because it is not just that one message, you change that
to "no directory" (or something) in the case of the cd command, then someone
has to come along and produce the Polish, French, Mandarin, Tagalog, Malay,
Afrikaans, Spanish, Thai,  versions of that new message, and it is
entirely possible that one or more or those won't end up saying exactly
what it should say.   A bug...

The sys_errlist[] messages are translated already, and widely used, so
any errors in those translations should have already been found and fixed.

kre


Hello Robert

Thank you for your reply. I've proposed at the end of this message an 
easy solution which doesn't require any additional translation.


In the case where a file exits, the message is appropriate:

$ touch myfile.txt
$ cd myfile.txt
bash: cd: myfile.txt: Not a directory

* This is because opendir sets errno to be ENOTDIR

In the case where the directory doesn't exist, opendir returns ENOENT 
and the message is not appropriate


$ cd mymissingdir
bash: cd: mymissingdir: No such file or directory



Yes, I appreciate that because the limitation ENOENT doesn't 
differentiate, it means every application that wants to be multilingual 
could have a bad translation if the developers don't treat this change 
professionally.


Better if it was fixed at in the UNIX/POSIX standards, but alas I can't 
imagine that ever happening, so then better to resolve this in each 
package in my view, which is why I raised it.


Would have been better to have ENOENT split into two different codes by 
the standards, one for files and one for directories. ie open() set 
ENOENTF and opendir() set ENOENTD



POSIX man pages:

http://pubs.opengroup.org/onlinepubs/009695399/functions/opendir.html
http://man7.org/linux/man-pages/man3/opendir.3.html


The easiest workaround is after opendir() to check for ENOENT. You don't 
need to do any additional translations.


if(NULL == dir)
{
int err = errno;
if(ENOENT == err)
{
/* Aathis is opendir(), update error to dir, so clear */
err = ENOTDIR;
}

printf("opendir: %s\n", strerror(err));
}

I'm sure you all know this better than myself. We shouldn't be fearful 
of changing code. That prevents projects moving forward. Testsuites can 
be used to give added confidence in changes.


Cheers, Jonny

Re: Bash handling of ENOENT on missing files and directories

[Robert Elz]

Date:Mon, 11 Sep 2017 22:49:47 +0300
From:Jonny Grant 
Message-ID:  

  | How can an easy update to clarify message "No such file or directory" 
  | introduce a bug?

That's easy ... because it is not just that one message, you change that
to "no directory" (or something) in the case of the cd command, then someone
has to come along and produce the Polish, French, Mandarin, Tagalog, Malay,
Afrikaans, Spanish, Thai,  versions of that new message, and it is
entirely possible that one or more or those won't end up saying exactly
what it should say.   A bug...

The sys_errlist[] messages are translated already, and widely used, so
any errors in those translations should have already been found and fixed.

kre

Re: Bash handling of ENOENT on missing files and directories

[Bob Proulx]

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.

  https://en.wikipedia.org/wiki/Unix_file_types
  "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.

Bob

Re: Bash handling of ENOENT on missing files and directories

[Jonny Grant]

On 11/09/17 20:58, Bob Proulx wrote:

Jonny Grant wrote:

Greg Wooledge wrote:

The wording is taken directly from perror() and related library calls,
as translated for your locale.


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?


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?


Jonny

Re: Bash handling of ENOENT on missing files and directories

[Bob Proulx]

Jonny Grant wrote:
> Greg Wooledge wrote:
> > The wording is taken directly from perror() and related library calls,
> > as translated for your locale.
> 
> 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.

> 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.

Bob

Re: Bash handling of ENOENT on missing files and directories

[Gerard Seibert]

On Tue, 5 Sep 2017 10:57:20 -0400, Greg Wooledge stated:

>Keep following this slippery slope and you get Microsoft Windows error
>messages that say nothing useful at all.  "An error has occurred."

True, to a point. However, launching the "C:\WINDOWS\System32\eventvwr.exe"
application and then clicking on the Windows Log you want to investigate, gives
quite a bit of useful information. Perhaps, not as much as running a debugger,
but more than just a simple error code.

-- 
Gerard

Re: Bash handling of ENOENT on missing files and directories

[Chet Ramey]

On 9/5/17 10:57 AM, Greg Wooledge wrote:

> Keep following this slippery slope and you get Microsoft Windows error
> messages that say nothing useful at all.  "An error has occurred."

I'd like to think we've evolved from ed's single all-purpose error
message: `?'.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Bash handling of ENOENT on missing files and directories

[Greg Wooledge]

On Tue, Sep 05, 2017 at 12:18:40AM +0300, Jonny Grant wrote:
> > > $ cd missingdir
> > > bash: cd: missingdir: No such file or directory

> 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 find it completely clear.  I *prefer* seeing this error string over
some alternative spelling, because when I see this string, I know
*exactly* what it means.

When I see "No such file" or whatever, then I don't know exactly what
it means, other than someone is trying to dumb down the software to
"help" newbies in a way that is not actually helpful.

Keep following this slippery slope and you get Microsoft Windows error
messages that say nothing useful at all.  "An error has occurred."

Re: Bash handling of ENOENT on missing files and directories

[Jonny Grant]

On 29/08/17 16:35, Chet Ramey wrote:

On 8/29/17 8:40 AM, Jonny Grant wrote:

Hello

Could bash have some better handling of ENOENT for directories that don't
exist and files that don't exist?


Better than the error message the OS associates with that errno? The one
that comes straight from strerror()?


Hi Chet, yes perhaps like GNU Objdump does:


$ objdump -d missing.elf
objdump: 'missing.elf': No such file

$ objdump -d mydir
objdump: Warning: 'mydir' is not an ordinary file

Cheers, Jonny

Re: Bash handling of ENOENT on missing files and directories

[Chet Ramey]

On 8/29/17 8:40 AM, Jonny Grant wrote:
> Hello
> 
> Could bash have some better handling of ENOENT for directories that don't
> exist and files that don't exist?

Better than the error message the OS associates with that errno? The one
that comes straight from strerror()?

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Bash handling of ENOENT on missing files and directories

[Greg Wooledge]

On Tue, Aug 29, 2017 at 03:40:54PM +0300, Jonny Grant wrote:
> (B) is good, but (A) and (C) are problematic below.
> 
> A)
> $ cd missingdir
> bash: cd: missingdir: No such file or directory

How is this a problem?  It seems completely clear to me.  It tells
you what program generated the error, what the program was trying to
do, what argument was given, and what the result was.

The wording is taken directly from perror() and related library calls,
as translated for your locale.

wooledg:~$ grep -r 'No such file' /usr/include
/usr/include/asm-generic/errno-base.h:#define   ENOENT   2  /* No 
such file or directory */
/usr/include/rpcsvc/nfs_prot.x: NFSERR_NOENT=2, /* No such file or 
directory */

The magic phrase "No such file or directory" tells the aware reader
that some system call failed with errno set to ENOENT.

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

Again, I'm not seeing the problem.