Thorsten Glaser <[email protected]> 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 [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
