Detect $status being carried over from last command

[soumya92]

fish, version 3.1.0

I did not expect this:

soumya@machine /h/soumya> false
soumya@machine /h/soumya [1]> set foo bar
soumya@machine /h/soumya [1]> sleep 2 &
Job 1, 'sleep 2 &' has ended
soumya@machine /h/soumya [1]>

soumya@machine /h/soumya> true
soumya@machine /h/soumya> set foo bar
soumya@machine /h/soumya> sleep 2 &
Job 1, 'sleep 2 &' has ended
soumya@machine /h/soumya> 

I understand why this is happening, since both set and & do not modify the status. And that behaviour is great for scripts.

But it was still surprising to me that the [1] carried over in the prompt. Would it be possible for $status to be cleared somehow in preexec, so that it's only set to a non-zero value if it was explicitly caused by the last command? Or introduce a variable that could indicate that the previous command had no status?

(I tried set status 0 in --on-event fish_preexec, but as expected, that did not work)

[faho]

Would it be possible for $status to be cleared somehow in preexec

No. We show $status as it is, anything else is more confusing, because now interactive fish and script-fish behave differently.

[soumya92]

Fair enough. What about introducing a variable to detect "empty status"? Then it could be up to prompt authors to handle that specially (e.g. indicate that the status "carried over"), without affecting the default prompt.

[soumya92]

The motivation behind this request is that I print a "summary" for commands that don't exit 0, indicating the error code and time. But it's weird to see " ✘ 1 ⬥ set ⬥ 12:04:20" since set did not exit with 1.

[soumya92]

anything else is more confusing, because now interactive fish and script-fish behave differently.

Actually, thinking about this some more, I don't agree completely. My mental model is that at the prompt, the status is "clean", and the displayed status is whatever the result of the previous command was. I don't consider my entire shell session similar to a single fish script, but rather I consider it similar to a bunch of tiny fish scripts.

So in my mind, the return value of a single command in interactive mode would be the same as the return value of fish -c "$commandline", and fish -c "set foo bar" returns 0.

But this is tangential, it's entirely possible that my mental model is in the minority, and adjusting that is not a big deal. The only problem here is that there's no way for me to detect the empty/carried-over status.

[faho]

I don't consider my entire shell session similar to a single fish script, but rather I consider it similar to a bunch of tiny fish scripts.

So in my mind, the return value of a single command in interactive mode would be the same as the return value of fish -c "$commandline", and fish -c "set foo bar" returns 0.

I would argue that your mind is... well, wrong. The commandline is positively dripping in state that carries over. Any set will affect all later lines, even if it's just local. Running fish -c twice should basically do the same thing (unless any global state changed, like exported variables or the working directory or files or something), but running two commands will often work differently.

Your shell session is a single fish script. It's "read line, execute line, read line, execute line". I don't think papering over that does any good.

[soumya92]

Huh, I didn't realise set -l would persist across the entire session. That definitely makes me rethink how sessions work 😄

In any case, all I really need here is some way to detect that the last command had an empty status.

I guess it's possible to hack that with some fish_indent and string checks to see if all commands were set without -q or backgrounded, but that sounds brittle, and it would be easier to just check (e.g.) $emptystatus. WDYT?

[soumya92]

Hmm, set explicitly returns the previous status, and it's not just a carried over status. So a simplistic solution would only work for the '&' case.

For set we would need some form of "optional" return, which seems like a rather large change to support just the one builtin command. 🤔

I'm out of ideas on this problem. For now I'll just hack it with some checks against argv in my postexec function, but it would be nice to have a proper solution.

[soumya92]

Nope, can't hack it in postexec either 😞

Consider the pathological case:

function return2; return 2; end; return2
set $varname bar

If varname has invalid characters, then the exit status of 2 is actually caused by set, otherwise it's caused by the preceding command "return2". Since there's no way to know that from just the commandline, any attempts to do so will be wrong under certain circumstances. So any changes to support this must happen in the shell itself.

[soumya92]

Okay, I hacked something together in #6820 that "works on my machine":tm:

This is just a proof of concept, but it could help further discussions by providing a concrete example implementation.

[krobelus]

I agree that the carried-over status is irritating and we should make it feel more natural. Reminds me of this thread on twitter.

Changing the language semantics or lying about $status is probably off-limits.
One idea would be to change the color of the status to something more modest, if the status was not written to. This would also communicate the fact.
Example:

printf '$ false\n'
printf '%s[1]%s $ set -l a b\n' (set_color --bold red) (set_color normal)
printf '%s[1]%s $\n' (set_color $fish_color_autosuggestion) (set_color normal)