4 ms·

It doesn't (bash, GNU grep). Shell expands inside double quotes. grep does not run commands in a re.

dozzie 9y ago
> It doesn't (bash, GNU grep). It can, you just incorrectly guessed what's the required input for it to work (the author didn't do a very good job at showing the environment in line 29). If you pass to grep a multi-line argument as the pattern (or a pattern, for -e option), grep will treat each line of this argument as a separate pattern. Or at least that's what GNU grep is doing. "echo ${data}" worked (and only somewhat and accidentally) because while the first line of ${data} got a prefix of "echo ", the other lines stayed the same. `cat filelist.txt` didn't work, because grep got the content of filelist.txt as a separate arguments (one word per line, if I guess the content correctly) thanks to shell's word splitting, so grep treated the first filename as a pattern and the rest of the filenames as files to search for the pattern. If the filelist.txt contained a name that didn't exist, grep would print an error message for ENOENT. Note that in this scenario the output of `ls' was not read by grep at all. If it was "`cat ...`" (double-quoted form), wordsplitting wouldn't take place and the grep call would work as the author was expecting.
- 8_hours_ago 9y ago
  Yep, this is the correct answer! I was just writing up something similar, but you beat me to it. This is the expected behavior if the `data` variable has newlines between every word: $ echo ${data} testfile1 testfile2 testfile3 testfile4 testfile5 testfile6 testfile7 testfile8 testfile9 testfile10 $ echo "${data}" testfile1 testfile2 testfile3 testfile4 testfile5 testfile6 testfile7 testfile8 testfile9 testfile10 $ echo "echo ${data}" echo testfile1 testfile2 testfile3 testfile4 testfile5 testfile6 testfile7 testfile8 testfile9 testfile10

> It doesn't (bash, GNU grep). It can, you just incorrectly guessed what's the required input for it to work (the author didn't do a very good job at showing the environment in line 29). If you pass to grep a multi-line argument as the pattern (or a pattern, for -e option), grep will treat each line of this argument as a separate pattern. Or at least that's what GNU grep is doing. "echo ${data}" worked (and only somewhat and accidentally) because while the first line of ${data} got a prefix of "echo ", the other lines stayed the same. `cat filelist.txt` didn't work, because grep got the content of filelist.txt as a separate arguments (one word per line, if I guess the content correctly) thanks to shell's word splitting, so grep treated the first filename as a pattern and the rest of the filenames as files to search for the pattern. If the filelist.txt contained a name that didn't exist, grep would print an error message for ENOENT. Note that in this scenario the output of `ls' was not read by grep at all. If it was "`cat ...`" (double-quoted form), wordsplitting wouldn't take place and the grep call would work as the author was expecting.

8_hours_ago 9y ago
Yep, this is the correct answer! I was just writing up something similar, but you beat me to it. This is the expected behavior if the `data` variable has newlines between every word: $ echo ${data} testfile1 testfile2 testfile3 testfile4 testfile5 testfile6 testfile7 testfile8 testfile9 testfile10 $ echo "${data}" testfile1 testfile2 testfile3 testfile4 testfile5 testfile6 testfile7 testfile8 testfile9 testfile10 $ echo "echo ${data}" echo testfile1 testfile2 testfile3 testfile4 testfile5 testfile6 testfile7 testfile8 testfile9 testfile10