[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