Re: No such file or directory
On 01/02/2013 02:25 AM, Mike Frysinger wrote: On Tuesday 01 January 2013 15:10:00 Chet Ramey wrote: On 1/1/13 2:49 PM, Aharon Robbins wrote: Michael Williamson wrote: I have a complaint. Apparently, when unknowingly attempting to run a 32-bit executable file on a 64-bit computer, bash gives the error message "No such file or directory". That error message is baffling and frustratingly unhelpful. Is it possible for bash to provide a better error message in this case? It's not Bash. That is the error returned from the OS in errno when it tries to do an exec(2) of the file. Bash merely translates the error into words. FWIW, the file in question that's not found is either the 32-bit version of the loader or one of the required 32-bit libraries, not the binary itself. it's the ldso missing. if a lib was missing, the ldso would spit out a useful message telling you exactly which lib could not be found. at least, that's the standard Linux (glibc/uclibc/etc...) behavior. $ ./a.out: error while loading shared libraries: libfoo.so: cannot open shared object file: No such file or directory -mike The patch stated in http://lists.gnu.org/archive/html/bug-bash/2002-03/msg00052.html is applied in Fedora. Chet, is it possible to apply it to source? RR
Re: No such file or directory
Hi Aharon, Thanks for your explanation. Now I have another question. Why is the error message for ENOENT simply "No such file or directory", when the man page for execve has this complete description: "The file filename or a script or ELF interpreter does not exist, or a shared library needed for file or interpreter cannot be found."? Thanks, -Mike On 1/1/13, Aharon Robbins wrote: > In article , > Michael Williamson wrote: >>Hi, >> >>I have a complaint. Apparently, when unknowingly attempting to run a >>32-bit executable file on a 64-bit computer, bash gives the error message >>"No such file or directory". That error message is baffling and >> frustratingly >>unhelpful. Is it possible for bash to provide a better error message >>in this case? >> >>Thanks, >>-Mike > > It's not Bash. That is the error returned from the OS in errno when > it tries to do an exec(2) of the file. Bash merely translates the > error into words. > > Depending on the distro, it's usually not too hard to install the 32 bit > compatibility files to support 32 bit executables. The "enterprise" > distibutions tend to do that by default, whereas the more free ones > (Fedora, Ubuntu, ...) require that you do it yourself. > > I agree, it's confusing. But it's a decision made by the kernel guys, > not Bash. > > HTH, > > Arnold > -- > Aharon (Arnold) Robbins arnold AT skeeve DOT com > P.O. Box 354 Home Phone: +972 8 979-0381 > Nof AyalonCell Phone: +972 50 729-7545 > D.N. Shimshon 99785 ISRAEL >
Re: No such file or directory
On 01/02/2013 07:28 AM, Michael Williamson wrote: > Hi Aharon, > > Thanks for your explanation. Now I have another question. > Why is the error message for ENOENT simply > "No such file or directory", when the man page for execve > has this complete description: > "The file filename or a script or ELF interpreter does not exist, > or a shared library needed for file or interpreter cannot be > found."? Because that's what strerror() in your libc reports. It's not bash's fault if libc produces a shorter message (correct in the common case) than what the man pages says is possible in the more comprehensive case. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: No such file or directory
On 01/02/2013 03:31 PM, Eric Blake wrote: On 01/02/2013 07:28 AM, Michael Williamson wrote: Hi Aharon, Thanks for your explanation. Now I have another question. Why is the error message for ENOENT simply "No such file or directory", when the man page for execve has this complete description: "The file filename or a script or ELF interpreter does not exist, or a shared library needed for file or interpreter cannot be found."? Because that's what strerror() in your libc reports. It's not bash's fault if libc produces a shorter message (correct in the common case) than what the man pages says is possible in the more comprehensive case. I think the best would be if kernel provides more informations. RR
Re: No such file or directory
On Wednesday 02 January 2013 09:47:10 Roman Rakus wrote: > On 01/02/2013 03:31 PM, Eric Blake wrote: > > On 01/02/2013 07:28 AM, Michael Williamson wrote: > >> Thanks for your explanation. Now I have another question. > >> Why is the error message for ENOENT simply > >> "No such file or directory", when the man page for execve > >> has this complete description: > >> "The file filename or a script or ELF interpreter does not exist, > >> or a shared library needed for file or interpreter cannot be > >> found."? > > > > Because that's what strerror() in your libc reports. It's not bash's > > fault if libc produces a shorter message (correct in the common case) > > than what the man pages says is possible in the more comprehensive case. > > I think the best would be if kernel provides more informations. that ship has already sailed -mike signature.asc Description: This is a digitally signed message part.
Re: No such file or directory
On Wednesday 02 January 2013 07:07:49 Roman Rakus wrote: > On 01/02/2013 02:25 AM, Mike Frysinger wrote: > > On Tuesday 01 January 2013 15:10:00 Chet Ramey wrote: > >> On 1/1/13 2:49 PM, Aharon Robbins wrote: > >>> Michael Williamson wrote: > I have a complaint. Apparently, when unknowingly attempting to run a > 32-bit executable file on a 64-bit computer, bash gives the error > message "No such file or directory". That error message is baffling > and frustratingly unhelpful. Is it possible for bash to provide a > better error message in this case? > >>> > >>> It's not Bash. That is the error returned from the OS in errno when > >>> it tries to do an exec(2) of the file. Bash merely translates the > >>> error into words. > >> > >> FWIW, the file in question that's not found is either the 32-bit version > >> of the loader or one of the required 32-bit libraries, not the binary > >> itself. > > > > it's the ldso missing. if a lib was missing, the ldso would spit out a > > useful message telling you exactly which lib could not be found. at > > least, that's the standard Linux (glibc/uclibc/etc...) behavior. > > > > $ ./a.out: error while loading shared libraries: libfoo.so: cannot open > > shared object file: No such file or directory > > The patch stated in > http://lists.gnu.org/archive/html/bug-bash/2002-03/msg00052.html is > applied in Fedora. > Chet, is it possible to apply it to source? seems like over kill when a slightly tweaked message would be sufficient. if you can stat(command), then include a fragment like "(bad interpreter?)". if we start supporting the ELF format, then people will want to add their own file formats (OS X's dylib also comes to mind). -mike signature.asc Description: This is a digitally signed message part.
Fwd: No such file or directory
-- Forwarded message -- From: Eric Blake Date: Wed, 02 Jan 2013 10:41:07 -0700 Subject: Re: No such file or directory To: Michael Williamson On 01/02/2013 10:30 AM, Michael Williamson wrote: > Hi Eric, > > Thanks for your explanation. I realize now that I should > submit my suggestion somewhere besides bug-bash, and > I am researching that. But, I have another question. > > Why does the man page have the complete, accurate error > message for ENOENT, but not glibc? Did you mean for this to go to the list (as other people might be interested in the question and answer)? And if so, please don't top-post. strerror() is full of historical baggage - changing the strings it outputs is not done lightly, even the string printed is not always the best fit for all documented cases in which a particular error is returned. Thus, the man pages will ALWAYS be a better fit than what glibc can cram into the limited abilities of strerror(). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org OK, thanks for that explanation Eric. In that case, my naive suggestion would be to introduce a new glibc function, such as strerror_verbose. -Mike signature.asc Description: PGP signature
Bash-4.2 Official Patch 40
BASH PATCH REPORT = Bash-Release: 4.2 Patch-ID: bash42-040 Bug-Reported-by:Andrey Zaitsev Bug-Reference-ID: Bug-Reference-URL: http://lists.gnu.org/archive/html/bug-bash/2012-04/msg00144.html Bug-Description: Output redirection applied to builtin commands missed I/O errors if they happened when the file descriptor was closed, rather than on write (e.g., like with an out-of-space error on a remote NFS file system). Patch (apply with `patch -p0'): *** ../bash-4.2-patched/redir.c 2011-01-02 16:00:31.0 -0500 --- redir.c 2012-04-24 20:42:12.0 -0400 *** *** 1092,1099 #if defined (BUFFERED_INPUT) check_bash_input (redirector); ! close_buffered_fd (redirector); #else /* !BUFFERED_INPUT */ ! close (redirector); #endif /* !BUFFERED_INPUT */ } break; --- 1092,1101 #if defined (BUFFERED_INPUT) check_bash_input (redirector); ! r = close_buffered_fd (redirector); #else /* !BUFFERED_INPUT */ ! r = close (redirector); #endif /* !BUFFERED_INPUT */ + if (r < 0 && (flags & RX_INTERNAL) && (errno == EIO || errno == ENOSPC)) + REDIRECTION_ERROR (r, errno, -1); } break; *** ../bash-4.2-patched/patchlevel.hSat Jun 12 20:14:48 2010 --- patchlevel.hThu Feb 24 21:41:34 2011 *** *** 26,30 looks for to find the patch level (for the sccs version string). */ ! #define PATCHLEVEL 39 #endif /* _PATCHLEVEL_H_ */ --- 26,30 looks for to find the patch level (for the sccs version string). */ ! #define PATCHLEVEL 40 #endif /* _PATCHLEVEL_H_ */ -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Bash-4.2 Official Patch 41
BASH PATCH REPORT = Bash-Release: 4.2 Patch-ID: bash42-041 Bug-Reported-by:Andrey Borzenkov Bug-Reference-ID: <20121202205200.21344...@opensuse.site> Bug-Reference-URL: http://lists.gnu.org/archive/html/bug-bash/2012-12/msg8.html Bug-Description: Process substitution incorrectly inherited a flag that inhibited using the (local) temporary environment for variable lookups if it was providing the filename to a redirection. The intent the flag is to enforce the Posix command expansion ordering rules. Patch (apply with `patch -p0'): *** ../bash-4.2-patched/subst.c 2012-07-14 15:53:20.0 -0400 --- subst.c 2012-12-02 22:26:54.0 -0500 *** *** 5125,5128 --- 5129,5136 #endif /* HAVE_DEV_FD */ + /* subshells shouldn't have this flag, which controls using the temporary + environment for variable lookups. */ + expanding_redir = 0; + result = parse_and_execute (string, "process substitution", (SEVAL_NONINT|SEVAL_NOHIST)); *** ../bash-4.2-patched/patchlevel.hSat Jun 12 20:14:48 2010 --- patchlevel.hThu Feb 24 21:41:34 2011 *** *** 26,30 looks for to find the patch level (for the sccs version string). */ ! #define PATCHLEVEL 40 #endif /* _PATCHLEVEL_H_ */ --- 26,30 looks for to find the patch level (for the sccs version string). */ ! #define PATCHLEVEL 41 #endif /* _PATCHLEVEL_H_ */ -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Bash-4.2 Official Patch 42
BASH PATCH REPORT
=
Bash-Release: 4.2
Patch-ID: bash42-042
Bug-Reported-by:Adam Pippin
Bug-Reference-ID:
Bug-Reference-URL:
http://lists.gnu.org/archive/html/bug-bash/2012-11/msg00087.html
Bug-Description:
Compilation failed after specifying the `--enable-minimal-config' option to
configure (more specifically, specifying `--disable-alias').
Patch (apply with `patch -p0'):
*** ../bash-4.2-patched/parse.y 2012-07-08 21:53:33.0 -0400
--- parse.y 2012-10-14 20:20:34.0 -0400
***
*** 2394,2397
--- 2392,2396
to consume the quoted newline and move to the next character in
the expansion. */
+ #if defined (ALIAS)
if (expanding_alias () && shell_input_line[shell_input_line_index+1] ==
'\0')
{
***
*** 2404,2408
goto next_alias_char; /* and get next character */
}
! else
goto restart_read;
}
--- 2403,2408
goto next_alias_char; /* and get next character */
}
! else
! #endif
goto restart_read;
}
*** ../bash-4.2-patched/patchlevel.hSat Jun 12 20:14:48 2010
--- patchlevel.hThu Feb 24 21:41:34 2011
***
*** 26,30
looks for to find the patch level (for the sccs version string). */
! #define PATCHLEVEL 41
#endif /* _PATCHLEVEL_H_ */
--- 26,30
looks for to find the patch level (for the sccs version string). */
! #define PATCHLEVEL 42
#endif /* _PATCHLEVEL_H_ */
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
