Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #16285

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

Show all headers | View raw

On 5/5/20 12:16 PM, Franklin, Jason wrote:

> 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.

In bash, yes. Nowhere else. They both require special handling.

> 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.

Yes, it's equivalent to -1. That's just giving it semantics, not providing
any unique functionality. It could just as easily have been an error, as
POSIX intended.

> 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.

This is about the only reasonable alternative.

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

I'll come up with something.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

Back to gnu.bash.bug | Previous | Next | Find similar

Thread

Re: [bug] Segmentation fault in the "fc" builtin Chet Ramey <chet.ramey@case.edu> - 2020-05-05 16:10 -0400

csiph-web