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.
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.
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?
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 do not like this feature. How can you distinguish the output of a program that outputs a newline from one that doesn't? This is intentional obfuscation. If you are bothered from where your prompt starts, add a newline at the beginning of your prompt.
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 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.
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.
And it's not at all surprising that it honours a command without a newline. Commands are terminated by semicolons, newlines OR EOF. That's pretty much how all shells work. You really wouldn't want the last line of a shell script to be ignored simply because someone didn't put a newline at the end of it.
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. :)
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.
;; For tramp with my bash config, the prompt of which terminates
;; in a newline. Tell tramp how to detect the end of my prompt.
(setq shell-prompt-pattern "
")
The value of the shell-prompt-var is a literal newline. (That newline entered, naturally, with a C-q C-j.)
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.
reply