Re: [bug] Segmentation fault in the "fc" builtin

[Franklin, Jason]

On 5/5/20 11:41 AM, Chet Ramey wrote:
> Thanks for the report and your careful analysis.
> 
>>
>> Allow me to explain the reasoning behind the patch...
>>
>> From the CHANGES file, we see this note concerning the "fc" builtin:
>>
>>   b.  The fc builtin now interprets -0 as the current command line.
> Yes, this is from one of the bash-4.3 testing releases. It's in response
> to this message:
> 
> https://lists.gnu.org/archive/html/bug-bash/2013-08/msg00037.html
> 
> and deliberately works only for -l.
> 
> The question is what to do about the cases where -l isn't supplied, as
> you observed. Dumping core is definitely the worst of the options.
> 
>> Our solution does not remove the last history item when the user passes
>> "-0" to tell "fc" to include it in the history and the list to edit.
> 
> The issue I have with this solution is that it leads to an infinite loop
> if the user doesn't change the command in the editor. If you use `fc -s -0'
> the shell runs fc recursively until it runs out of stack space and then
> dumps core.

You're right here, I think.  With this, it still seems easy to shoot
yourself in the foot.  As you say below, though, it might be reasonable
to call this a user error.  Though the command does offer this negative
possibility, it is logically consistent with the intent.

> You could easily say that this falls into the category of user error, and
> I wouldn't argue, but as you also observe, there's nothing in the man page
> prohibiting or even warning against it.

Agreed.  This is an undocumented feature, which is why Brandon and I had
a bit of trouble figuring out what "should" happen. :/

> I'm leaning towards making 0 and -0 out-of-range errors for the non-listing
> case. This is what other shells do (the netbsd and freebsd shells being
> notable exceptions).

Well, I think 0 and -0 have different intentions as it stands.
Currently, "0" indicates the command right before the "fc" invocation
that caused the editing or listing.  This shouldn't ever cause an
infinite loop and should not be an out-of-range error, I assert.

Example session:

  bash-5.0$ true # example command
  bash-5.0$ fc -l 0
  48       true # example command
  bash-5.0$

Thus, the argument in question is specifically "-0" proper.  This, to
me, means "the fc command itself" that did this work.

Would a good solution be to have "0" function as-is, but have "-0" only
be valid in the listing case?  This would avoid the problem above.

Of course, documenting the intent of the feature would be key to making
the change a successful one!

Thanks, Chet!

-- 
Jason Franklin