0

(Note: Both of these examples may require GNU or BSD find and may not work as-is with the POSIX "edition" of find).

Both of the scriptlets below must be understood as excerpts from way more complex scripts, with the gist having been compacted into a few lines.
As I get the exact same results with both variants, I'm wondering where the differences (respectively: pitfalls) of either implementation may be...

  • var. 1
while IFS= read -r f; do

  echo "reading entry: "$f""

done < <(find ~/workdocs -type f -name '*.pdf' -print)
  • var. 2
while IFS= read -rd '' f; do

  echo "reading entry: "$f""

done < <(find ~/workdocs -type f -name '*.pdf' -print0)


It turned out that the output (which this question is all about here) was entirely identical in both cases. (Tested by redirecting to output log file, then diff'ing both)
Still, I am wondering if there might be any borderline cases which may actually cause the outputs from variant #1 and #2 to differ.

This is what I'd like to know about.

  • 1
    The later handles filenames that contain a newline character. – jordanm Dec 14 '14 at 18:21
  • 2
    The echo quoting is nonsense though: echo "reading entry: "$f"" – Hauke Laging Dec 14 '14 at 18:35
  • 1
    I didn't mean "nonsense" as "unnecessary". I meant it as nonsense. You should really understand what you have done there. It is a good general rule to quote everything in order to minimize the risk of forgetting to quote. – Hauke Laging Dec 14 '14 at 18:41
  • 4
    @syntaxerror There is no contradiction. It is OK to always quote. The point is that in echo "reading entry: "$f"" the relevant part $f isn't quoted at all. It is nonsense, how the quotes are used in that command; not that they are used. – Hauke Laging Dec 14 '14 at 19:04
  • 1
    echo "reading entry: "$f"" -- the variable is NOT quoted. You're echoing the concatenation of 3 strings: "reading entry: ", the unquoted $f and then an empty string "". You want to put the variable inside quotes: echo "reading entry: $f" – glenn jackman Dec 14 '14 at 21:36
0

For the sake of comprehensibility and visibility I abuse an answer for explaining the quoting part. May the SE karma forgive me...

This is (depending on the content of f) a special case, the problem is not easy to see:

> f=foo
> set -x
> echo "reading entry: "$f""
+ echo 'reading entry: foo'
reading entry: foo

The shells debug modus shows just one string. But that is not due to "nested quoting".

A change in the variable content or a change of the command line shows the problem:

> f=foo

> set -x

> echo "reading entry: " $f ""
+ echo 'reading entry: ' foo ''
reading entry: foo

> echo "reading entry: "    $f     ""
+ echo 'reading entry: ' foo ''
reading entry: foo

> f="foo    bar"
+ echo 'reading entry: foo' bar
reading entry: foo bar

If this kind of quoting worked then the spaces would be preserved.

  • Thanks for "abusing" (?) this answer! As said in my comments, it was a long-time false interpretation of yours truly of this quoting stuff. Well, of course I knew that in JavaScript (simple) nested quoting is achieved by using single quotes for the outer and double ones for the inner term. BUT I knew as well that with echo the use of single/double quotes had a totally different meaning (i. e. interpreting $... variables and other things (y/n)). So I assumed the bash way (e. g. echo) is to use double quotes twice. However, had I had a notion of how this is interpreted...oh well. – syntaxerror Dec 15 '14 at 1:11
  • @syntaxerror It's "abuse" because this answer does not refer to the question... I am not familiar enough with Javascript but single and double quotes (or backslashes) can be combined in bash, too: echo "The file '${file}' is empty." That is not the same like echo 'The file "${file}" is empty.' – Hauke Laging Dec 15 '14 at 1:27
  • Yes, that's what I was just trying to point out. In JS, the choice of quotes (single/double) does not change the meaning. But in bash, it will, with usually entirely different results in resolving variables (getting literal $var output instead of their value) etc... – syntaxerror Dec 15 '14 at 2:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.