3 ms·

Which is why it makes more sense for \r\n to be the *nix line ending - because there is a distinct "carriage return (on same line)" from "line feed (at same car

Which is why it makes more sense for \r\n to be the *nix line ending - because there is a distinct "carriage return (on same line)" from "line feed (at same carriage position)" operations possible, and combining them together makes carriage return and line feed to put the cursor at the start of a new line. And why it makes more sense for \n to be the common Windows line ending because it doesn't have that TTY ancestry.

Arnavion 4y ago
That would make sense except you have them the wrong way around.
- jodrellblank 4y ago
  I have them the right way around, it's everyone else who has them the wrong way around.
- tbrownaw 4y ago
  Sometimes when theory doesn't match reality, it's reality that's wrong.
- Dylan16807 4y ago
  I don't see anything that says which is which in that comment. Just what makes sense.
juped 4y ago
What's even more nuts about Unix 300-layers-of-tty-emulation \n acting like a CRLF is that \r still works just fine as CR. e.g., you can get a nice little clock with: while true; do echo -n " $(date)\r"; sleep 1; done
- Athas 4y ago
  I need to use printf to interpret the escape character: while true; do printf " $(date)\r"; sleep 1; done
  - schoen 4y ago
    It might also work with "echo -e".
  - hbossy 4y ago
    I like my terminals a little bit cleaner: printf '\033c'; while true; do echo -en " $(date)\r"; sleep 1; done
- jjjz 4y ago
  (don't forget "-e" for echo) while true; do echo -en " $(date)\r"; sleep 1; done
  - faho 4y ago
    Depends on your echo. Zsh's interpretes escape sequences by default unless the "BSD_ECHO" option is used, bash's doesn't unless "xpg_echo" is on. And xpg_echo is on by default for bash on macOS, so for users on macOS it looks like echo interprets escapes by default. This is one of the reasons why echo is hopelessly unportable. See https://unix.stackexchange.com/a/65819/55665 https://unix.stackexchange.com/a/65819/55665
    - jrumbut 4y ago
      Learn something new every day! And I wish we had a stronger word than unportable for echo. You see that word tossed around on shell scripting resources where the only system it applies to is a 30 year old version of ksh and it only blows up on a full moon when passed a filename with a literal form feed \f, but echo is a practical portability problem.

Arnavion 4y ago

That would make sense except you have them the wrong way around.

jodrellblank 4y ago
I have them the right way around, it's everyone else who has them the wrong way around.
tbrownaw 4y ago
Sometimes when theory doesn't match reality, it's reality that's wrong.
Dylan16807 4y ago
I don't see anything that says which is which in that comment. Just what makes sense.

juped 4y ago

What's even more nuts about Unix 300-layers-of-tty-emulation \n acting like a CRLF is that \r still works just fine as CR. e.g., you can get a nice little clock with: while true; do echo -n " $(date)\r"; sleep 1; done

Athas 4y ago
I need to use printf to interpret the escape character: while true; do printf " $(date)\r"; sleep 1; done
- schoen 4y ago
  It might also work with "echo -e".
- hbossy 4y ago
  I like my terminals a little bit cleaner: printf '\033c'; while true; do echo -en " $(date)\r"; sleep 1; done
jjjz 4y ago
(don't forget "-e" for echo) while true; do echo -en " $(date)\r"; sleep 1; done
- faho 4y ago
  Depends on your echo. Zsh's interpretes escape sequences by default unless the "BSD_ECHO" option is used, bash's doesn't unless "xpg_echo" is on. And xpg_echo is on by default for bash on macOS, so for users on macOS it looks like echo interprets escapes by default. This is one of the reasons why echo is hopelessly unportable. See https://unix.stackexchange.com/a/65819/55665 https://unix.stackexchange.com/a/65819/55665
  - jrumbut 4y ago
    Learn something new every day! And I wish we had a stronger word than unportable for echo. You see that word tossed around on shell scripting resources where the only system it applies to is a 30 year old version of ksh and it only blows up on a full moon when passed a filename with a literal form feed \f, but echo is a practical portability problem.