Sent from my iPhone
> On 17 Apr 2019, at 01:37, 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
You mean think they know, bett
^^ In the readline-8.0/doc directory from the readline tar with
time/date: Jan 7th 06:13, the ".0" (appears to be manpage) has
a 7.0 footer-line.
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 or that there is
something mal
On 4/14/19 9:40 PM, Paul Wise wrote:
>> The tool you have is the exit status of the last command.
>> From that perspective, there's no difference.
>
> From the perspective of the user of a shell prompt there is a difference.
I've been thinking about this. The user at a shell prompt is the only o
On 4/16/19 10:36 AM, Eric Blake wrote:
> On 4/15/19 4:31 PM, Chet Ramey wrote:
>
>>
>> The Korn shell uses values > 256 to denote `internal' shell exit statuses,
>> but that violates POSIX.
>
> No, actually it does NOT violate POSIX. In fact, POSIX has tried hard
> to permit that ksh behavior, i
On 4/15/19 4:31 PM, Chet Ramey wrote:
>
> The Korn shell uses values > 256 to denote `internal' shell exit statuses,
> but that violates POSIX.
No, actually it does NOT violate POSIX. In fact, POSIX has tried hard
to permit that ksh behavior, in particular since that extension allows
an easy di
On 4/15/19 10:29 PM, Paul Wise wrote:
> I wonder if bash could set an additional variable to indicate if $? is
> from a normal exit, a signal exit, a shell keystroke etc, as well as a
> corresponding equivalent array that is about PIPESTATUS.
That falls apart fairly quickly for anything but the c
