GNU bug report logs -
#65604
[PATCH] Display the exit code if the last command failed in Eshell
Previous Next
Reported by: Davide Masserut <dm <at> mssdvd.com>
Date: Tue, 29 Aug 2023 22:45:01 UTC
Severity: normal
Tags: patch
Fixed in version 30.1
Done: Jim Porter <jporterbugs <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Jim Porter <jporterbugs <at> gmail.com> writes:
> Hmm, well if everyone else disagrees, I suppose I don't see any
> *major* issues with including the exit status in the prompt, though
> I'm a little worried it would annoy people who like the current
> way. If it were easier to customize the prompt, I don't think I'd be
> as worried. Fixing that for real is probably beyond the scope of
> this
> bug, but I do have a WIP patch for it.
What do you find difficult to customize?
I can only think of two things:
1) The default function is quite simple, but displaying the bytecode
in customization buffer can be confusing.
Hide Eshell Prompt Function: Function:
#[0 "\300\301 !\302 \303U\203\0\304\202\0\305P\207"
[abbreviate-file-name eshell/pwd file-user-uid 0 " # " " $ "] 3]
State : STANDARD.
A function that returns the Eshell prompt string. Hide
Make sure to update ‘eshell-prompt-regexp’ so that it will match
your
prompt.
2) It may require to update the regexp.
Can we use rx to make it more understandable?
> If we do use the mode-line to display this though, I was initially
> thinking we could use the existing variable
> 'eshell-command-running-string', which we could set to something
> like
> "!!" in 'eshell-command-finished'. That's not as useful as the
> actual
> number though, and honestly I'm not sure the current
> 'eshell-status-in-mode-line' code is a good idea anyway. It
> (buffer-locally) replaces the mode-line construct immediately after
> 'mode-line-front-space', which means you lose some of the
> potentially-useful information there.
>
> Maybe it would make sense to move *all* of the current Eshell
> mode-line stuff to the 'mode-line-process' construct. That seems
> like
> it would be less brittle. That is, in 'mode-line-process', we could
> show whether a command is running or the exit status if nothing's
> running (possibly including successful exit). What does everyone
> think
> about that?
In this case I would add a small delay before signaling that something
is running.
However, I'm not sure it is so useful to signaling it.
When I suspect that the process is hanging, I usually use tools like
top or proced to check if something is stuck, but otherwise I already
know something is going on.
I believe some terminals update the title bar when something is
running and send a notification when process ends and the window is
not focused.
But for such long operations compilation-mode works best for me (BTW,
thank you for the new compile command).
>>> and OTOH Bash does show abnormal exit codes as part of its prompt.
>>> But feel free to disregard
>>> my opinions, as I'm not a heavy user of Eshell.)
>> fish and some zsh distributions also show the error in the prompt.
>
> Do they? I tried to see what the default was for Bash and after some
> searching, it seemed that it doesn't show the exit status by
> default. But that could be wrong.
Distros often change the default prompt.
This bug report was last modified 1 year and 256 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.