Bug#549179: mksh: Stop on error when reading directory as script
reopen 549179 thanks please read the answers in the following thread from the Austin ML: http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/755640/focus=2959 There have been no more followups, so I believe that, when expecting a file, but given a directory, this is a user error which the shell needs not handle in a given way. What user does, is of no consequence. What a shell should do, is better looked up from the standard. Reopening because the close message did not include explanation to the points marked (), as to why mksh is interpreting them according to the spec: See http://www.opengroup.org/onlinepubs/9699919799/utilities/sh.html hat defines: NAME sh - shell, the standard command language interpreter SYNOPSIS sh [-abCefhimnuvx][-o option][+abCefhimnuvx][+o option] [command_file [argument...]] INPUT FILES The input file shall be a text file, except that line lengths shall be unlimited. If the input file is empty or consists solely of blank lines or comments, or both, sh shall exit with a zero exit status. EXIT STATUS The following exit values shall be returned: 0 The script to be executed consisted solely of zero or more blank lines or comments, or both. 1-125 A non-interactive shell detected a syntax, redirection, or variable assignment error. 127 A specified command_file could not be found by a non-interactive shell. That would summarize to something like; that a file is defined as being a: text file Running conditions for the shell, when reading: script to be executed ... == and an error condition when: command_file could not be ... The context of file in the sh specification is stated to be, not a broad definition of term file, but specifically limited to a command file (sections: synopsis, exit status). According to the spec, if command file is not to be found, it is an error condition. A non command_file could be in this regard anything: a block device, a character device, a directory. For the reference, similar fix was committed to dash: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548687 Changes: dash (0.5.5.1-4) unstable; urgency=low * Debian/diff/0025-INPUT-exit-127-if-command_file-is-given-...diff: new; exit 127 if command_file is given but is a directory (closes: #548687). Jari -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549179: mksh: Stop on error when reading directory as script
The shell scripts are executed in context of file. The POSIX standard specifically requires the context to be a readabale in order to run the instructions. [mirabilos] Yes, but SUSv4 doesn’t say (or I could not find it) explicitly what to do with directories. Directories are files. You did not prove otherwise. SUSv4 does not (or I cannot find it) say that directories are *not* files. Here is new information: 1) See http://www.opengroup.org/onlinepubs/9699919799/utilities/sh.html hat defines: NAME sh - shell, the standard command language interpreter INPUT FILES [-] The input file shall be a text file, except that line lengths shall be unlimited. If the input file is empty or consists solely of blank lines or comments, or both, sh shall exit with a zero exit status. POSIX requires that input files to bash shall be text files; directories do not qualify. 2) See also http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#exec NAME exec - execute commands and open, close, or copy file descriptors EXIT STATUS If command is specified, exec shall not return to the shell; rather, the exit status of the process shall be the exit status of the program implementing command, which overlaid the shell. If command is not found, the exit status shall be 127. If command is [-] found, but it is not an executable utility, the exit status shall be 126. If a redirection error occurs (see Consequences of Shell Errors ), the shell shall exit with a value in the range 1-125. Otherwise, exec shall return a zero exit status. emphasis on if ... is not an executable utility. An example: $ mksh -c 'exec .'; echo $? mksh: .: missing argument 1 That should exit with 126. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549179: mksh: Stop on error when reading directory as script
Thorsten Glaser t...@mirbsd.de writes: tags 549179 wontfix t...@herc:~ $ cat tmp; echo $? 0 t...@herc:~ $ mksh tmp; echo $? 0 This is consistent with the rest of the operating system, ans as such not a bug, unless SUSv4 were to specifiy otherwise. That is an incorrect reasoning. The POSIX standard mandates: http://www.opengroup.org/onlinepubs/009695399/utilities/cat.html SYNOPSIS cat [-u][file ...] DESCRIPTION The cat utility shall read files in sequence and shall write their contents to the standard output in the same sequence. EXIT STATUS The following exit values shall be returned: 0 All input files were output successfully. 0 An error occurred. It's a bug in cat(1). It should work only in file context; thus return an error on other contexts. This bug needs to be reported to cat(1) as well. and as such not a bug, unless SUSv4 were to specifiy otherwise. Note that, when you can show me clearly that SUSv4 mandates or recommends different behaviour, I *will* change it, but not as I can’t see the problem right now. Doh, I wish a common sense were sometimes exercised. The shell scripts are executed in context of file. The POSIX standard specifically requires the context to be a readabale in order to run the instructions. See: (1) http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html 2. Shell Command Language This chapter contains the definition of the Shell Command Language. 1. The shell reads its input from a file (see sh), from the -c option or from the system() and popen() functions defined in the System Interfaces volume of IEEE Std 1003.1-2001. If the first line of a file of shell commands starts with the characters #!, the results are unspecified. (2) http://www.opengroup.org/onlinepubs/009695399/utilities/sh.html NAME sh - shell, the standard command language interpreter SYNOPSIS sh [-abCefhimnuvx][-o option][+abCefhimnuvx][+o option] [command_file [argument...]] DESCRIPTION The sh utility is a command language interpreter that shall execute commands read from a command line string, the standard input, or a specified file. The application shall ensure that the commands to be executed are expressed in the language described in Shell Command Language. (3) It's an error by definition not to be able to read a file given for the shell. These error conditions are identical. In both cases the shell cannot read content to execute: type sh /bin/dash touch file chmod 000 file sh file echo $? 127 rm file mkdir file sh file = Likewise (should print error; the dash bug was recently files) I'm sure you find these arguments reasonable enough -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549179: mksh: Stop on error when reading directory as script
t...@herc:~ $ mkdir tmp; cat tmp; echo $? 0 This is consistent with the rest of the operating system, ans as such not a bug, unless SUSv4 were to specifiy otherwise. FYI, In Debian Linux the cat(1) behaves in standards compliant way[1]: $ cat /tmp cat: /tmp: Is a directory $ echo $? 1 It would be helpful to report this cat(1) bug to the OS you had used for testing. [1] http://www.opengroup.org/onlinepubs/009695399/utilities/cat.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549179: mksh: Stop on error when reading directory as script
Jari Aalto dixit:
That is an incorrect reasoning. The POSIX standard mandates:
[…]
The shell scripts are executed in context of file. The POSIX standard
specifically requires the context to be a readabale in order to run the
instructions.
Yes, but SUSv4 doesn’t say (or I could not find it) explicitly what
to do with directories.
It would be helpful to report this cat(1) bug to the OS you had used for
testing.
mksh is part of MirBSD.
In UNIX®, everything is a file. This is a mantra. Directories
are files. See also the attached source code, which outputs
this on MirBSD:
t...@bleu:~ $ ./a.out
open successful: 3
close: 0
There are even operating systems where you can read from directories:
mirabi...@stargazer:~ $ ./a.out
open successful: 3
read 512 bytes
close: 0
mirabi...@stargazer:~ $ uname -a
MidnightBSD stargazer.midnightbsd.org 0.3-CURRENT MidnightBSD 0.3-CURRENT #4:
Wed Jun 10 16:14:19 EDT 2009
r...@stargazer.midnightbsd.org:/usr/obj/usr/src/sys/GENERIC i386
Of course, this leads to interesting things:
mirabi...@stargazer:~ $ mksh /
/[1]: syntax error: '^B^L^D^Cvar$D^B^P^D^Dhome�$X�^T^A^L^D^Cetc' unexpected
But this is not an error, since:
OPEN(2)BSD Programmer's Manual OPEN(2)
NAME
open - open or create a file for reading or writing
Apparently, the open(2) syscall operates in the very same file context
as the shell does, but it succeeds to open directories. Thus, directo-
ries *are* files even for the shell context, *unless* this gets chan-
ged in open(2), which is most unlikely.
Please provide a better reasoning if you want this behaviour changed ☺
bye,
//mirabilos
--
[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
what about xfs, and if only i had waited until reiser4 was ready... in the be-
ginning, there was ffs, and in the middle, there was ffs, and at the end, there
was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs#include err.h
#include errno.h
#include fcntl.h
#include stdio.h
#include unistd.h
char buf[4096];
int
main(void)
{
int fd;
ssize_t n;
if ((fd = open(/, O_RDONLY)) 0)
err(1, open);
printf(open successful: %d\n, fd);
while ((n = read(fd, buf, sizeof(buf {
if (n == -1) {
if (errno == EAGAIN)
continue;
err(1, read);
}
printf(read %zd bytes\n, n);
}
fd = close(fd);
printf(close: %d\n, fd);
return (fd == 0 ? 0 : 1);
}
Bug#549179: mksh: Stop on error when reading directory as script
Thorsten Glaser t...@mirbsd.de writes: Jari Aalto dixit: That is an incorrect reasoning. The POSIX standard mandates ... The shell scripts are executed in context of file. The POSIX standard specifically requires the context to be a readabale in order to run the instructions. Yes, but SUSv4 doesn’t say (or I could not find it) explicitly what to do with directories. It doesn't say about many things: context of symlinks, block devices etc. What is does say, as quoted: http://www.opengroup.org/onlinepubs/009695399/utilities/cat.html cat [-u][file ...] EXIT STATUS The following exit values shall be returned: 0 All input files were output successfully. 0 An error occurred. Does it not explicitly read file in all points? http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html SYNOPSIS sh [-abCefhimnuvx][-o option][+abCefhimnuvx][+o option] [command_file [argument...]] Does it not explicitly read command_file? http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html 2. Shell Command Language This chapter contains the definition of the Shell Command Language. 1. The shell reads its input from a file (see sh), from the -c option or from the system() and popen() functions defined in the System Interfaces volume of IEEE Std 1003.1-2001. If the first line of a file of shell commands starts with the characters #!, the results are unspecified. Does it not read file in all points? It would be helpful to report this cat(1) bug to the OS you had used for testing. mksh is part of MirBSD. Then please use Debian when comparing the results, where programs are brought forward to POSIX compliance. Please provide a better reasoning if you want this behaviour changed ☺ The POSIX standard is perfectly clear on this: it says file and that word does not have intereptation you suggest. Please bring mksh to follow the POSIX standard under Debian. mksh is a Debian package, so the rules of POSIX apply here. A Debian specific patch would be appropriate if mksh is ported elsewhere. Jari -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549179: mksh: Stop on error when reading directory as script
Jari Aalto dixit: Thorsten Glaser t...@mirbsd.de writes: Yes, but SUSv4 doesn’t say (or I could not find it) explicitly what to do with directories. It doesn't say about many things: context of symlinks, block devices etc. Indeed. That would probably be implementation-specific behaviour. […] Does it not explicitly read file in all points? The POSIX standard is perfectly clear on this: it says file and that word does not have intereptation you suggest. Directories are files. You did not prove otherwise. SUSv4 does not (or I cannot find it) say that directories are *not* files. bye, //mirabilos -- Yay for having to rewrite other people's Bash scripts because bash suddenly stopped supporting the bash extensions they make use of -- Tonnerre Lombard in #nosec -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549179: mksh: Stop on error when reading directory as script
Package: mksh Version: 38.3-1 Severity: normal mkdir tmp mksh tmp = No error messages, no status code $? to signify an error. Please signal an error and terminate on non-zero exit code. An example from Bash: bash tmp tmp/: tmp/: is a directory C.f. This bug was found from other shells as well (posh, dash). See e.g. how posh fixed it in version 0.8 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548688 -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mksh depends on: ii debconf [debconf-2.0] 1.5.27 Debian configuration management sy ii libbsd0 0.1.6-1utility functions from BSD systems ii libc6 2.9-25 GNU C Library: Shared libraries mksh recommends no packages. Versions of packages mksh suggests: ii ed1.4-1 The classic UNIX line editor -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549179: mksh: Stop on error when reading directory as script
tags 549179 wontfix severity 549179 wishlist thanks Jari Aalto dixit: mkdir tmp mksh tmp = No error messages, no status code $? to signify an error. t...@herc:~ $ cat tmp; echo $? 0 t...@herc:~ $ mksh tmp; echo $? 0 This is consistent with the rest of the operating system, ans as such not a bug, unless SUSv4 were to specifiy otherwise. bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
