bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?
Michael Stone wrote: On Tue, Jul 17, 2018 at 02:15:14PM -0700, L A Walsh wrote: I can't think of a similar failure mode that I'd want a hard link created Yes, you've made that clear --- I think you are making it clear that you didn't understand what I said and why I said it. I said that I could not think of a similar situation that would involve creating a hard link by default, as I would not be less than 50% certain it was what was wanted. That is directly the opposite of my initial proposal to handle directories differently and default to the only option that works rather than assuming they got it wrong and issuing an error message and not doing anything useful for them. You seem to think my positions on the two types of links would be the same when they are not. In almost any circumstance where you could create a hardlink, you could also create a symlink -- I.e. if you *wanted* to try to do what the user wanted, there is no way to know -- since there are two possibilities. 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. 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.
bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?
On Wed, Jul 18, 2018 at 4:24 AM L A Walsh 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. > 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. 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. Even when it could be argued(and I said exactly this when I saw the new feature) "Hey, thats pretty cool, i can cut and paste with a mouse now and it won't require manual editing later" and many people have made this argument; many other people have made the argument of "if its not in an interactive terminal, NOTHING CHANGED" because so many thought that "well crap I can't rely on any scripts to work anymore" ... 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. Perhaps, there are better things to do with the time than argue a point that will cause NUMEROUS people grief in the future. Mike
bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?
On Wed, Jul 18, 2018 at 03:23:59AM -0700, L A Walsh 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. 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. Or, they expect the traditional behavior, which is that requesting a link which can't be created will result in failure. You seem to completely disregard the possibility that any script written in 40 years might use that behavior in its logic, while I find it extremely unlikely that scripts would be written in the hope that someday the behavior might change and things work differently because they make more sense that way.
bug#32198: tail -f -F unexpected behavior
This is for tail v8.28 encountered on Ubuntu 18.04. I was doing some experimentation with nano v2.9.3 and tail, watching the output of tail after saving in nano and encountered some strange behavior. I had two terminals open side by side; one with nano and one with tail. I opened a file called test.txt in nano and saved with ^w in the first terminal. I went to the second terminal and ran tail -f test.txt to watch the file. I went back to the nano terminal and returned twice and saved. The tail terminal reports this change properly. With the file still open in nano, I write any number of characters and save. The tail terminal reports this change But skips the first character. I also tested this with -F. This may not be an issue because it only happens when using the write(ctrl-o, ctrl-s) in nano and not closing the file. I have reproduced this on two machines.
bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?
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 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
bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?
Mike Hodson wrote:
I wager that some people *aren't* aware that you cannot hardlink a directory
If they don't know why, they probably don't know the difference
between hard and soft links to files -- and will *then* be annoyed that
linking doesn't work. *THEN*, they will your "hundreds of NEW
bug reports 'linking broken' 'why can't I link a directory' -- all because
ln creates no link nor gives an explanation.
My suggestion does both -- create a link that they obviously wanted,
of the only type that works (as no link type was specified(**) ), AND warn
that "A symlink was created, as hard-linking to a directory is
not supported".
(**) - if they go so far as to use '-P'/'--physical', then I would suggest
NOT creating the symlink.
That addresses the issue of people filing 100's of new bug reports
as it tells them why -- it's not supported.
The message "hard link not allowed for directory" is also inaccurate.
It says hard linking is not "allowed" (permitted), suggesting it could
be. Saying 'not supported' says nothing about permissions.
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.
---
Because someone chose to *add* quotes by default when there
was already an option to add them. They changed the default on a
personal whim. It's not the case that without quotes nothing will
work. It was an *arbitrary* choice for change among several choices
that were already present.
Even when it could be argued(and I said exactly this when I saw the new
feature) "Hey, thats pretty cool, i can cut and paste with a mouse now
and it won't require manual editing later"
---
Sigh...untrue. Maybe someone new who hadn't developed a workflow
to handle such input would like it. Anyone who had been around "a while"
would have developed a workaround, *if* it bothered them. That workflow
broke with the new change:
/bin/ls -1
# that I Copy+Paste as such:
readarray -t files
^D
## now my filenames w/spaces in them or whatever, are in 'files'
# now try to use the files like 'ls "${x[@]}"'
ls "${x[@]}"
ls: cannot access "'Anime/D. Gray-man'": No such file or directory
ls: cannot access ' Anime/DGreyMan-「ディー・グレイマン」オリジナル・サウンドトラック ２': No such file
or directory
ls: cannot access "'Anime/Daphne In The Brilliant Blue'": No such file or
directory
ls: cannot access "'Anime/Darling in the FranXX'": No such file or directory
ls: cannot access "'Anime/Devil Survivor 2 - The Animation OST'": No such file
or directory
ls: cannot access "'Anime/Dragonaut - The Resonance OST'": No such file or
directory
Total SNAFU.
many other people have made the argument of "if its not
in an interactive terminal, NOTHING CHANGED" because so many thought
that "well crap I can't rely on any scripts to work anymore" \
---
If I never ran interactively, I wouldn't have noticed (nor
would I already have a workaround).
So it was 1) arbitrary, 2) already had an option to do
it (could have been done w/aliases) and
3) it broke existing workflows ==>> Bad Change.
The proposed change, however fixes an error condition
as well as provides the workaround, automatically (with an
optional explanation). The two cases are VERY different.
-l
bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?
Michael Stone wrote: Or, they expect the traditional behavior, which is that requesting a link which can't be created will result in failure. You seem to completely disregard the possibility that any script written in 40 years might use that behavior in its logic, while I find it extremely unlikely that scripts would be written in the hope that someday the behavior might change and things work differently because they make more sense that way. --- Like I saidputting change into the kernel to do the same -- seems to fly by with little or no comment... Putting it in an app where it is visible...and everyone complains. Interesting. Apps that rely on getting errors? You don't regard that as a bit of an unreliable design? But easily solved -- go the way of 'ls' and only create the symlinks if the process is interactive. Problem solved
