Right, I forget that it's not the default to print a \n as the first character of your PS1. Doesn't make sense to me that this isn't the default, as there are quite a few commands that might not end with a newline and then it messes up the prompt position, and it doesn't impact backwards compatibility to add it now.
I don't have this problem (even though I don't use bash) since the first character in my prompt is a newline. I think it makes things easier to read in general.
I use a custom prompt that indeed starts with a newline. I like that it gives better visual distinction between the output of commands and the prompt; it's also indeed a workaround for when commands don't put a newline at the end of their output.
This made me think how trailing newline is actually bit weird. Wouldn't it make more sense to just have shell prompts always start with newline and commands not outputting trailing newlines as gratuitously as they do now?
function __col1_ps1 {
[[ $MC_SID ]] && return
local termios cur_y
# ask the terminal for any pending (line buffered) input
termios=$(stty --save) && stty -icanon && stty "$termios"
# if there's pending input, assume it's been echoed and we're not in first column
# otherwise ask the terminal for current column and read it from input
if read -t 0 || { IFS='[;' read -s -r -d'R' -p$'\033[6n' _ _ cur_y && [[ $cur_y != 1 ]]; }; then
echo $'\001\033[41m?\033[m\002\n\001\r\002'
fi
}
PS1='$(__col1_ps1)<the rest of my prompt>'
Exactly. I got tired of the occasional command that didn't add a final newline, often my own sloppy "perl -e" output. So, my prompt starts with a newline, just in case the previous command had unfinished business.
I added a newline (\n) to the beginning of my prompt. This way I never lose program output -- and also it's easier to see where previous commands begin and end in the scrollback buffer.
huh, that's actually the first time I've heard a somewhat reasonable answer for that question. I wonder why pep8 gives such a terrible reason (editors that show newline chars) when there's actually a somewhat defensible reason. I still disagree with it, and other guides don't appear to consider this a problem even for projects like the linux kernel, which considers terminal users to be first class citizens, but it's at least nice to know a better reasoning than showing newline chars.
Now, see, that's the kind of ignorance the article was trying to treat. It's very much not microsoft's fault. Early teletypes had two command bytes: "\n" (newline) would advance the paper, and "\r" (carriage return) would move the type head (on a typewriter, the paper carriage -- thus the name) back to the start of the line. If you wanted to do both, you had to send both.
So if you have a text file to print, you'll either need to include both command bytes or else have some "terminal driver" software do the translation for you from a single "end of line" marker. This feature was a Unix innovation. It didn't exist in other contemporary systems (VMS, for instance, from which CP/M and MS-DOS stole lots of other ideas).
So the problem was that Gary Kildall, in 1977, failed to recognize the great idea Unix had and cloned VMS behavior instead (and Bill Gates likewise cloned CP/M instead of Unix). And due to backwards compatibility pressure we're still living with the result. But it's clearly not a case of someone having made the "wrong choice".
I believe you are misunderstanding. The feature ensures that your (empty) prompt is printed at the start of a line, even if the preceding command's output doesn't end with a newline.
Start up fish and run `echo -n foo` to see `foo?` in your terminal.
Just out of curiosity, which systems uses \r as newline these days? As far as I understand it, Mac OS did it prior to its version 10 (its Unix version), but the modern macOS does not.
> So yeah, I'd consider it a bug if it didn't support what has been the standard line ending format since the 60's.
The standard line ending format in the '60s, which was the height of the mainframe era, would probably have been the newline character in IBM's EBCIDC encoding, which differs from the value used for ASCII (https://en.wikipedia.org/wiki/Newline). Unix didn't really start taking off until around the early '80s IIRC.
Windows properly supported the newline format for its platform of lineage (CP/M + DOS) which also didn't start taking off until the early '80s. Not sure that Unix has any real claim to precedence here.
The use of ASCII '\n' to move the the start of the next line in UNIXes is merely a historical accident. There were plenty of other operating systems, some of which predate UNIX itself, which used other encodings: see https://en.wikipedia.org/wiki/Newline#Representations_in_dif...
reply