Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
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.
Feb 23, 2021 at 0: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.
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.
@variableexpander, the $ at the start marks a shell prompt I new that, I just prefer markdown over using that :)
Feb 23, 2021 at 11:00
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).-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.