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 <coreut...@tlinx.org> 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
