Re: Thoughts after an install (well, partway through)
On Wed Jan 05, 2000 at 09:38:46PM -0500, Daniel Jacobowitz wrote:
>
> I also turned up a couple of cosmetic bugs in busybox cp (it claimed it
> was moving one file onto itself when the two paths were different,
I'm not sure how to reproduce this one. Any hints?
> and
> it handles copying a file to a directory in a nonstandard way)
Hmm. Ok, I see this one:
mkdir foo
mkdir bar
cp README foo
cp foo/README bar
and the last command fails.
I've just added this one to my regression test script. I just did a
major overhaul of both cp and mv, and this is an atiffact. I'll fix it
right up.
> , a bug
> in tar (it spewed unprintable characters, even though invoked as tar
> -xf, and in addition to successfully unpacking)
Hmm. I'm just not seeing this one. Any hints? Do you have the tarball
in question?
> , annoyances in tar
> (is there any reason it won't accept tar xf instead of tar -xf?
The reason is that I didn't code the tar option parser that way. I'm
open to a patch, but only if you can keep it _very_ small. Remember that
this isn't intended to be GNU tar. Bloat is bad. I want to avoid the
kind of creeping featurism that makes GNU tar be 135k.
> And no
> -z flag)
True. busybox has both gunzip and tar in it. I never bothered to
hook the two of them together. So far the Unix tradition of zcat|tar
has worked well enough to do the job. Remember that BusyBox is all
about doing the job as simply as possable. I am open to a patch
though (I like tar -xzf ;-), but only if you can keep it really
small. This is definately the sort of thing that would warrent a
BB_FEATURE_TAR_GZIP_SUPPORT type entry in busybox.def.h.
-Erik
--
Erik B. Andersen Web: http://www.xmission.com/~andersen/
email: andersee@debian.org
--This message was written using 73% post-consumer electrons--
Reply to: