[pacman-dev] [PATCH] contrib/pacdiff : big rework and cleanup

Aaron Griffin aaronmgriffin at gmail.com
Wed Feb 18 11:35:38 EST 2009


On Wed, Feb 18, 2009 at 1:41 AM, Xavier <shiningxc at gmail.com> wrote:
> On Wed, Feb 18, 2009 at 12:22 AM, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
>> On Tue, Feb 17, 2009 at 4:44 PM, Xavier Chantry <shiningxc at 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


More information about the pacman-dev mailing list