Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

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.


sort by: page size:

Something like "\w\n\$ " should work; mine is more complex by the idea holds, you can have a \n in your PS1 just fine.

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?

Another useful thing to have in one's PS1 is an optional newline if the last output didn't print one itself. Turns out this is non-trivial to get working perfectly (https://stackoverflow.com/questions/19943482/configure-shell..., https://work.lisk.in/2020/11/20/even-faster-bash-startup.htm...). The version that I've been using for a while without problems is this one:

  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>'
My full prompt is here: https://github.com/liskin/dotfiles/blob/9785740f7f97d7da1f84...

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.

All too often, this "erases" legitimate output. I just prefix my prompt with a \n, personally.

I actually have the full path in my PS1, and it actually spans two lines with the second line being only “$ “.

The reality if my life is that I often work with long paths, and having the full path around saves me some pwd fairly often.


Funny you mention echo, which prints a newline by default as well.

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".


Glad you like it! =)

It's supposed to be usable "inline", so it shouldn't print a newline. (E.g. `touch note-$(tu yesterday).md`)

Some terminals have an option to still write the $ prompt to the next line and use an enter symbol (?) to signify that no newline was printed.


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.


Serious question.

Are they doing the wrong thing? Is there a standard that says the only line ending is \n.

Is the Mac also doing the wrong thing then but using just \r?


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...

That's definitely a Zsh thing, showing that there was no newline: https://zsh.sourceforge.io/Doc/Release/Options.html#Promptin.... It's not to do with PS1 or PROMPT, or head.
next

Legal | privacy