coreutils
[Top][All Lists]
Advanced

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

Re: Does -s apply to -m in sort?


From: Peng Yu
Subject: Re: Does -s apply to -m in sort?
Date: Mon, 11 May 2020 19:42:39 -0500

Are you the author of -m? If not, maybe the author of -m should knows how
it works with -s? If not, maybe this should be documented anyway?

On Mon, May 11, 2020 at 5:01 PM Eric Blake <address@hidden> wrote:

> On 5/11/20 4:18 PM, Peng Yu wrote:
> > I used real files (already sorted) to test whether having -s or not
> > affect -m. But I have not made minimal example input files so that is
> > why I am not sure about my conclusion.
> >
> > But the command to try is basically `sort -m -k sort_fields files...`
> > or `sort -s -m -k sort_fields files..`.
>
> That's closer - it shows a pseudo-command line you attempted.  But it
> still does not lend itself to reproducibility, because we don't know
> what 'sort_fields' you used, nor what 'files..' contain.
>
> You also didn't state whether you tried the --debug option, to see if
> the presence or absence of -s showed enough debugging crumbs to prove
> that you at least tried to analyze the problem yourself.  Nor did you
> mention whether you read the source code (it _is_ open source, after
> all, so instead of asking someone else to do your homework, _you_ can
> find the answer).
>
> >
> > I assume to authors who made -m and -s. My question should be clear?
>
> Unfortunately, your assumption is wrong.  A clear question is one that
> includes actual examples, and not one that forces someone to reproduce
> the work that you could have already provided them.  Put it this way:
> suppose it took you 5 minutes to come up with a test case, and that
> there are 100 list readers interested in your problem, each of whom then
> take another 5 minutes to reproduce the setup from your vague
> description.  Then you have cost 505 minutes of collective time; and
> your original work plus the work of each reader results in a very low
> signal-to-noise ratio (5/505 is less than 1% new discoveries, and more
> than 99% rehash).  But if it takes you an additional 5 minutes to polish
> your query into an email that can then be copy-pasted into a terminal so
> that each reader can reproduce the problem in 5 seconds, then your
> initial 10 minutes of effort (which is indeed twice the work on your
> part) plus 500 seconds of list readers' time results in a much better
> ratio of useful new work (5/18.3 is > 27%).  Although it costs you more,
> your efforts to make everyone else's life easier is magnified by the
> number of readers benefitted by your extra efforts.  (And that's why I'm
> spending so long in writing my reply - to try to teach you that your
> historical style of questioning leaves a lot to be desired, as well as a
> possibly-futile attempt on my part to get you to recognize that the more
> effort YOU put into a good bug report, the less likely you are to be
> habitually ignored as someone who merely wastes time).
>
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.           +1-919-301-3226
> Virtualization:  qemu.org | libvirt.org
>
>
> --
Regards,
Peng


reply via email to

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