Re: [PATCH v2 6/8] t7063: drop non-POSIX argument "-ls" from find(1)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:

> Hi Junio,
>
> On Mon, 23 Mar 2020, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
>>
>> > diff --git a/t/t7063-status-untracked-cache.sh
>> > b/t/t7063-status-untracked-cache.sh
>> > index 190ae149cf3c..ab7e8b5fea01 100755
>> > --- a/t/t7063-status-untracked-cache.sh
>> > +++ b/t/t7063-status-untracked-cache.sh
>> > @@ -18,7 +18,12 @@ GIT_FORCE_UNTRACKED_CACHE=true
>> >  export GIT_FORCE_UNTRACKED_CACHE
>> >
>> >  sync_mtime () {
>> > -       find . -type d -ls >/dev/null
>> > +       if test_have_prereq BUSYBOX
>> > +       then
>> > +               find . -type d -print0 | xargs -0r ls -ld >/dev/null
>> > +       else
>> > +               find . -type d -ls >/dev/null
>> > +       fi
>>
>> Given that this is only to work around the lazy mtime sync found on
>> BSDs, if we were to have any if/then/else, shouldn't we be rather
>> doing
>>
>> 	if test_have_prereq NEEDS_SYNC_MTIME_BECAUSE_WE_ARE_ON_BSD
>> 	then
>> 		find . -type d -ls >/dev/null
>> 	fi
>>
>> to make it a no-op for most everybody (including Windows)?
>
> I like that approach.

I actually think I was being half stupid --- what are we going to
tell those who want a stripped down system with busybox based on
BSD?  I think the condition for "if" is OK (as long as we have a
real prereq suitable for the approach), but the actual "let's make
sure the inodes are stat(2)ed" should avoid relying on "find -ls".

If we can assume that a typical busybox build offers find with -print0
and xargs with -0, I think the version you sent is probably the best
(with or without "do so only on BSD" I suggested) approach.

Thanks.





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux