IFS=',' /usr/bin/read vs IFS=',' read

Question

Context

$ bash --version
GNU bash, version 4.4.19(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.$ which read
/usr/bin/read

$ which read
/usr/bin/read

Can someone explain why Example 1 below works and Example 2 does not?

Example 1 - bare read works

This:

declare data
data="pig,cow,horse,rattlesnake,"
declare -a my_array
IFS=',' read -r -a my_array <<< "$data"
for item in "${my_array[@]}"; do echo "$item"; done

Produces:

pig
cow
horse
rattlesnake

Example 2 - /usr/bin/read fails

This produces no output:

declare data
data="pig,cow,horse,rattlesnake,"
declare -a my_array
IFS=',' /usr/bin/read -r -a my_array <<< "$data"
for item in "${my_array[@]}"; do echo "$item"; done

Answer 1

read is a shell builtin, i.e. a command that is provided by the shell itself rather than by an external program. For more information about shell builtins, see What is the difference between a builtin command and one that is not?

read needs to be a builtin because it modifies the state of the shell, specifically it sets variables containing the output. It's impossible for an external command to set variables of the shell that calls them. See also Why is cd not a program?.

Some systems also have an external command called read, for debatable compliance reasons. The external command can't do all the job of the command: it can read a line of input, but it can't set shell variables to what it read, so the external command can only be used to discard a line of input, not to process it.

which read doesn't tell you that a builtin exists because that's not its job. which itself is an external command in bash and other Bourne-style shells (excluding zsh), so it only reports information about external commands. There's very rarely any good reason to call which. The command to find out what a command name stands for is type.

bash-5.0$ type read
read is a shell builtin

Answer 2

read is also a shell built-in, which which doesn't know about. Try running:

$ type read
read is a shell builtin

As for why /usr/bin/read doesn't work, I'm not sure what app that is as I don't have it installed on my system, but most likely the shell built-in is the one you want.

Answer 3

read is a shell builtin that affects the current environment. /usr/bin/read is an external command that runs in a subshell and so can't.

So why do we have /usr/bin/read at all, since it's practically useless? The answer is POSIX. It requires builtin commands to also exist as an external command!

So, for example, there's also a /usr/bin/cd command. Let's walk that through... it creates a sub shell, runs the script (which is basically builtin cd "$@") and then exits... so it does nothing useful.

The rationale for this oddity is described here: https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap01.html#tag_23_01_07

Answer 4

why Example 1 below works and Example 2 does not?

Because the read command being executed is not the same.
Thus each one acts differently.

We can set an external executable to explicitly show the difference:

sudo mv /usr/bin/read /usr/bin/read.back  # keep a backup
echo $'#/bin/bash\necho "This is an external $0"' | sudo tee /usr/bin/read
sudo chmod a+x /usr/bin/read

With the executable changed, this still works:

read a b c <<<'one two three'
echo "$a $b $c"

But this (obviously) doesn't:

/usr/bin/read a b c <<<'111 222 333'
echo "$a $b $c"

The reason is that in bash (and in most of POSIX shells) there is an order to find commands. The first command found is the one that gets executed. That order may be shown by type -a in bash:

$ type -a read
read is a shell builtin
read is /usr/bin/read
read is /bin/read

Which explains why the builtin is executed even if there are external executables that have the same effective name.

The reason why Redhat provides an external /usr/bin/read is a bit more complex and is actually related to the way POSIX works.

Answer 5

As mentioned by others, "read" is a shell built-in. On my system, there is no /usr/bin/read. However, man read informs me:

NAME read - read from a file descriptor

SYNOPSIS #include <unistd.h>

ssize_t read(int fd, void *buf, size_t count);

DESCRIPTION read() attempts to read up to count bytes from file descriptor fd into the buffer starting at buf.

So, that kind of read is a system call and programming tool.

HOWEVER! Do not use read at all. You have "data" and you want an array.

IFS=',';my_array=( ${data[@]} )
for item in "${my_array[@]}"; do echo "$item"; done
pig
cow
horse
rattlesnake