Re: [PATCH] adding two new options to 'cp'

On 7/31/06, Mike Meyer <mwm-keyword-freebsdhackers2.e313df@xxxxxxxxx> wrote:

In <44CE199C.2020500@xxxxxxxxxxxx>, Eric Anderson <anderson@xxxxxxxxxxxx>
typed:
> On 07/31/06 09:11, Mike Meyer wrote:
> > In <44CE03D2.2050803@xxxxxxxxxxxx>, Eric Anderson <
anderson@xxxxxxxxxxxx> typed:
> >> The patch doesn't change any current behavior, nor should it be
noticed
> >> by anyone not looking for it. However, it is useful, and it does
make
> >> our cp work just like the GNU cp, which eases the migration path for
> >> linux->FreeBSD users.
> > Is emulating Linux behavior that good an idea? I mean, if I want
> > Linux, I can download and install a copy. The joke about "Linux is for
> > people who hate Windows; FreeBSD is for people who love Unix" is funny
> > to me *because* it seems to capture the difference between the two
> > systems so accurately. I like Unix/BSD because I feel like the
> > developers respect the user, and are willing to let the user do pretty
> > much anything they need to do, even if there's no obvious reason for
> > them to want that. I detest Windows because the developers treat the
> > the user like an idiot, and write software that does things the way
> > they think the user should want to do them - and make it impossible to
> > do things that the developers don't think users would ever need/want
> > to do. Linux seems to have more of the latter attitude than the
> > former. [And no, I don't think this patch has that attitude; I just
> > don't think that "that's how linux does it" is a valid argument:
> > freebsd isn't linux.]
> The reasoning was not simply to make it like linux, that's just a side
> effect.

That doesn't make the "to makes it more like Linux" argument a good
reason to change FreeBSD.

> >> 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.

> > 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?

<mike
--
Mike Meyer <mwm@xxxxxxxxx>
http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"


Hello,

My GNU version of "cp" has more than 18 options, the FreeBSD
version only has 9.

As I usually work with Linux machines, I'm used to "cp -a" and I have always
hated to have to look up in the FreeBSD's "cp" manual page for the right
options to get the same funtionality. I tend to think
that "-a" is option bloating because it's not really needed, but I see
"-l" as a new feature for "cp" that might be useful. I'm not a unix/linux
expert but when I have to copy something, "cp" shows up inmediately in my
mind (I almost never use "cpio" and I didn't know "pax", for example). To
sum it up, I think "cp -a" and "cp -l" are both useful, the first one
because of compatibility with the large base of Linux systems out there, and
the second one because I think it's a useful feature for the FreeBSD "cp".

This is only my personal experience, though I understand that if you want to
protect "cp" for having more than 10 options, these options shouldn't see
the sunlight :P


--
JFRH
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: [PATCH] adding two new options to cp
    ... Is emulating Linux behavior that good an idea? ... reason to change FreeBSD. ... already created shell code to make this functionality easily available ... How does "people would have created shell code to make this easy to ...
    (freebsd-hackers)
  • Re: [PATCH] adding two new options to cp
    ... Is emulating Linux behavior that good an idea? ... FreeBSD is for people who love Unix" is funny ... reason to change FreeBSD. ... already created shell code to make this functionality easily available ...
    (freebsd-hackers)
  • Re: [PATCH] adding two new options to cp
    ... Linux, I can download and install a copy. ... I detest Windows because the developers treat the ... This is a really funny reason not to. ... already created shell code to make this functionality easily available ...
    (freebsd-hackers)
  • Re: Nice processes on Unix
    ... | rpw3@xxxxxxxx (Rob Warnock) writes: ... but it was rejected by the Linux kernel core maintainers: ... Ah, well perhaps there's a good reason to do it differently, but I sure ... I'd actually be interested in why they consider it a feature (beyond ...
    (comp.lang.lisp)
  • Re: [WISHLIST] IBM HD Shock detection in Linux
    ... >While I have seen this feature in XP, It would be nice to have such ... >functionality in Linux. ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)