On 10/21/11 3:50 PM, Linda A. Walsh wrote:
> URL:
> <http://savannah.gnu.org/patch/?7637>
>
> Summary: bash 4.1 return builtin violates posix in checking
> for options
> Project: The GNU Bourne-Again SHell
> Submitted by: law
> Submitted on: Fri 21 Oct 2011 12:50:32 PM PDT
> Category: None
> Priority: 6
> Status: None
> Privacy: Public
> Assigned to: None
> Originator Email:
> Open/Closed: Open
> Discussion Lock: Any
>
> _______________________________________________________
>
> Details:
>
> in bash 4.1, the return cmd now checks to see if it has
> options and parses them as 'illegal' (not very helpful and
> certainly not a usability feature). Posix says the return command takes no
> options.
This changed between bash-4.0-alpha and bash-4.0-beta. You missed the
ensuing discussion by around three years.
The rationale at the time was that Posix specifies the argument to return
to be an `unsigned decimal integer', so negative numbers should not be
allowed. The Bourne shell has never accepted them, for instance, and
other shells claiming Posix conformance (e.g., dash, mksh, FreeBSD 8 sh)
don't either.
The issue came up again recently, and the resultant discussion convinced
me that it would be a reasonable, if non-portable, extension to Posix.
No application should be passing anything but {0..255} in any case.
Accepting it as an argument doesn't mean the value isn't going to be
masked with 0xff, though.
The next version of bash will allow negative numbers as arguments to
return, which has the added benefit of rationalizing the values passed
to `return' and `exit'.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
