bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?


From: Erik Auerswald
Subject: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?
Date: Wed, 18 Jul 2018 17:27:54 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Hi,

On Wed, Jul 18, 2018 at 04:36:44AM -0600, Mike Hodson wrote:
> On Wed, Jul 18, 2018 at 4:24 AM L A Walsh <address@hidden> wrote:
> 
> > In the case of creating a link to a directory there is
> > no choice in creating a "working solution".  If you want a link
> > there, it HAS to be a symlink.  That the user would bother to
> > use the 'ln' (link) command in the first place is a sufficiently
> > convincing "argument" that they really DID want a link there.

This sounds reasonalble to me: a link was requested, it might not matter
which kind, and only one kind of link can be created. Thus 'ln' could
try to do the right thing and create a (symbolic) link.

> > That they didn't explicitly specify the type should additionally
> > be taken that they didn't care enough to specify the type -- only
> > that the link be created.
> >
> >         I hope that clarifies that I'm not attempting to always
> > find some "automatic action", but saw that in this case, it
> > wouldn't be hard to figure out what was wanted and that doing
> > so wouldn't be hard to undo if it was not.
> 
> I wager that some people *aren't* aware that you cannot hardlink a
> directory, and instead of writing hundreds of NEW bug reports "linking
> broken" "why can't I link a directory" leaving 'ln' as it has been since
> the dawn of time is the better option.

Printing a helpful warning message that a symbolic link has been created
instead of a hard link, because a hard link cannot be created (perhaps
less verbose) would help at least a little bit. A new option that is
needed to enable that behavior would prevent the confused users, until
distributions start to add it to the default aliases.

> You don't think this will happen? I assure you it will.
> 
> Look at the YEARS of new users being introduced, as their distributions
> finally 'stabilize' newer coreutils, to the new "Quoted Filenames" in 'ls'
> . So many people have been totally confused, angry, and rather taken aback
> that such an old utility did something different.

I immediatly searched for the respective option and changed my aliases
to not quote 'ls' output. ;-)

I did not like that the default output of 'ls' was changed, but at least
I can disable this anti-feature.

> Let us all learn from history, on this same maillist, of when and when not
> to change the default workings of a 40 year old tool.

This sounds reasonable to me, but others have different view, see your
'ls' example. ;-)

Anyway, IMHO Linda's arguments for the specific change requested
have merit. I personally would prefer an option to enable that new
functionality instead of making it the default, if someone were to
implement said functionality.

Thanks,
Erik
-- 
Design your product to please the users.
                        -- Paul Graham





reply via email to

[Prev in Thread] Current Thread [Next in Thread]