Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000114 [1003.1(2008)/Issue 7] Shell and Utilities Comment Omission 2009-07-01 16:55 2013-04-16 13:06
Reporter eblake View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Eric Blake
Organization
User Reference ebb.dot
Section dot
Page Number 2341
Line Number 74053
Interp Status Approved
Final Accepted Text Note: 0000257
Summary 0000114: dot exit status
Description The standard is unclear what happens to $? when an argument to . is not found in an interactive shell. Line 74030 states that a diagnostic is written but it is not a syntax error (which generally implies non-zero status), but line 74053 states that the exit status is 0 if no command is executed (and since no file was found, no command was executed). Existing practice is that $? is set to non-zero in this case (although various shells have chosen 1, 2, or 127).

In a similar vein, the standard appears to be silent on what happens when ., eval, or trap encounter text that cannot be parsed in isolation. In this case, traditional shells either aborted with non-zero status, or guaranteed non-zero status visible to subsequent commands; but some modern shells do not detect the failure (which can be rather surprising):

$ echo 'if' > tmp
$ zsh -c 'emulate sh; . ./tmp; echo $?'
./tmp:1: parse error near `\n'
0
$ bash --posix -c 'trap "if" 0'; echo $?
bash: exit trap: line 1: syntax error: unexpected end of file
0

It would be nice to tighten this up (even though that renders some existing implementations buggy).
Desired Action At line 74053 (dot), replace:

Returns the value of the last command executed, or a zero exit status if no command is executed.

with:

If no readable file was found or if the commands in the file could not be parsed, and the shell does not abort, the exit status shall be non-zero. Otherwise, return the value of the last command executed, or a zero exit status if no command is executed.

At line 74110 (eval), replace:

If there are no arguments, or only null arguments, eval shall return a zero exit status; otherwise, it shall return the exit status of the command defined by the string of concatenated arguments separated by <space> characters.

with:

If there are no arguments, or only null arguments, eval shall return a zero exit status; otherwise, it shall return the exit status of the command defined by the string of concatenated arguments separated by <space> characters, or a non-zero exit status if the concatenation could not be parsed as a command and the shell did not abort.

At line 74864 (trap), replace:

The value of "$?" after the trap action completes shall be the value it had before trap was invoked.

with:

If a trap action cannot be parsed at the time it is invoked, and the shell does not abort, then the value of "$?" shall be non-zero; otherwise the value of "$?" after the trap action completes shall be the value it had before the trap action was invoked.
Tags tc1-2008
Attached Files

- Relationships
related to 0000443Closedajosey 2008-TC1 poor wording about errors in interactive shells 

-  Notes
(0000195)
ajosey (manager)
2009-08-13 16:07

This item was reviewed at the 13 August 2009 teleconference. The changes proposed to dot and eval appear acceptable. Some reservations were noted with the trap replacement text. Some further investigations are required . Action on Andrew to contact Dave Korn for feedback.
(0000255)
nick (manager)
2009-10-15 15:07

From David Korn:

The wording is somewhat ambiguous, but the intent was not.

In Bourne shell and ksh88, if a readable file is not found,
this is an error. With an interactive script it is fatal and
with an interactive script it is not. Since it is an error, it
must have a non-zero exit status. It is not a syntax error therefore
cannot be found with sh -n.

The Exit Status line refers to the case where the file is readable.
If the file is empty (or just comments), and therefore no command
is executed, then the exit status will be zero.

It would make no sense for a command that terminates due to an
error to return a zero exit status.

One could argue that the exit status should be 127 in the case the file
file was not foud, and 126 if it is not readable, but this would
represent a change.

As far as the proposed change:

The proposed change for dot is incorrect in that an interactive script will
abort if the file is not found or is not readable as currently described.
In the case that the . script has a syntax error, I don't think that
the shell should abort, but this is debatable.

For eval, a syntax error should cause eval to have a non-zero exit status.
I would eliminate "and the shell did not abort". I don't know why eval
should cause the shell to abort.

For trap, the value of $? after the trap should be the value before
the trap so a syntax error would not effect $?
I don't understand why the shell would abort. I don't think that a syntax
error should effect the value of $?. It doesn't with historical practice.


David Korn
dgk@research.att.com
(0000256)
nick (manager)
2009-10-15 15:08

Geoff Clare responded:

>> The proposed change for dot is incorrect in that an interactive script
>> will
>> abort if the file is not found or is not readable as currently
>> described.

Presumably David meant to say non-interactive here. The requirement
for a non-interactive shell to abort when a dot file is not found
is in 2.8.1 Consequences of Shell Errors. (We should probably
change it to say "not found or not readable".) So the proposed
change is not actually wrong, it's just that the "and the shell does
not abort" part only applies to interactive shells. Having said
that, it might be better to word it so that it is not misleading
to readers not familiar with 2.8.1.

>> In the case that the . script has a syntax error, I don't think that
>> the shell should abort, but this is debatable.

2.8.1 requires a non-interactive shell to abort.

>> For eval, a syntax error should cause eval to have a non-zero exit
>> status.
>> I would eliminate "and the shell did not abort". I don't know why
>> eval
>> should cause the shell to abort.

Again, 2.8.1 requires a non-interactive shell to abort.
Most of the shells I tried do abort, but ksh93 and bash don't.

>> For trap, the value of $? after the trap should be the value before
>> the trap so a syntax error would not effect $?
>> I don't understand why the shell would abort. I don't think that a
>> syntax
>> error should effect the value of $?. It doesn't with historical
>> practice.

This confirms the misgivings we had that prompted us to ask David
about it, so I believe we should omit the trap part of the changes.

Regards,
Geoff.
(0000257)
geoffclare (manager)
2009-10-15 15:15
edited on: 2009-10-15 15:21

Interpretation response
------------------------
The standard is unclear on this issue, and no conformance
distinction can be made between alternative implementations based
on this. This is being referred to the sponsor.

Rationale:
-------------
None.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------

At line 74053 (dot), replace:

Returns the value of the last command executed, or a zero exit status
if no command is executed.

with:

If no readable file was found or if the commands in the file could not
be parsed, and the shell is interactive (and therefore does not
abort; see [xref to 2.8.1]), the exit status shall be non-zero.
Otherwise, return the value of the last command executed, or a zero
exit status if no command is executed.

At line 74110 (eval), replace:

If there are no arguments, or only null arguments, eval shall return a
zero exit status; otherwise, it shall return the exit status of the
command defined by the string of concatenated arguments separated by
<space> characters.

with:

If there are no arguments, or only null arguments, eval shall return a
zero exit status; otherwise, it shall return the exit status of the
command defined by the string of concatenated arguments separated by
<space> characters, or a non-zero exit status if the concatenation
could not be parsed as a command and the shell is interactive (and
therefore did not abort).


- Issue History
Date Modified Username Field Change
2009-07-01 16:55 eblake New Issue
2009-07-01 16:55 eblake Status New => Under Review
2009-07-01 16:55 eblake Assigned To => ajosey
2009-07-01 16:55 eblake Name => Eric Blake
2009-07-01 16:55 eblake User Reference => ebb.dot
2009-07-01 16:55 eblake Section => dot
2009-07-01 16:55 eblake Page Number => 2341
2009-07-01 16:55 eblake Line Number => 74053
2009-08-13 16:07 ajosey Interp Status => ---
2009-08-13 16:07 ajosey Note Added: 0000195
2009-10-15 15:07 nick Note Added: 0000255
2009-10-15 15:08 nick Note Added: 0000256
2009-10-15 15:15 geoffclare Note Added: 0000257
2009-10-15 15:21 geoffclare Note Edited: 0000257
2009-10-15 15:23 geoffclare Interp Status --- => Pending
2009-10-15 15:23 geoffclare Final Accepted Text => Note: 0000257
2009-10-15 15:23 geoffclare Status Under Review => Interpretation Required
2009-10-15 15:23 geoffclare Resolution Open => Accepted As Marked
2009-11-07 07:36 ajosey Interp Status Pending => Proposed
2009-12-07 16:57 ajosey Interp Status Proposed => Approved
2010-09-21 11:07 geoffclare Tag Attached: tc1-2008
2011-05-16 09:14 geoffclare Relationship added related to 0000443
2013-04-16 13:06 ajosey Status Interpretation Required => Closed


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker