[noir_lord]

Joking aside I can’t ever remember seeing a bug in either bash or zsh, never seen either crash or segfault and anytime I’ve had weirdness it’s always turned out to be me missing something.

Both (along with a lot of the standard utilities) are a testament to what talented C programmers plus years of people beating on them in unintended ways can achieve in terms of reliability/stability.

[1718627440]

Programs not outputting a final newline to stdout leave a prompt that doesn't start on column 0, and readline seams to not takes this into consideration, but still optimizes redraws and overwrites so you get an inconsistent display. This bugs seam to exist in a lot of shells and interactive programs. The program causing the issue isn't POSIX conform though.

[tuetuopay]

I don't get why this is still the case on classic shells. fish properly puts the prompt on column zero, while outputting a small "line return arrow" at the end of the command to indicate it lacked one.

[mort96]

It's arguably not the shell's role to protect against garbled output. Do you expect a shell to reset the TTY state after every command too in case you accidentally `cat /dev/urandom` and the terminal emulator enters a weird state due to random escape sequences?

The newline is a line terminator, a command outputting an incomplete line without a line terminator is producing garbled non-textual output. Files which contain incomplete lines without a line terminator are similarly garbled non-textual files and not very different from /dev/urandom or any other binary file.

[wat10000]

If you were designing a command-line interface from scratch, you'd definitely make it so that the command prompt gets displayed consistently and reliably after each command terminates, regardless of what garbage it spewed. The only reason we see anything different is because UNIX systems happened to grow that way, and everything gets crammed through an interface that was originally designed to show characters on physical paper.

With the design we actually have, the shell is the only thing in the chain that could reset the TTY state and ensure that the prompt gets displayed consistently each time, and it should. I wouldn't go so far as to say that I expect it to (my expectations for computers are not high in general) but it ought to.

[1718627440]

command-line interface != shell

Maybe that should be actually the job of the terminal emulator instead. It could happen when a new pseudo terminal is (de)allocated, which is ordered by the shell.

[wat10000]

> command-line interface != shell

I realize that. That's why I was talking about a hypothetical where it was designed all together, instead of evolving over the decades like we did.

In the situation we actually have, the shell is the only single entity that's in a position to actually do this. The terminal emulator doesn't know when a command completes. Of course, it doesn't have to be solved in a single entity. It would make sense to have the shell signal command completion to the terminal emulator, and let the terminal emulator do whatever it wishes with that information, which could include resetting any garbage state.

[tuetuopay]

> a command outputting an incomplete line without a line terminator is producing garbled non-textual output

I would argue that no, there are many valid cases for commands to not produce a final \n in their output. The first example that come to mind is curl'ing a REST API whose body is a single line of JSON. Many of those will not bother with a final \n, and this does not qualify as "garbled output" in my book. I would even go as far as saying that a shell just printing the prompt at whatever place the cursor happens to be is a side-effect of how terminal emulation works and the fact it's just a character based terminal.

This is actually something that Warp does pretty well, with a strong integration with the shell where your command is in a dedicated text box, by the virtue of it being GUI and leveraging GUIs. (I don't use it however, I'm too much of a sucker for dense UIs).

However I do agree with your argument that it's not the role of the shell to protect you against `cat /dev/urandom` or `cat picture.png`. And fish indeed does not try.

IMHO a shell is built for humans when in interactive mode (one of the raison d'être of fish), and the lack of final \n is such an annoyance that handling this specific edge case is worth it.

[schoen]

I understand the terminal-garbling issue and know that I should run "reset" in this case (and that it wasn't the shell's fault), but I bet a lot of users who aren't very familiar with this might feel that the shell is "in charge of" the terminal or "in charge of" the whole interaction, and so that it actually should be more proactive in making sure that the terminal is in a visible sensible, usable, understandable state as often as possible -- in this case probably whenever a program exits and a new prompt is displayed?

[kevin_thibedeau]

> The newline is a line terminator, a command outputting an incomplete line without a line terminator is producing garbled non-textual output.

A command could very well be manipulating the cursor on its own and intentionally not writing newlines when it wants to overwrite text such as in a progress bar.

[latexr]

> seams

The correct spelling is “seems”. I first assumed it was a typo, but since you did it twice I thought you might like to know.

[gucci-on-fleek]

> I can’t ever remember seeing a bug in either bash

Shellshock [0] is a rather famous example, but bugs like that are rare enough that they make the news when they're found.

[0] https://en.wikipedia.org/wiki/Shellshock_%28software_bug%29

[rkeene2]

I had a fun bug where bash would run scripts out of order!

This would lead to impossible states, like

if cat foo | false; then echo hmm; fi

Producing output sometimes, depending on whether or not `cat foo` or `false` return value was used

[0] https://lists.gnu.org/archive/html/bug-bash/2015-06/msg00010...

[lhmiles]

This was an interesting read.

[probably_wrong]

Depending on how you define "bash" and "bug", funny things happen when you run on a computer with 0 remaining hard drive space.

[CaptainOfCoit]

To be fair, bash won't be the only thing struggling when you end up in that state.

[AdieuToLogic]

> Joking aside I can’t ever remember seeing a bug in either bash or zsh, never seen either crash or segfault and anytime I’ve had weirdness it’s always turned out to be me missing something.

Given that this statement begins with "joking aside", I have to assume it is either a meta-joke or an uninformed opinion. Taking the subsequent sentence into account thoroughly reinforces the former.

Well played. :-)

[PokestarFan]

I've been able to trigger a segfault in zsh with certain plugins, a directory with a lot of files/folders, and globs with a bunch of * characters.

[qwertox]

Amen.