[PATCH] adding two new options to 'cp'

[Mike Meyer]

In <44CE4AD0.60409 at centtech.com>, Eric Anderson <anderson at centtech.com> typed:
> On 07/31/06 10:23, Mike Meyer wrote:
> > In <44CE199C.2020500 at centtech.com>, Eric Anderson <anderson at centtech.com> typed:
> >> On 07/31/06 09:11, Mike Meyer wrote:
> >>>> I suppose I'm just missing the reason *not* to commit such a simple and 
> > n> >> useful set of options.
> >>> Feature bloat. Or, more verbosely, this doesn't add any new
> >>> functionality to the system, while adding things that we would rather
> >>> minimize.
> >> This is a really funny reason not to.  Honestly, if you believe that, 
> >> that you probably don't use cp at all, since dd can do it.
> > 
> > Yes, I believe that. Adding features does *not* necessarily improve a
> > system. If you want it added, give us *good* reasons to add it. Lack
> > of a good reason not to add a feature is *not* a good reason to add
> > the feature.
> > 
> > Personally, I'm neutral on this change, other than not wanting FreeBSD
> > to bloat any more than it already is. Given good reasons, I'd say
> > commit it. The reasons you just provided are specious.
> You don't sound neutral at all actually, but ok.

I'm as neutral as I'd be about *any* other addition. I don't have a
specific reason to dislike it. But I don't have a specific reason to
like it, either. The last time I wanted a hardlinked copy of a
directory tree was long enough ago that most (if not all) of the
alternative solutions mentioned here didn't exist yet.

> I suppose I thought 
> the reasons were obvious - to get a hardlinked copy of a directory tree, 
> one must concoct any one of a number of command lines, all using at 
> least one of which is much bigger in size than the patched cp I 
> proposed.  Here are some of the commands mentioned so far that are used 
> by people to do the exact same thing:
> 
> -r-xr-xr-x  1 root  wheel  50056 Jul 25 23:08 /usr/bin/bsdtar
> -r-xr-xr-x  1 root  wheel  52600 Jul 25 23:07 /usr/bin/cpio
> -r-xr-xr-x  1 root  wheel  36480 Jul 25 23:08 /usr/bin/find
> -r-xr-xr-x  1 root  wheel  90376 Jul 25 23:06 /bin/pax

> And here's my patched version of cp:
> -r-xr-xr-x  1 root  wheel  15460 Jul 26 14:52 /bin/cp
> 
> So yes, you bloat by 160 bytes, but you can then possibly remove your 
> need for one or more utilities that eat up at least twice the space.

So are you proposing that we remove one of those utilities? If not,
then you are bloating the system. Yeah, it's only by a little bit. But
a lot of little bits add up.

> The -a option isn't as much of a useful option, but it keeps life nice 
> and simple for those of us with only FreeBSD systems.  If the -a option 
> is an issue, then ignore it.

How does the -a option make life simpler for those of us with only
FreeBSD systems? By saving two characters typing if we want to use a
tool designed for copying files to archive them instead?

> >>> If the functionality is all that useful, then people should have
> >>> already created shell code to make this functionality easily available
> >>> via the tools that already have it. If nobody needs this functionality
> >>> often enough to have done that, is it something that we want to
> >>> enshrine in compiled code?
> >> To me, I read this as saying: "If it was useful, it would have already 
> >> been done, and since it isn't, it must not be needed by anyone."
> > 
> > How does "people would have created shell code to make this easy to
> > do" equate to "someone would have already added an option for it"? You
> > claim that the code provides "useful functionality". If it's useful,
> > then people should be using the alternatives frequently. Command lines
> > that people use frequently tend to get enshrined in shell scripts, or
> > aliases, or shell functions, or whatever. Moving such things into
> > commands is a standard path for Unix code, and has been since at least
> > v6. So, if you want to take that step, can you show that it's really
> > used frequently enough to warrant getting a dedicated option?
> People do make scripts to get around it, and they've posted their own 
> 'heres what I do' on this list in this thread.  People even use tools 
> like rsync for it too.  There's a lot of people working around it in 
> various ways, that's what gave me the reason to post it to the list.

I haven't seen any scripts. I recall lots of people pointing out
alternatives. None of these are what I would call "work
arounds". They're using the available tools to do the job they were
designed to do. Your patch means they can use a tool designed to copy
files to create links.

Which points up an obvious question: other than compatibility with
Linux, is there any reason this functionaly shouldn't be added to the
ln command instead?

> Anyway, it's apparent that those who are against the extra features post 
> louder than those who could use them, so feel free to ignore the patch 
> altogether if you wish.

That's how technical decisions get made on the internet.

	<mike

-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.