bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?
Original Message Subject: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise? Resent-Date:Thu, 12 Jul 2018 07:17:02 + Resent-From:L A Walsh Resent-CC: bug-coreutils@gnu.org Date: Thu, 12 Jul 2018 00:16:50 -0700 From: L A Walsh To: Paul Eggert CC: 32...@debbugs.gnu.org References: <5b465a80.8030...@tlinx.org> Paul Eggert wrote: L A Walsh wrote: Like I'll want an "RCS" dir to point to 1 RCS tree -- so I try to use ln . ln, of course seems to think I want the impossible -- and says you can't have hard-linked directories. You can use "ln -s" instead of plain "ln". If that's not what you want, then I'm afraid I don't understand what you want, exactly. --- Yes, I can retype the command after getting an error telling me that regular links to directories are invalid. I'm asking why does 'ln' bother to tell the user that they are wrong and do nothing useful? Why not just go ahead and create a symlink -- since it is likely that is what is wanted and is the only type of link that works? If needed, it could even tell the user that hard links don't work so it created a symlink instead. That way, in the mostly likely case (user wanted a symlink and left off the '-l'), they user would have the symlink created and would not have to re-enter the command.
bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?
On 07/12/2018 02:16 AM, L A Walsh wrote: > > I'm asking why does 'ln' bother to tell the user that they are > wrong and do nothing useful? Why not just go ahead and create a symlink The user didn't ask for a symlink, and it sounds unwise for ln to be second-guessing that. Sometimes, reporting an error and exiting is a better thing to do.
bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?
Paul Eggert wrote: On 07/12/2018 02:16 AM, L A Walsh wrote: I'm asking why does 'ln' bother to tell the user that they are wrong and do nothing useful? Why not just go ahead and create a symlink The user didn't ask for a symlink, and it sounds unwise for ln to be second-guessing that. Sometimes, reporting an error and exiting is a better thing to do. Often in deciding whether it is good or not good to make a reasonable attempt at completion factors are evaluated -- such as consequences for trying or not trying and whether or not the user is running interactively or not, and the likelihood of the possible solution being what they wanted. In this case, it seems they wanted some type of link created or they would not have used the link command. If they link was created as a symlink because hardlinks are not available, then they have solved their problem. If the link isn't created because hardlinks are not supported (even though they did not specify the link type (-P|-s) then ln would fail and they would need to redo the command. If they didn't want the link created, it would be unlikely they'd be using the 'ln' (link) command. Only in the case that they wanted a link -- but only a hard link, would they need to remove it -- 'ln' would have failed to do the right thing. I posit that they wouldn't need to create a hard link in a workable solution -- they will need to find some other way to create a solution ( perhaps mounting the file). However if they are not root, they won't be able to use that solution. I would suggest that it would be unlikely that they would need a hard link there and they might change their mind and decide that a symlink is fine. In all of the cases, given the probabilities, it would be most helpful and most useful to create *some link*, as that is what they asked for by using the 'ln' command. Non of the outcomes require any more correction than undoing the incorrect action, but it is likely they would agree that a symbolic link was the right choice given that physical links are not available. You said "The user didn't ask for a symlink". Neither did they hask for a hardlink by using "-P'. They wanted a link. Creating the only possible link would seem to be the best option available. Indeed -- my focus was on creating a link -- that it had to be a symlink was a bit of minutia that I didn't care much about. If I had stated that I wanted a physical link by specifying "-P" -- then I would not suggest auto-creating the link -- only in the case where a link was asked for without specification of type. Frequently is is more user friendly to do something than do nothing (assuming doing something doesn't cause damage -- which is the case here. -L.
bug#32099: Testing with other options (Was: Benchmarks: Hashing ~70% faster )
Hey Berny,
I like your suggestion of testing whether hashing
interferes with any other option.
I was glad to see the POSIX standard doesn't
explicitly require sorted input or output.
If someone writes the patch, I should be able to
test it, at least on up to 1 GB of input.
So,
Kingsley
On 07/12/2018 08:43, Bernhard Voelker wrote:
> On 07/10/2018 08:21 PM, Assaf Gordon wrote:
> > I would suggest several improvements to the measurements, to ensure
> > relevant information is conveyed:
> >
> > 1.
> > [...]
>
> great summary. With the risk of mentioning already said aspects:
>
> 7. Consider all the existing options, i.e. processing modes, of 'uniq' as
> well.
> This means, it has to be considered (upfront!) whether introducing an
> alternate
> way to do things - in this case hashing - only serves for the trivial case,
> or whether this would slow down or even contradict the processing with other
> options, currently:
>
> -c, --count prefix lines by the number of occurrences
> -d, --repeatedonly print duplicate lines, one for each group
> -Dprint all duplicate lines
> --all-repeated[=METHOD] like -D, but allow separating groups
> with an empty line;
> METHOD={none(default),prepend,separate}
> -f, --skip-fields=N avoid comparing the first N fields
> --group[=METHOD] show all items, separating groups with an empty line;
> METHOD={separate(default),prepend,append,both}
> -i, --ignore-case ignore differences in case when comparing
> -s, --skip-chars=Navoid comparing the first N characters
> -u, --unique only print unique lines
> -z, --zero-terminated line delimiter is NUL, not newline
> -w, --check-chars=N compare no more than N characters in lines
>
> Without deeper thinking about it, especially the combinations with
> the --group, --repeated and --unique options might be problematic.
>
> 8. Standards. POSIX says:
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/uniq.html
>
> The uniq utility shall read an input file comparing adjacent lines,
> and write one copy of each input line on the output. The second and
> succeeding copies of repeated adjacent input lines shall not be written.
>
> This makes an assumption both on the input and output.
>
> Regarding the input, this means that the processing just has to remember
> the previous line in order to decide whether to print/discard it in the
> output. Therefore, arbitrary input size is fine.
> Hashing most probably will have issues with arbitrary input size;
> I do not talk about 1GB files, but _much_ larger files (yes, we
> are in 2018 where 1GB is like nothing).
>
> Regarding the output, this means that the output is implicitly in
> sort order as well. Like the input, uniq can discard the already
> written data from memory because it is sure that uniq doesn't need
> to consider it anymore.
>
>
> Thus said, a successful optimization idea does not only have to show
> that it is faster or needs less resources in _some_ cases, but also
> must prove that it does not tear down many cases including extreme
> ones. The current implementation might be as-is for a good reason.
> If it turns out that the optimization idea screws up a single
> of the above use cases, then the dilemma is whether 2 implementations
> are warranted to be kept (maintenance!), and whether it is possible
> to detect the extreme cases early enough to switch from the default
> to the other processing strategy.
>
> https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good
> or D. Knuth:
> "premature optimization is the root of all evil
>(or at least most of it) in programming"
>
> As Assaf said, a patch with a proof of concept would be helpful ... even
> if it's just helpful to proof that the current implementation is fine.
>
> Have a nice day,
> Berny
--
Time is the fire in which we all burn.
