On Wed, Feb 18, 2009 at 1:41 AM, Xavier <shiningxc@gmail.com> wrote:
On Wed, Feb 18, 2009 at 12:22 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Tue, Feb 17, 2009 at 4:44 PM, Xavier Chantry <shiningxc@gmail.com> wrote:
+exec 3< <(cmd) +while IFS= read -r -d '' pacfile <&3; do ... +exec 3>&-
Wow this looks ugly. Is the anything gained over using a construct like this:
cmd | while read pacfile; do ... done
In practice, I guess not much. In theory, this is the only way to deal with any kind of filenames.
-print0 True; print the full file name on the standard output, followed by a null character (instead of the newline character that -print uses). This allows file names that contain newlines or other types of white space to be correctly interpreted by pro‐ grams that process the find output. This option corresponds to the -0 option of xargs.
And I believe that your construct cannot deal with this null character separation. Unfortunately that construct I used also required a redirection, because we still need to read the terminal input inside the loop (for read and vimdiff). The best is to use find -exec, but unfortunately locate does not support that.. Anyway, I am fine if you want to aim more for readability rather than correctness, it's very unlikely we are going to encounter weird filenames with this script. I can easily switch "cmd | while read pacfile; do", it has been an useful exercise for me anyway.
That's why I don't use print0 for this sort of stuff. "while read line" will use newlines as separators. If you remove the -print0 and -0 args to find and locate (respectively), then my construct should work fine