[clbuild-devel] [PATCH] fix trash to trash project's registered system
Daniel White
daniel at whitehouse.id.au
Mon Jan 12 18:49:59 UTC 2009
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
--
Daniel White
More information about the clbuild-devel
mailing list