Chet Ramey wrote:
On 8/7/11 6:03 PM, Linda Walsh wrote:
Bash itself is inconsistent in that it accepts exit values the same as
every other
program, but limits return values to a particular subset.
Bash accepts any value you want to give to `return' and strips it to
8 bits, as the standard allows. Read the error message closely: it says
`invalid option'. return doesn't accept any options
====
Does 'exit' accept any options? No. It doesn't complain.
I would assert, that 'return', since it accepts no options, cannot
have an 'invalid option', (there are no valid options), therefore, any
argument to should attempt to be parsed as a number.
Else, I would ask: If -1 is an invalid option, what are valid
options...well, as you said, it accepts no options, so it shouldn't be
possible for it to return a "validation" on the acceptability of something
as an argument -- as the option parser should never be called on it any more
than it is called on exit.
As a nice enhancement, you could just default to accepting any
expression that returned a number (i.e. treat it as the interior of
a (()), vs. requiring that one use $(((expr))) as is now acceptable,
and explicitly mention that "return $status+0x80" is a bash enhancement...
Of course to return -1, apparently one can also use
return $(-1)...there are plenty of ways to get around it...
that wasn't the point.
if shouldn't be trying to parse options any more than 'exit' does.
example of a valid option
It's not about "getting around the bug" -- it's that it shouldn't
be checking for options in the first place!
