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.
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.
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?
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 honestly cannot replicate either of these behaviors, even using the OS X Terminal application (which definitely causes serious cursor synchronization issues with complex prompts due to incorrect terminal emulation: use iTerm2 instead), and even using an old version of bash (tested on both Linux and OS X).
A) When I hit ^C, I am always seeing a newline occur after the ^C and before my prompt is redrawn. I have tried this with cat (blocked on read) and ssh (blocked on password).
B) When I purposely attempt to cause this (using echo -n and interpreting "a very long command" to mean "long enough that it wrapped to the next line"), hitting up redraws and overwrites part of the prompt in order to guarantee that the position of the prompt will edit correctly.
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.
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.
For what it's worth, Terminal doesn't do anything special with line breaks on shell prompts. PowerShell, however, might.
If you're using powershell, you can escape newlines with `. If git bash, \. If CMD, I don't know what to tell you -- I don't use it for any serious work. :)
I've moved to two line prompts everywhere as well, the second line being basically just " > "
I've also added inter prompt spacing.. first that was just an extra \n before the prompt, but I decided I wanted space between the prompt and the start of program output, as well as between the end of output and the next prompt.
I can't remember where I stole the idea from to give credit, and it feels a little wrong but works really well:
For bash, in PROMPT_COMMAND, set a debug trap that writes a newline, and then removes itself "trap - DEBUG".
If it's not obvious the debug trap fires right after you hit return, but before the command actually runs ( also making it a nice place to update xterm/tmux titles ). So that gets you your post prompt newline, but then because the traps removed it doesn't keep firing for every command in you for loop or whatever.
But PROMPT_COMMAND adds the trap again for the next time.
I also have some weird logic in prompt_command that only adds the preprompt newline if the cursor isn't in column 0, because I found otherwise I was getting unnecessary extra spacing.
So yes, if I hit enter on a plain prompt I get two blank lines before the next one.. so?
But it makes differentiating output so much easier. Combine with colour prompts with timestamps ( and in history too ) and I get at least rough timing on how long tasks take, which is often useful.
It's actually on monochrome terminals (for whatever dumb reason that might be happening) that it helps the most, to the point where now when I see a non customised terminal my reaction is "urhg.. what's all this mess, take it away" <shooing wave of hands>
That and pspg for database/csv viewing make my daily life measurably better.
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.
If a file doesn't have a newline at the end then `cat` will immediately start writing the prompt after the last line; this is the same behavior you'd expect from sh or bash. We might later improve this by having a "no newline"-indicator in the promptline instead.
Output that doesn't end in LF is pretty annoying in general, since the shell prompt gets visually tacked on to the end. I have this as part of my PROMPT_COMMAND:
printf "%%%$((COLUMNS - 1))s\\r%1s\\r"
Effectively, it adds the missing newline in those cases and puts a '%' at the end of the output to let you know. The implementation is tad bit of printf trickery that leverages your bash's line wrapping.
reply