Re: bash-4.0 regression: negative return values

[Chet Ramey]

Mike Frysinger wrote:
> On Monday 23 February 2009 08:48:32 Chet Ramey wrote:
>> Mike Frysinger wrote:
>>> previous versions of bash would happily accept negative values ( treated
>>> as a signed integer and masked with like 0xff), but it seems some changes
>>> related to option parsing has broken that
>>>
>>> $ f(){ return -1; }; f
>>> -bash: return: -1: invalid option
>>> return: usage: return [n]
>> Bash still happily accepts the same negative return values; however, the
>> `return' builtin was changed to use the standard option parsing rules
>> like the rest of the builtins.  The effect is that arguments
>> beginning with a `-' that are not to be treated as options must follow
>> a `--'.
> 
> that makes negative values kind of useless imo and breaks backwards 
> compatibility.  if 'return -1' isnt going to be fixed, then i'd just break it 
> completely so as to force people to migrate to POSIX compliant behavior.

By your logic, nothing could ever be fixed as long as someone was using
it.

Are filenames beginning with a `-' useless because `rm' interprets
them as option arguments when, for instance, they're generated by the
expansion of `*'?  Is `rm' broken for interpreting them as options?
I mean, there's no real difference between the two cases.  If you have
an argument that looks like an option, and you don't want it interpreted
as an option, you protect it in some way. The standard way to do that is
to make it follow `--'.

>> It's in the change log as having happened between bash-4.0-alpha and
>> bash-4.0 beta.
> 
> the changelog mentions options, not negative values.  they arent the same 
> thing.

Ummm...yes, they are.  They are both arguments to the command that
begin with `-'.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/