4 ms·

I don't understand how this is an answer. If I follow your argument correctly, and totally ignoring for a moment what ${data} might evaluate to, then for the fi

I don't understand how this is an answer. If I follow your argument correctly, and totally ignoring for a moment what ${data} might evaluate to, then for the first command to produce any output it is necessary for the output of ls to at least contain the string "echo". But we can see that it does not, yet the claim (which I haven't tested) is that it does produce output. Why is that?

kazinator 9y ago
It doesn't work, at least in a POSIX-like shell: 0:terada:~$ mkdir testdir 0:terada:~$ cd testdir 0:terada:~/testdir$ data="testfile1 testfile2 testfile3" 0:terada:~/testdir$ touch $data 0:terada:~/testdir$ ls -1 testfile1 testfile2 testfile3 0:terada:~/testdir$ ls | grep "echo ${data}" 1:terada:~/testdir$ I've seen this sort of shenanigan more than once in comp.unix.shell; usually followed by "oops, I somehow confused myself and can no longer reproduce this" type of backpedaling. The submitted web page doesn't have a properly presented repro test case; it's writing about something which allegedly happened on some machine somewhere, possibly with inaccuracies and omissions. We don't know what shell this is. Maybe the command that was actually run was ls | `echo ${data}`, data happened to be empty at the time, and the shell being used expanded that backtick expression to an empty argument instead of expanding to no argument. An empty regex matches everything.
- indigodaddy 9y ago
  This was done on CentOS 7.3.x (not CentOS 6 as I had incorrectly first noted), and the following versions of bash and grep: "GNU bash, version 4.2.46(1)-release (x86_64-redhat-linux-gnu)" "grep (GNU grep) 2.20" So where $data is a newline delimited list of items/patterns: grep "${data}" ..will indeed match each item/pattern individually and grep over each, eg, just as grep -f does against a file with a list of patterns. It doesn't work without the double quotes, and putting the echo in front was obvious derp in hindsight. See my comment where I replied to uraza and demonstrated this.
  - kazinator 9y ago
    Aha! This is a POSIX-required behavior, not documented in the GNU "info grep" or man page. According to POSIX, the syntax is: grep [-E|-F] [-c|-l|-q] [-insvx] -e pattern_list What is pattern_list? "The pattern_list's value shall consist of one or more patterns separated by <newline> characters" In the GNU man page and info, the pattern argument is referred to as the PATTERN metavariable, a noun in singular form. The only hint I can find that it can contain a plurality is this, in the man page: -F, --fixed-strings Interpret PATTERN as a list of fixed strings (instead of regular expressions), separated by newlines, any of which is to be matched. This drops the hint that there may be multiple regular expressions in PATTERN separated by newlines, which may instead be treated as fixed strings. A similar description is in the Info manual. Elsewhere in both documents, PATTERN is misleadingly referred to as "the pattern". This may be worth a documentation patch.
  - kazinator 9y ago
    Documentation patch logged against GNU Grep which thoroughly clarifies that the pattern argument is a newline-separated list. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31400 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31400

kazinator 9y ago

It doesn't work, at least in a POSIX-like shell: 0:terada:~$ mkdir testdir 0:terada:~$ cd testdir 0:terada:~/testdir$ data="testfile1 testfile2 testfile3" 0:terada:~/testdir$ touch $data 0:terada:~/testdir$ ls -1 testfile1 testfile2 testfile3 0:terada:~/testdir$ ls | grep "echo ${data}" 1:terada:~/testdir$ I've seen this sort of shenanigan more than once in comp.unix.shell; usually followed by "oops, I somehow confused myself and can no longer reproduce this" type of backpedaling. The submitted web page doesn't have a properly presented repro test case; it's writing about something which allegedly happened on some machine somewhere, possibly with inaccuracies and omissions. We don't know what shell this is. Maybe the command that was actually run was ls | `echo ${data}`, data happened to be empty at the time, and the shell being used expanded that backtick expression to an empty argument instead of expanding to no argument. An empty regex matches everything.

indigodaddy 9y ago
This was done on CentOS 7.3.x (not CentOS 6 as I had incorrectly first noted), and the following versions of bash and grep: "GNU bash, version 4.2.46(1)-release (x86_64-redhat-linux-gnu)" "grep (GNU grep) 2.20" So where $data is a newline delimited list of items/patterns: grep "${data}" ..will indeed match each item/pattern individually and grep over each, eg, just as grep -f does against a file with a list of patterns. It doesn't work without the double quotes, and putting the echo in front was obvious derp in hindsight. See my comment where I replied to uraza and demonstrated this.
- kazinator 9y ago
  Aha! This is a POSIX-required behavior, not documented in the GNU "info grep" or man page. According to POSIX, the syntax is: grep [-E|-F] [-c|-l|-q] [-insvx] -e pattern_list What is pattern_list? "The pattern_list's value shall consist of one or more patterns separated by <newline> characters" In the GNU man page and info, the pattern argument is referred to as the PATTERN metavariable, a noun in singular form. The only hint I can find that it can contain a plurality is this, in the man page: -F, --fixed-strings Interpret PATTERN as a list of fixed strings (instead of regular expressions), separated by newlines, any of which is to be matched. This drops the hint that there may be multiple regular expressions in PATTERN separated by newlines, which may instead be treated as fixed strings. A similar description is in the Info manual. Elsewhere in both documents, PATTERN is misleadingly referred to as "the pattern". This may be worth a documentation patch.
- kazinator 9y ago
  Documentation patch logged against GNU Grep which thoroughly clarifies that the pattern argument is a newline-separated list. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31400 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31400