Later on in deployment, it will go somewhere else. Somewhere that has been evaluated for being able to handle it.
In that way, /dev/null is to storage what `true` is to execution - it just works.
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.
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.
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.
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.
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.
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.
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.
I think that even when you would design it all today the distinction between interface and running program would still be useful, otherwise every program would need to implement it's own interface and a shell does more than just communicate interactively with the computer. It's also a task runner, program orchestrator, controls program selection and allows for automating other programs.
> 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.
The thing is, it kinda works this way already. I'm not that knowledged about the actual interaction, but the shell already tells my terminal what the current directory is, which programs it has invoked, so that my terminal emulator can show me this in the chrome.
Ok, so my stance is: Yes it is not the job of the shell to modify the output of some program, but it is the job of the shell to tell the terminal emulator to do that, when the user requests this. I'm positively minded, that actually someone can chime in and say "ah, that's just not the default, you can configure bash, readline, etc. to do that though." I think the thing is, that bash just assumes that programs are POSIX-compliant and POSIX specifies, that every programs outputs a newline. Actually POSIX doesn't define it as newline, it defines it as the end of line. A program that forgets LF doesn't have forgotten to advance output a newline, it has output an incomplete line in that reading.