5 ms·

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

• patrec 6y ago
  In unix every text file is basically a (possibly degenerate, Nx1) matrix and every row is terminated (and demarcated) by a newline. This makes it much easier to filter, concatenate and rearrange rows. Try rewriting this: cat <(cmd1...) <(cmd2...) >> some_output for a world without final terminating newlines.
  • zokier 6y ago
    cat foo <(printf "\\n") bar ?
    • patrec 6y ago
      Nope :) (Hint: what's the neutral element?)
      • patrec 6y ago
        You'd need something like this: cat <(cmd1... | awk -vRS='\0' '""$0') <(cmd2... | awk -vRS='\0' '""$0') >>output
  • wwright 6y ago
    Interleaving multiple commands/stdout and stderr as well.
• 1996 6y ago
  As the path can be long, I do this: a first line for the things the shell want to displays, a second line for the things I type # (user@server):/where/I/am # This gives something like # (user@server):/where/I/am # cd now # (user@server):/where/I/am/now # The # is used because I sometimes copy-paste, and I want to avoid problems
  • Tyr42 6y ago
    I use the same pattern, if only because I've not mastered the art of naming directories with clear and short names, so my $PWD tends to get rather long. Add in any git nonsense, and I end up line wrapping anyways. Much cleaner to always put a newline after the $PWD
  • roelschroeven 6y ago
    Same here (except the #). The advantage is not only that it prevents problems with very long paths and/or commands, but it also makes every command I type start at the same offset from the left, irrespective of the length of the path. Much cleaner that way, IMO.
• roelschroeven 6y ago
  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.
• mantap 6y ago
  imagine a program such as: print("hello") time.sleep(10) print("goodbye") If's impossible for the program to know which print is the last one, as the user may kill the program during the sleep. I guess in a parallel universe you could have print issue a newline first. Not sure I want to live in that universe.
  • hnlmorg 6y ago
    The shell would know when the program has been finished for the same reason it knows when to print the shell prompt. The issue isn't that the shell is unaware of the state of the process, it's that the shell simply doesn't know where the cursor is nor what output a process has written to a TTY. And in fact a TTY can even be written to by processes outside of the same shell process group (since they're all just files in /dev).