bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: issues in bash found while creating command result display


From: Chet Ramey
Subject: Re: issues in bash found while creating command result display
Date: Wed, 17 Apr 2019 11:23:27 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 4/16/19 7:37 PM, Paul Wise wrote:
> On Tue, 2019-04-16 at 14:57 -0400, Chet Ramey wrote:
> 
>> Why take so much effort to (imperfectly) figure out and display
>> things you already know?
> 
> Correctness. If what the user knows doesn't match what the program
> knows then they might think that the program is buggy 

OK, let's explore that a little.

1. The user types ^C, and knows he typed it.

2. The shell sets $? to 130 (128+SIGINT) to note that a command was
   interrupted during parsing.

3. The user types ^C, and knows he typed it.

4. The shell sets $? to 130 for the same reason.

Compare that to

1. The user types ^C, and knows he typed it.

2. The shell sets $? to 130 (128+SIGINT) to note that a command was
   interrupted during parsing.

3. The user types RET, and knows he typed it.

4. The shell doesn't change $?, since no command was executed to change it.


What is the `correctness' rationale to change this? Why should the shell
modify well-understood rules? The user knows what he did, and should know
the consequences of those actions on what the shell exposes externally.

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]