The newline cat mystery
petefreitag.com
petefreitag.com
perhaps: "the terminal correctly displayed the file, overwriting the printed line at each CR, with the last line blank"
https://unix.stackexchange.com/questions/355559/bash-and-car...
Foofoo\rbar\r
Should show as
barfoo
With the cursor over the start of that line.
[dale@host ~]$ echo -n "hi" > test
[dale@host ~]$ cat test
hi[dale@host ~]$
[dale@host ~]$ echo -en "hi\r" > test
[dale@host ~]$ cat test
[dale@host ~]$/r means "slash, then the letter r". \r means carriage return, which doesn't clear the line, just moves the cursor to the left margin. Unless you're on an Apple ][, in which case CHR$(13) moves to the beginning of the next line, but still doesn't clear anything. And CHR$(4) is where the real magic happens, but it has to follow a CHR$(13)!
]PRINT CHR$(4) + "INIT HELLO"
...
Point is, \r goes to the beginning of the line, without going to the next one, as you reiterated, so you can output a spinner using
-
/
-
\Try this:
$ echo -ne "ooo\rf\n"
foo
Carriage return is a carriage return, not a delete or backspace or clear line.
To be fair it isn't.
On typewriters it also adds a new line. On Mac, it is (used to be?) the new line character.
I don't know how non vt terminals handled it.
>> most of them do. it's what a /r means. it's how cli programs can easily output a spinning wheel/similar for busy status.
You did.
printf "%%%$((COLUMNS - 1))s\\r%1s\\r"
> Attempt to preserve a partial line (i.e. a line that did not end with a newline) that would otherwise be covered up by the command prompt due to the PROMPT_CR option. This works by outputting some cursor-control characters, including a series of spaces, that should make the terminal wrap to the next line when a partial line is present (note that this is only successful if your terminal has automatic margins, which is typical).
> When a partial line is preserved, by default you will see an inverse+bold character at the end of the partial line: a ‘%’ for a normal user or a ‘#’ for root. If set, the shell parameter PROMPT_EOL_MARK can be used to customize how the end of partial lines are shown.
cat: README: No such file or directory
I'd occasionally get email from frustrated people who had trouble trying to read the README file, so I'd tell them to simply run "emacs README", and emacs would solve all of their problems. I don't know if my passive aggressive emacs evangelism ever worked, because I never heard back from them.
Bringing the cursor back doesn't delete what was output. It's writing over it with the second line and the shell prompt that deletes it.
If you set `PS1='$ '`, one should be able to see part of both lines:
$ printf '"order_id","date"\r"1","2023-01-01"\r'
$ ","2023-01-01""> Now one thing that I should have noticed was that the file size was 9 bytes
The file contains more than 9 characters. What was the author trying to say?
...this is the only way.
share and enjoy
https://www.gnu.org/software/termutils/manual/termcap-1.3/ht...
cat -v
`cat` usually does one thing: concatenate the contents of the inputs you give in the order you give them. Of course, if the user gives only one input, it will only print that.
It is not a text viewer even though many *nix users use it that way because they learned it that way, because a series of tutorials taught the wrong thing to generations. The very first one probably came from a very limited and very bad Unix environment like a server that is hostile to active development. So the tutorial used whatever core utility that's available: cat, beginning the multi-generational bad habit.
Saying "cat is not a text viewer" is absurd, though - the history of Unix is that the "print" command was removed when the Unix devs realized that cat did the same thing already, and so told their users to just use cat with a single argument.
I'm not saying it was good design, but it was intended design.
it's not built into our text format (our being us,-unix-before-unicode). It's built into the terminal.
The file format is 8-bit clean as it should be, any other values are going to have to be out-of-band. The unix stream format follows the file format, with the exception of
the terminal format (and the comms format) is 7-bit ascii with varying amounts of ANSI control, but that's on you, you bought the terminal...
ANSI escape sequences do also include control codes but there’s plenty in ASCII too.
Frankly, you only need to spend 30 seconds looking at an ASCII table to see this.
Source: I’m an author of an alt $SHELL
Since we've all read the docs, but a bunch of you are laboring under misimpressions, I'm trying to say things in an unusual but truthful way to be the iceberg to the titanic of misunderstanding that thinks the BEL character doesn't belong in ANSI's ASCII protocol
ANSI's escape sequences came later to control more functions for glass teletypes.
While I'm sure the actual code looked different, the "spirit" of the code builds a CSV file by concatenating strings and specifying raw ASCII codes. Building a CSV file like this on 2023 is guaranteed to cause bugs down the line.
Had the code used the Python CSV primitives, or at least had the author let Python convert the "\n" character to the OS-dependent representation, the bug would have been avoided entirely. The author just happened to run into it with `cat` instead of, say, a CSV parser confused about the unusual choice.