[clbuild-devel] [PATCH] fix trash to trash project's registered system

Ben Hyde bhyde at pobox.com
Tue Jan 13 02:29:57 UTC 2009


On Jan 12, 2009, at 1:49 PM, Daniel White wrote:
> On Mon, 12 Jan 2009 10:15:18 -0500
> Ben Hyde <bhyde at pobox.com> wrote:
>
>> On Jan 12, 2009, at 9:42 AM, Daniel White wrote:
>>> On Sat, 10 Jan 2009 16:03:26 -0500
>>> Ben Hyde <bhyde at pobox.com> wrote:
>>>
>>>> The following diff changes the trash command.  It currently
>>>> neglects to
>>>> de-register the project's system files.  This removes those  
>>>> symbolic
>>>> links.
>>>>
>>>> An addition minor change to the working of the count_systems
>>>> scratches
>>>> my itch.  I install project foo, and it says "60 system definition
>>>> files registered"
>>>> making me think project foo had 60 systems.
>>>>
>>>>
>>>> --- old-clbuild/clbuild	2009-01-10 15:58:17.000000000 -0500
>>>> +++ new-clbuild/clbuild	2009-01-10 15:58:17.000000000 -0500
>>>> @@ -449,7 +449,7 @@
>>>>
>>>> count_systems() {
>>>> 	n_asd=`ls -1 "$system_dir"/*.asd | wc -l`
>>>> -	echo "$n_asd system definition files registered"
>>>> +	echo "$n_asd total system definition files now registered"
>>>> }
>>>>
>>>>
>>>> blank_line
>>>> = 
>>>> "                                                                  "
>>>> @@ -1404,6 +1404,8 @@
>>>>     else
>>>> 	mkdir $trash
>>>>     fi
>>>> +    echo "deregistering system files of $1"
>>>> +    ls -l $BASE/systems/* | grep "$1" | awk '{print $9}' | xargs  
>>>> rm
>>>>     echo moving "$1" to "$trash/$basename"
>>>>     mv "$1" "$trash"
>>>> }
>>>
>>> This only removes .asd files that happen to contain the project's
>>> name.
>>
>> By the time we get to the ugly pipeline ending in rm, $1 has is bound
>> to the
>> a directory path, not the project name, by example /Users/bhyde/p/
>> clbuild/source/zs3
>> rather than zs3,  The caller of the bash function trash did that.
>> Which means the grep
>> is selecting all the links running back to that branch in the
>> filesystem tree.
>>
>>     $ ./clbuild trash zs3
>>    deregistering system files of /Users/bhyde/p/clbuild/source/zs3
>>    moving /Users/bhyde/p/clbuild/source/zs3 to /Users/bhyde/p/ 
>> clbuild/
>> trash/2009-01-12/zs3
>>    $
>
> Is it a good idea to rely on this accidental behaviour?  I imagine
> it'll be quite easy for this to end up broken down the road.
>
> Not that my solution is all that perfect.  It'll blow away all broken
> symlinks instead of just the project's ones.
>
> A better idea might be break out the .asd finding code from the
> register_ methods.  Biggest problem with that is that bash doesn't  
> have
> real functions.
>
>>
>>> I've the following patch in my repository at http://darcs.whitehouse.id.au/daniel/clbuild/
>>>
>>> * Clean broken links after a trash operation
>>
>> I'm not darc's fluent, can I see that patch without checking out the
>> entire rep?
>>
>
> Sure.  It's in my darcsweb for clbuild.
>
> http://darcs.whitehouse.id.au/cgi-bin/darcsweb.cgi?r=clbuild;a=summary

That's pretty, i likes.

> -- 
> Daniel White





More information about the clbuild-devel mailing list