According to this manual -r for read:
Do not allow backslashes to escape any characters
I understand that generally, the read shell builtin gets input and creates a variable which holds that input as a string in which backslashes would be just literal components and wouldn't escape anything anyway.
Is read -r only used in rare exceptional usecases of read (with the common denominator of the output being anything else than a string)?
I understand that generally, the read shell builtin gets input and creates a variable which holds that input as a string in which backslashes would be just literal components and wouldn't escape anything anyway.
Plain read var, without -r, when given the input foo\bar, would store in var the string foobar. It treats the backslash as escaping the following character, and removes the backslash. You'd need to enter foo\\bar to get foo\bar.
read can be used to read multiple values, like so:
$ read a b <<< 'xx yy'; echo "<$a> <$b>"
<xx> <yy>
(<<< is a "here-string", the following string is provided to the command as input.)
It uses the characters in IFS as separators, so whitespace by default.
It's these separators that a backslash can be used to escape, making them regular characters, and removing the backslash, also if it appears in front of a regular character. So you'd get:
$ read a b <<< 'xx\ yy'; echo "<$a> <$b>"
<xx yy> <>
$ read a b <<< 'xx\n yy'; echo "<$a> <$b>"
<xxn> <yy>
Being able to escape the separators is seldom useful, and removing backslashes can also be annoying if someone wants to enter a string with C-style character escapes.
In addition, a backslash at the end of a line would make read wait for another line to be read as a continuation of the first, similarly to how continuation lines work in C and in the shell.
With read -r, backslashes are just a regular character:
$ read -r a b <<< 'value\with\backslashes\ yy'; echo "<$a> <$b>"
<value\with\backslashes\> <yy>
In many use cases, backslashes aren't something one would expect the user to input, and if there aren't any, read -r is the same as plain read. But in case someone were to (need to) input backslashes, using read -r may reduce the surprises involved. Hence it's probably good to use it, unless you really know you want them to be special for read (in addition to whatever special properties your program might otherwise assign to them).
$ read a b <<< 'xx yy'; echo "<$a> <$b>" code examples; I am having hard time to understand these; I humbly suggest to change how the code examples are formatted and/or removing the herestrings and focusing on a more intuitive feature for input. Especially the use of $ at the start and not separating input from output to two different blocks makes it hard for me.
– variableexpander
Feb 23 '21 at 00:49
$ at the start marks a shell prompt, it's a somewhat usual custom to separate commands from output. It's hard to do italics or such in code blocks to mark that. And partly related to that, at least I try not to write code blocks where there's user input anywhere other than the command line, since it's not easy to mark which part is input and which part is output.
– ilkkachu
Feb 23 '21 at 10:55
somecommand <<< "foo bar" is pretty much the same as echo "foo bar" | somecommand, except that with read, the latter couldn't store the output variables, so it doesn't work there. And I'm not sure something like echo 'xx yy' | ( read a b; echo "<$a> <$b>" ) would be any clearer.
– ilkkachu
Feb 23 '21 at 10:56
@variableexpander, the $ at the start marks a shell prompt I new that, I just prefer markdown over using that :)
– variableexpander
Feb 23 '21 at 11:00
read a b and give it the input xx yy, then $a and $b contain xx and yy, respectively" and did something like that in the first paragraph (which I actually wrote separately from the rest, so maybe that's why). But it's a lot more to write, and harder to copypaste from the terminal where you actually ran the command. Making sure the command is right is useful too, and no-one wants to spend time for unnecessary stuff (because humans are lazy...). That read <<< blah; echo isn't perfect though, with the input to read in the middle.
– ilkkachu
Feb 23 '21 at 11:21
readwithout-rand without explicitly setting$IFSfor that onereadinvocation to the list of delimiters you wantreadto use to delimit words (or the empty string, if you don't want splitting). – Stéphane Chazelas Feb 22 '21 at 17:26readoutputting anything; it merely sets variables. I agree thatread -rmakes sense in the majority of cases; it is the special treatment of backslashes that is the exception. But this is just an opinion. – berndbausch Feb 22 '21 at 17:53makes sense in the majority of cases; I actually thought it only makes sense in rare exceptional cases; me, as a non professional, amateur sysadmin which only does some of my own small-scale shared-hosting/PaaS system administration --- I don't recall ever using it and I never had a problem when I didn't use it; hence I took an opposite approach than of Stéphane Chazelas and of yours and now I seek to learn why I was wrong in doing so. – variableexpander Feb 22 '21 at 18:07-eoption (similar to what Dennis Ritchie did toechoin V8 in the early 80s), but unfortunately that was later reverted as portability with the Bourne shell was deemed more important than a cleaner design. – Stéphane Chazelas Feb 22 '21 at 18:18