On Sat, 29 Apr 2023 12:01:14 +0100, Chris Elvidge wrote:
> On 29/04/2023 11:01, Martin Τrautmann wrote:
>> On Sun, 23 Apr 2023 09:43:06 -0400, David W. Hodgins wrote:
>>> On Sun, 23 Apr 2023 07:28:22 -0400, Martin Τrautmann <t-usenet@gmx.net> wrote:
>>>> That was my problem - I expected that a pipe through several sorts would
>>>> keep the order. I don't know why it doesn't.
>>>
>>> It may be easier to understand if you use a temporary files instead of pipes.
>>>
>>> Sorting the input file by column 4, numerical creating a first temporary file.
>>> Sort the first temporary file by column 2 creating a second temporary file.
>>> Sort the second temporary file by column 3 creating the output.
>>>
>>> The last sort doesn't know that the prior two sorts have been done. It just
>>> looks at the file it's giving and sorts it by column 3.
>>>
>>> Using a pipe just takes the output of the first and second sort and uses it
>>> directly as input for the next sort. All the pipe does is eliminate the
>>> need for a temporary file.
>>
>> But if I sort by one column only, then through the pipe by another
>> column only, the second sort SHOULD respect the previous sort.
>> Unfortunately, I feel it doesn't.
>
> Of course it doesn't. How does the second sort know that the first sort
> even happened?

It should sort on the given column only, but keep anything else as it
was. I guess that's my misconception - however, sort seems to be allowed
to resort anything else however it likes. That's the difference e.g. to
an excel spreadsheet, which does keep the former sort.

On 29/04/2023 13:12, Martin Τrautmann wrote:
> On Sat, 29 Apr 2023 12:01:14 +0100, Chris Elvidge wrote:
>> On 29/04/2023 11:01, Martin Τrautmann wrote:
>>> On Sun, 23 Apr 2023 09:43:06 -0400, David W. Hodgins wrote:
>>>> On Sun, 23 Apr 2023 07:28:22 -0400, Martin Τrautmann <t-usenet@gmx.net> wrote:
>>>>> That was my problem - I expected that a pipe through several sorts would
>>>>> keep the order. I don't know why it doesn't.
>>>>
>>>> It may be easier to understand if you use a temporary files instead of pipes.
>>>>
>>>> Sorting the input file by column 4, numerical creating a first temporary file.
>>>> Sort the first temporary file by column 2 creating a second temporary file.
>>>> Sort the second temporary file by column 3 creating the output.
>>>>
>>>> The last sort doesn't know that the prior two sorts have been done. It just
>>>> looks at the file it's giving and sorts it by column 3.
>>>>
>>>> Using a pipe just takes the output of the first and second sort and uses it
>>>> directly as input for the next sort. All the pipe does is eliminate the
>>>> need for a temporary file.
>>>
>>> But if I sort by one column only, then through the pipe by another
>>> column only, the second sort SHOULD respect the previous sort.
>>> Unfortunately, I feel it doesn't.
>>
>> Of course it doesn't. How does the second sort know that the first sort
>> even happened?
>
> It should sort on the given column only, but keep anything else as it
> was. I guess that's my misconception - however, sort seems to be allowed
> to resort anything else however it likes. That's the difference e.g. to
> an excel spreadsheet, which does keep the former sort.

You want a stable sort, then. Check if you have a '-s' option.

On Sat, 29 Apr 2023 13:38:58 +0100, Richard Harnden wrote:
>> It should sort on the given column only, but keep anything else as it
>> was. I guess that's my misconception - however, sort seems to be allowed
>> to resort anything else however it likes. That's the difference e.g. to
>> an excel spreadsheet, which does keep the former sort.
>
> You want a stable sort, then. Check if you have a '-s' option.

wow, cool

-s, --stable
stabilize sort by disabling last-resort comparison

I do not understand what that means. But it worked

1;2
0;2
2;2
1;1
0;1
2;1
1;0
0;0
2;0
....
0;2
0;1
0;0
1;2
1;1
1;0
2;2
2;1
2;0

On Sat, 29 Apr 2023 20:23:18 +0200, Martin Τrautmann wrote:

> On Sat, 29 Apr 2023 13:38:58 +0100, Richard Harnden wrote:
>>> It should sort on the given column only, but keep anything else as it
>>> was. I guess that's my misconception - however, sort seems to be allowed
>>> to resort anything else however it likes. That's the difference e.g. to
>>> an excel spreadsheet, which does keep the former sort.
>>
>> You want a stable sort, then. Check if you have a '-s' option.
>
> wow, cool
>
> -s, --stable
> stabilize sort by disabling last-resort comparison
>
> I do not understand what that means. But it worked

From the option summary, the meaning is less than obvious. However
some versions of the manpage include an explanation:

"A pair of lines is compared as follows: if any key fields have
been specified, 'sort' compares each pair of fields, in the
order specified on the command line, according to the associated
ordering options, until a difference is found or no fields are
left.
...
Finally, as a last resort when all keys compare equal (or if no
ordering options were specified at all), 'sort' compares the
entire lines. ... The '-s' (stable) option disables this
last-resort comparison so that lines in which all fields
compare equal are left in their original relative order.
..."

In the case of a file that has already been sorted, either on a
key occurring before the key-to-be-sorted, or on a key that follows
(but is not adjacent to) the key-to-be sorted, this "last resort
comparison" may result in a record that sorts out-of-sequence
with respect to the prior sort order. To ensure that the order
from a prior sort is not lost, you have to disable this "last
resort comparison".

[snip]

HTH
--
Lew Pitcher
"In Skills We Trust"

On Sat, 29 Apr 2023 14:23:18 -0400, Martin Τrautmann <t-usenet@gmx.net> wrote:

> On Sat, 29 Apr 2023 13:38:58 +0100, Richard Harnden wrote:
>>> It should sort on the given column only, but keep anything else as it
>>> was. I guess that's my misconception - however, sort seems to be allowed
>>> to resort anything else however it likes. That's the difference e.g. to
>>> an excel spreadsheet, which does keep the former sort.
>>
>> You want a stable sort, then. Check if you have a '-s' option.
>
> wow, cool
>
> -s, --stable
> stabilize sort by disabling last-resort comparison
>
> I do not understand what that means. But it worked

See https://unix.stackexchange.com/questions/64102/why-is-sort-changing-the-order-of-lines-with-identical-sort-keys

Regards, Dave Hodgins

On Sat, 29 Apr 2023 20:33:24 -0000 (UTC), Lew Pitcher wrote:
> From the option summary, the meaning is less than obvious. However
> some versions of the manpage include an explanation:
>
> "A pair of lines is compared as follows: if any key fields have
> been specified, 'sort' compares each pair of fields, in the
> order specified on the command line, according to the associated
> ordering options, until a difference is found or no fields are
> left.
> ...

> Finally, as a last resort when all keys compare equal (or if no
> ordering options were specified at all), 'sort' compares the
> entire lines. ...

That is unexpected, but does explain why it behaves that way.

> In the case of a file that has already been sorted, either on a
> key occurring before the key-to-be-sorted, or on a key that follows
> (but is not adjacent to) the key-to-be sorted, this "last resort
> comparison" may result in a record that sorts out-of-sequence
> with respect to the prior sort order. To ensure that the order
> from a prior sort is not lost, you have to disable this "last
> resort comparison".

Again a lesson learned

Martin Τrautmann <t-usenet@gmx.net>:
> On Sat, 29 Apr 2023 12:05:17 +0200, Martin Τrautmann wrote:
>> On Sun, 23 Apr 2023 22:30:24 +0200, Helmut Waitzmann wrote:
>>> Helmut Waitzmann <nn.throttle@xoxy.net>:
>>>> Look at these sample lines:
>>>>
>>>>
>>>> 1;0
>>>> 1;1
>>>> 1;2
>>>> 0;0
>>>> 0;1
>>>> 0;2
>>>> 2;0
>>>> 2;1
>>>> 2;2
>>>>
>>>>
>>>> To have this sequence of lines sorted in such a way that the
>>>> first field is sorted in ascending numeric order while the
>>>> second is sorted in descending numeric order,
>>>
>>> I'm sorry, that is a quite misleading description.  What I wanted
>>> to say is that the sequence of lines should be sorted to look
>>> like
>>>
>>> 0;2
>>> 0;1
>>> 0;0
>>> 1;2
>>> 1;1
>>> 1;0
>>> 2;2
>>> 2;1
>>> 2;0
>>>
>>> and to achieve this…
>>>
>>>
>>>> one could specify the two sort criteria at once:
>>>>
>>>>
>>>> sort -t ';' -k 1nb,1 -k 2nr,2
>>
>> Would you achieve this via a pipe as well?
>>
>
> When I sort by column 2 first and only, I end up with
>
> 0;2
> 1;2
> 2;2
> 0;1
> 1;1
> 2;1
> 0;0
> 1;0
> 2;0
>
> Why that? I would expect
>
> 1;2
> 0;2
> 2;2
> 1;1
> 0;1
> 2;1
> 1;0
> 0;0
> 2;0
>

[Sorted by using the

sort -t ';' -k 2nr,2

command]

> So why does it resort by first column as well?
>

Because that is the way "sort" is supposed to work.  The POSIX
standard, especially the last paragraph in the "OPTIONS" section
(<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sort.html#tag_20_119_04>)
says:  "Except when the -u option is specified, lines that
otherwise compare equal shall be ordered as if none of the
options -d, -f, -i, -n, or -k were present (but with -r still in
effect, if it was specified) and with all bytes in the lines
significant to the comparison.  The order in which lines that
still compare equal are written is unspecified."

In your case, the lines "1;2" and "0;2" for example compare equal
when compared according to the "-k 2nr,2" key specification. 
Because of that equality, these two equal comparing lines are
ordered as a last resort, as if by the

sort

command line, and that of course will sort "0;2" before "1;2".

With GNU sort, you may specify the "--stable" option (which
unfortunately is not part of the POSIX standard) to suppress that
last resort ordering.

> Since it does that, both a pipe and a second sort from a
> temporary file still fail, since they also ignore the temporary
> sort of the other column.

Yes, "sort" without the GNU "sort" "--stable" option will always
do a total ordering, ignoring and destroying any order that has
been done to its input before.  That's what we've been discussing
the whole thread and that's what makes the GNU "sort" "--stable"
option a nice thing to have.

Martin Τrautmann <t-usenet@gmx.net>:

> So the sort via a file actually should work the same as via the
> pipe?

Yes.  At least the result will be the same.  When using a pipe,
the first sort must either use its virtual memory if the data fit
into it else use a temporary file.

Helmut Waitzmann <nn.throttle@xoxy.net> writes:

Sorry, piggybacking...

> Yes, "sort" without the GNU "sort" "--stable" option will always do a
> total ordering, ignoring and destroying any order that has been done to
> its input before.  That's what we've been discussing the whole thread and
> that's what makes the GNU "sort" "--stable" option a nice thing to
> have.

There's an old trick that was common back in the day of adding a line
number (or similar) and then removing it. You could then either
explicitly sort on that number or make sure that the number has leading
zeros so the default sort restores the original order:

nl -n rz data | sort -t ';' -k 2nr,2 | cut -f2-

--
Ben.

On Mon, 01 May 2023 13:19:24 +0200, Helmut Waitzmann wrote:
>> So why does it resort by first column as well?
>>
>
> Because that is the way "sort" is supposed to work. 

How should I know that this is supposed that way? If I tell "sort" to
sort by a certain column only, why would I have to expect that it will
sort by something else as well?

>> Since it does that, both a pipe and a second sort from a
>> temporary file still fail, since they also ignore the temporary
>> sort of the other column.
>
> Yes, "sort" without the GNU "sort" "--stable" option will always
> do a total ordering, ignoring and destroying any order that has
> been done to its input before.  That's what we've been discussing
> the whole thread and that's what makes the GNU "sort" "--stable"
> option a nice thing to have.

Fortunately, someone else pointet out the stable and last resort options
to me. Thanks for that.

On Mon, 01 May 2023 20:27:57 +0200, Martin Τrautmann wrote:

> On Mon, 01 May 2023 13:19:24 +0200, Helmut Waitzmann wrote:
>>> So why does it resort by first column as well?
>>>
>>
>> Because that is the way "sort" is supposed to work. 
>
> How should I know that this is supposed that way? If I tell "sort" to
> sort by a certain column only, why would I have to expect that it will
> sort by something else as well?

As Helmut said, "because that is the way 'sort' is supposed to work".
The Open Group defines the interface and results for each of the common
'Unix' utilities, "sort[1]" included, and their definition of sort says
that
"When there are multiple key fields, later keys shall be compared
only after all earlier keys compare equal. ... [L]ines that otherwise
compare equal shall be ordered as if none of the options -d, -f, -i,
-n, or -k were present ... and with all bytes in the lines
significant to the comparison."

The "Rationale" section /does/ seem to give implementations some leeway:
"Implementations are encouraged to perform the recommended further
byte-by-byte comparison of lines that collate equally, even though
this may affect efficiency."
The key phrase here is "are encouraged", implying that this behaviour,
while specified, is not absolutely required.

[1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sort.html

HTH
--
Lew Pitcher
"In Skills We Trust"

On 2023-05-01, Martin Τrautmann <t-usenet@gmx.net> wrote:
> On Mon, 01 May 2023 13:19:24 +0200, Helmut Waitzmann wrote:
>>> So why does it resort by first column as well?
>>>
>>
>> Because that is the way "sort" is supposed to work. 
>
> How should I know that this is supposed that way? If I tell "sort" to
> sort by a certain column only, why would I have to expect that it will
> sort by something else as well?

Sorting, in computer science, may be stable or unstable. If you've
not read the documentation of a sorting system thoroughly,
you have no basis for expecting it to be one way or the other.

When you expect stable sort, you're still expecting "sorting by
something else".

Under stable sort, all records are imagined to be put into
correspondence with the natural numbers, in their original sorted order.
When two records are considered equal by the sorting comparison
function, they are in fact not considered equal but further
compared by their original order number: the record with the lower
number is considered lesser.

Some sorting algorithms achieve that behavior implicitly, by never
exchanging the relative position of items that are equal by the sorting
comparison function. Algorithms which work by comparing elements
pairwise and swapping them into order will be like this: merge sort,
insertion sort, Shell sort.

Some sorting algorithms, like quicksort, will wreck the original order
for equal keys. Quicksort has a partitioning step whereby it chooses
some middle key value, and then separates records into two groups: those
higher and those lower.

If all you know is that some program sorts, you have no idea
which kind of algorithm is using.

Ben Bacarisse <ben.usenet@bsb.me.uk>:
> Helmut Waitzmann <nn.throttle@xoxy.net> writes:
>
>> Yes, "sort" without the GNU "sort" "--stable" option will
>> always do a total ordering, ignoring and destroying any order
>> that has been done to its input before.  That's what we've been
>> discussing the whole thread and that's what makes the GNU
>> "sort" "--stable" option a nice thing to have.
>
> There's an old trick that was common back in the day of adding a
> line number (or similar) and then removing it. You could then
> either explicitly sort on that number or make sure that the
> number has leading zeros so the default sort restores the
> original order:
>
> nl -n rz data | sort -t ';' -k 2nr,2 | cut -f2-
>

I'm stunned.  Thank you for presenting this solution!  And thank
you, Martin, for initiating this interesting topic!

I prefer

grep -F -n -- ''

over

nl -n rz

though, because it doesn't get confused by header, body, and
footer lines (see the "nl(1)" manual):

# Sort according to the second numerical field, descending:
#
sort -t ';' -k 2nr,2 |

# To each line, prepend an additional numeric field, ascending,
# separated by a ";", in order to "save" the sorted result for
# later retrieval thus making the second sort below a "stable"
# one:
#
grep -F -n -- '' | sed -e 's/:/;/' |

# Sort according to the original first - now second - numerical
# field, ascending, and the "saved" sort in the first numerical
# field, ascending, thus getting a stable sort:
#
sort -t ';' -k 2nb,2 -k 1nb,1 |

# Finally remove the leading field of the saved sort result:
#
cut -d ';' -f 2-

Of course this is no better than just doing

sort -t ';' -k 1n,1 -k 2nr,2

but it might be helpful when there are either more than 10 sort
keys (POSIX only requires that "sort" shall at least allow 10
sort keys) or different delimiters ("-t" option), which can't be
specified in one sort invocation.

On Mon, 1 May 2023 18:57:13 -0000 (UTC), Lew Pitcher wrote:
> On Mon, 01 May 2023 20:27:57 +0200, Martin Τrautmann wrote:
>
>> On Mon, 01 May 2023 13:19:24 +0200, Helmut Waitzmann wrote:
>>>> So why does it resort by first column as well?
>>>>
>>>
>>> Because that is the way "sort" is supposed to work. 
>>
>> How should I know that this is supposed that way? If I tell "sort" to
>> sort by a certain column only, why would I have to expect that it will
>> sort by something else as well?
>
> As Helmut said, "because that is the way 'sort' is supposed to work".
> The Open Group defines the interface and results for each of the common
> 'Unix' utilities, "sort[1]" included, and their definition of sort says
> that
> "When there are multiple key fields, later keys shall be compared
> only after all earlier keys compare equal. ... [L]ines that otherwise
> compare equal shall be ordered as if none of the options -d, -f, -i,
> -n, or -k were present ... and with all bytes in the lines
> significant to the comparison."

So where is that information available on my computer? Sorry, but I
really did not think about using a geneology search first to find out
how someone thought something should behave. No, it was not obvious to
me. When -k tells me about first and last key to sort by, I just did not
expect a bonus sort.

Martin Τrautmann <t-usenet@gmx.net> writes:
> On Mon, 1 May 2023 18:57:13 -0000 (UTC), Lew Pitcher wrote:
>> On Mon, 01 May 2023 20:27:57 +0200, Martin Τrautmann wrote:
>>> On Mon, 01 May 2023 13:19:24 +0200, Helmut Waitzmann wrote:
>>>>> So why does it resort by first column as well?
>>>>
>>>> Because that is the way "sort" is supposed to work. 
>>>
>>> How should I know that this is supposed that way? If I tell "sort" to
>>> sort by a certain column only, why would I have to expect that it will
>>> sort by something else as well?
>>
>> As Helmut said, "because that is the way 'sort' is supposed to work".
>> The Open Group defines the interface and results for each of the common
>> 'Unix' utilities, "sort[1]" included, and their definition of sort says
>> that
>> "When there are multiple key fields, later keys shall be compared
>> only after all earlier keys compare equal. ... [L]ines that otherwise
>> compare equal shall be ordered as if none of the options -d, -f, -i,
>> -n, or -k were present ... and with all bytes in the lines
>> significant to the comparison."
>
> So where is that information available on my computer? Sorry, but I
> really did not think about using a geneology search first to find out
> how someone thought something should behave. No, it was not obvious to
> me. When -k tells me about first and last key to sort by, I just did not
> expect a bonus sort.

Nobody is expecting you to know this inherently. Helmut told you
'Because that is the way "sort" is supposed to work.' I don't think he
meant to imply that there was anything wrong with you for not already
knowing it. You asked; he answered.

You *should* be able to get this information with `man sort`. If you
have the GNU coreutils implementation of sort, the man page doesn't
mention re-sorting by the whole line (which is IMHO unfortunate), but at
the bottom of the man page there is a reference to the full
documentation:

Full documentation <https://www.gnu.org/software/coreutils/sort>
or available locally via: info '(coreutils) sort invocation'

If you have an implemntation other than GNU coreutils, `man sort` is
likely to describe it in more detail. `sort --help` is also a good
thing to try.

It's also good to know about the POSIX standard:
<https://pubs.opengroup.org/onlinepubs/9699919799/toc.htm>
This is the standard for the behavior of Unix tools, but not all
implementations follow it completely, and most provide extra
functionality.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

On Mon, 01 May 2023 17:49:24 -0700, Keith Thompson wrote:
> You *should* be able to get this information with `man sort`. If you
> have the GNU coreutils implementation of sort, the man page doesn't
> mention re-sorting by the whole line (which is IMHO unfortunate), but at
> the bottom of the man page there is a reference to the full
> documentation:
>
> Full documentation <https://www.gnu.org/software/coreutils/sort>
> or available locally via: info '(coreutils) sort invocation'
>
> If you have an implemntation other than GNU coreutils, `man sort` is
> likely to describe it in more detail. `sort --help` is also a good
> thing to try.

No, mine says

SEE ALSO
The full documentation for sort is maintained as a Texinfo
manual. If the info and sort programs are properly installed at your
site, the command

info sort

should give you access to the complete manual.

sort 5.93 November 2005
SORT(1)

And info sort does not provide more details here.

> It's also good to know about the POSIX standard:
> <https://pubs.opengroup.org/onlinepubs/9699919799/toc.htm>
> This is the standard for the behavior of Unix tools, but not all
> implementations follow it completely, and most provide extra
> functionality.

It does indicate
+++
Implementations are encouraged to perform the recommended further
byte-by-byte comparison of lines that collate equally, even though this
may affect efficiency. The impact on efficiency can be mitigated by only
performing the additional comparison if the current locale's collating
sequence does not have a total ordering of all characters (if the
implementation provides a way to query this) or by only performing the
additional comparison if the locale name associated with the LC_COLLATE
category has an '@' modifier in the name (since locales without an '@'
modifier should have a total ordering of all characters - see XBD
LC_COLLATE). Note that if the implementation provides a stable sort
option as an extension (usually -s), the additional comparison should
not be performed when this option has been specified.
+++

So the -s stable is named within further notes.

On Tue, 2 May 2023 12:43:00 +0200
Martin =?UTF-8?Q?=CE=A4rautmann?= <t-usenet@gmx.net> wrote:
> On Mon, 01 May 2023 17:49:24 -0700, Keith Thompson wrote:
> > You *should* be able to get this information with `man sort`. If you
> > have the GNU coreutils implementation of sort, the man page doesn't
> > mention re-sorting by the whole line (which is IMHO unfortunate), but at
> > the bottom of the man page there is a reference to the full
> > documentation:
> >
> > Full documentation <https://www.gnu.org/software/coreutils/sort>
> > or available locally via: info '(coreutils) sort invocation'
> >
> > If you have an implemntation other than GNU coreutils, `man sort` is
> > likely to describe it in more detail. `sort --help` is also a good
> > thing to try.
>
> No, mine says
>
> SEE ALSO
> The full documentation for sort is maintained as a Texinfo
> manual. If the info and sort programs are properly installed at your
> site, the command
>
> info sort
>
> should give you access to the complete manual.
>
> sort 5.93 November 2005
> SORT(1)
>
> And info sort does not provide more details here.

On the other hand
https://www.gnu.org/software/coreutils/manual/html_node/sort-invocation.html
says

A pair of lines is compared as follows: sort compares each pair of
fields (see --key), in the order specified on the command line,
according to the associated ordering options, until a difference is
found or no fields are left. If no key fields are specified, sort uses a
default key of the entire line. Finally, as a last resort when all keys
compare equal, sort compares entire lines as if no ordering options
other than --reverse (-r) were specified. The --stable (-s) option
disables this last-resort comparison so that lines in which all fields
compare equal are left in their original relative order. The --unique
(-u) option also disables the last-resort comparison.

..With GNU software it is worth checking (and perhaps also downloading) the
online documentation which usually has a lot more detail than what is
automatically installed and that includes both info and man pages. (GNU
tar is a prominent example)

Martin Τrautmann <t-usenet@gmx.net> writes:
> On Mon, 01 May 2023 17:49:24 -0700, Keith Thompson wrote:
>> You *should* be able to get this information with `man sort`. If you
>> have the GNU coreutils implementation of sort, the man page doesn't
>> mention re-sorting by the whole line (which is IMHO unfortunate), but at
>> the bottom of the man page there is a reference to the full
>> documentation:
>>
>> Full documentation <https://www.gnu.org/software/coreutils/sort>
>> or available locally via: info '(coreutils) sort invocation'
>>
>> If you have an implemntation other than GNU coreutils, `man sort` is
>> likely to describe it in more detail. `sort --help` is also a good
>> thing to try.
>
> No, mine says
>
> SEE ALSO
> The full documentation for sort is maintained as a Texinfo
> manual. If the info and sort programs are properly installed at your
> site, the command
>
> info sort
>
> should give you access to the complete manual.
>
> sort 5.93 November 2005
> SORT(1)
>
> And info sort does not provide more details here.

Yours is quite old. If you don't have the "info" documentation
installed, "info sort" falls back to showing you the man page. Is that
what you're seeing? The info documentation for COREUTILS-5_92 (which I
presume is very close to the version you have) says:

If no key fields are specified, @command{sort} uses a default key of
the entire line. Finally, as a last resort when all keys compare
equal, @command{sort} compares entire lines as if no ordering options
other than @option{--reverse} (@option{-r}) were specified. The
@option{--stable} (@option{-s}) option disables this @dfn{last-resort
comparison} so that lines in which all fields compare equal are left
in their original relative order. The @option{--unique}
(@option{-u}) option also disables the last-resort comparison.

(That's from the raw coreutils.texi file; the info documentation is
generated from it.)

At least on modern Ubuntu, the "coreutils" package installs all the
documentation. Perhaps on your system the tools and the documentation
are in separate packages, for example "coreutils" and "coreutils-doc".

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

On Tue, 02 May 2023 13:41:28 -0700, Keith Thompson wrote:
>> And info sort does not provide more details here.
>
> Yours is quite old. If you don't have the "info" documentation
> installed, "info sort" falls back to showing you the man page.

That's what it does. It's the older MacBook where I do that stuff and
its SSD is limited to get all available coreutils etc. stuff.

Good to know that the actual info files would have known the details.

mlr --fs 'semicolon' --ocsv --hi --ho --from t.ssv sort -n 4 -f 2,3

mfg, el

On 19/04/2023 09:27, Martin Τrautmann wrote:
>
> Hi all,
>
> how do I sort by multiple columns?
>
> Example:
> +++
> Borgentreich;D9386;Lindenstätte;1;;32;520150.696;5709236.354
> Borgentreich;D9444;Auf der Lindenstätte;1;;32;519950.850;5708982.109
> Borgentreich;D9444;Auf der Lindenstätte;2;;32;519926.937;5708966.116
> Borgentreich;D9444;Auf der Lindenstätte;3;;32;520008.619;5709083.464
> Borgentreich;D9444;Auf der Lindenstätte;4;;32;519860.278;5709041.468
> Borgentreich;T2960;Lindenstätte;12;;32;519622.835;5709023.590
> Borgentreich;T2960;Lindenstätte;6;;32;519696.745;5709038.833
> Borgentreich;T2960;Lindenstätte;4;;32;519722.956;5709043.915
> Borgentreich;T2960;Lindenstätte;15;;32;519489.638;5709077.693
> Borgentreich;T2960;Lindenstätte;24;;32;519518.763;5709090.026
> Borgentreich;T2960;Lindenstätte;18;;32;519559.108;5709037.356
> Borgentreich;T2960;Lindenstätte;14;;32;519596.623;5709013.684
> Borgentreich;T2960;Lindenstätte;16;;32;519569.141;5709017.854
> Borgentreich;T2960;Lindenstätte;22;;32;519540.257;5709072.032
> Borgentreich;T2960;Lindenstätte;26;;32;519503.270;5709103.321
> Borgentreich;T2960;Lindenstätte;2;;32;519758.267;5709057.635
> Borgentreich;T2960;Lindenstätte;10;;32;519648.417;5709028.865
> Borgentreich;T2960;Lindenstätte;11;;32;519607.438;5708989.545
> Borgentreich;T2960;Lindenstätte;3;;32;519732.686;5709020.833
> Borgentreich;T2960;Lindenstätte;7;;32;519678.983;5709007.380
> Borgentreich;T2960;Lindenstätte;9;;32;519651.859;5709000.462
> Borgentreich;T2960;Lindenstätte;5;;32;519708.841;5709015.137
> Borgentreich;T2960;Lindenstätte;1;;32;519778.725;5709026.584
> Borgentreich;T2960;Lindenstätte;8;;32;519673.036;5709040.372
> +++
>
> I want to sort
> * first by column 4, numerical,
> * second by column 2
> * third by column 3
>
> So the result should be
> +++
> Borgentreich;D9444;Auf der Lindenstätte;1;;32;519950.850;5708982.109
> Borgentreich;D9444;Auf der Lindenstätte;2;;32;519926.937;5708966.116
> Borgentreich;D9444;Auf der Lindenstätte;3;;32;520008.619;5709083.464
> Borgentreich;D9444;Auf der Lindenstätte;4;;32;519860.278;5709041.468
> Borgentreich;D9386;Lindenstätte;1;;32;520150.696;5709236.354
> Borgentreich;T2960;Lindenstätte;1;;32;519778.725;5709026.584
> Borgentreich;T2960;Lindenstätte;2;;32;519758.267;5709057.635
> Borgentreich;T2960;Lindenstätte;3;;32;519732.686;5709020.833
> Borgentreich;T2960;Lindenstätte;4;;32;519722.956;5709043.915
> Borgentreich;T2960;Lindenstätte;5;;32;519708.841;5709015.137
> Borgentreich;T2960;Lindenstätte;6;;32;519696.745;5709038.833
> Borgentreich;T2960;Lindenstätte;7;;32;519678.983;5709007.380
> Borgentreich;T2960;Lindenstätte;8;;32;519673.036;5709040.372
> Borgentreich;T2960;Lindenstätte;9;;32;519651.859;5709000.462
> Borgentreich;T2960;Lindenstätte;10;;32;519648.417;5709028.865
> Borgentreich;T2960;Lindenstätte;11;;32;519607.438;5708989.545
> Borgentreich;T2960;Lindenstätte;12;;32;519622.835;5709023.590
> Borgentreich;T2960;Lindenstätte;14;;32;519596.623;5709013.684
> Borgentreich;T2960;Lindenstätte;15;;32;519489.638;5709077.693
> Borgentreich;T2960;Lindenstätte;16;;32;519569.141;5709017.854
> Borgentreich;T2960;Lindenstätte;18;;32;519559.108;5709037.356
> Borgentreich;T2960;Lindenstätte;22;;32;519540.257;5709072.032
> Borgentreich;T2960;Lindenstätte;24;;32;519518.763;5709090.026
> Borgentreich;T2960;Lindenstätte;26;;32;519503.270;5709103.321
> +++
>
> I tried both
> sort -k4 -t";" -n | sort -k2,2 -t";" | sort -k3,3 -t";"
> and
> sort -k4 -t";" -n -k2,2 -k3,3
> and some permutations and reverted orders, without success.
> The sort by column 4 just gets lost or resorted.
>
> I'm not sure about the man page
> -k, --key=POS1[,POS2]
> start a key at POS1, end it at POS2 (origin 1)
>
> So I tried relative positions with
> -k3,1
> as well, without success.
>
> How do I apply the sort syntax properly?
>
> Thanks
> Martin

On Fri, 5 May 2023 10:35:01 +0200, Dr Eberhard W Lisse wrote:
> mlr --fs 'semicolon' --ocsv --hi --ho --from t.ssv sort -n 4 -f 2,3

miller looks very powerful to, but unfortunately it's not available here.

On Fri, 5 May 2023 10:35:01 +0200, Dr Eberhard W Lisse wrote:
> mlr --fs 'semicolon' --ocsv --hi --ho --from t.ssv sort -n 4 -f 2,3

miller looks very powerful to me, but unfortunately it's not available here.

In article <slrnu59tbj.2sg.t-usenet@ID-685.user.individual.de>,
Martin rautmann <traut@gmx.de> wrote:
>On Fri, 5 May 2023 10:35:01 +0200, Dr Eberhard W Lisse wrote:
>> mlr --fs 'semicolon' --ocsv --hi --ho --from t.ssv sort -n 4 -f 2,3
>
>miller looks very powerful to me, but unfortunately it's not available here.

Some sort of import/export restriction in your country?

--
If you ask a Trumper who is to blame for the debacle of Jan 6, they will almost certainly say
something about Antifa/BLM/something/whatever. This shows just how screwed up they are; they can't
even get their narrative straight. What they *should* say is "Eugene Goodman". If not for him, the plot
would probably have succeeded, so he (Eugene) is clearly to blame for the failure.

On Fri, 5 May 2023 12:26:56 -0000 (UTC), Kenny McCormack wrote:
> In article <slrnu59tbj.2sg.t-usenet@ID-685.user.individual.de>,
> Martin rautmann <traut@gmx.de> wrote:
>>On Fri, 5 May 2023 10:35:01 +0200, Dr Eberhard W Lisse wrote:
>>> mlr --fs 'semicolon' --ocsv --hi --ho --from t.ssv sort -n 4 -f 2,3
>>
>>miller looks very powerful to me, but unfortunately it's not available here.
>
> Some sort of import/export restriction in your country?

Error: Port miller requires a full Xcode installation, which was not
found on your system.

....and I've not enough space for that, 256 GB SSD only.

In article <slrnu5a50m.2sg.t-usenet@ID-685.user.individual.de>,
Martin rautmann <traut@gmx.de> wrote:
>On Fri, 5 May 2023 12:26:56 -0000 (UTC), Kenny McCormack wrote:
>> In article <slrnu59tbj.2sg.t-usenet@ID-685.user.individual.de>,
>> Martin rautmann <traut@gmx.de> wrote:
>>>On Fri, 5 May 2023 10:35:01 +0200, Dr Eberhard W Lisse wrote:
>>>> mlr --fs 'semicolon' --ocsv --hi --ho --from t.ssv sort -n 4 -f 2,3
>>>
>>>miller looks very powerful to me, but unfortunately it's not available here.
>>
>> Some sort of import/export restriction in your country?
>
>Error: Port miller requires a full Xcode installation, which was not
>found on your system.
>
>...and I've not enough space for that, 256 GB SSD only.

(Quoting Arte Johnson) Interesting... But not very.

I did a little research on "Miller" (which I had never heard of before
today). I don't see the point of it. It just seems like another AWK (or
Perl or Ruby or Python or ...). I.e., what I am saying is that the only
reason to use the "traditional" Unix tools (cut, join, comm, sort, sed,
grep, etc, etc) is because you just don't want to learn anything new (*).
If you were going to learn something new, just learn AWK - which can do all
the things that any/all of those "traditional" tools can do - and much more.
Why bother to learn this "Miller" thing?

(*) Or for pedagogical reasons. I sometimes see people - who obviously
know better - post sed | grep | cut | sed | sort | grep | ...
pipeliners on various boards because they assume their audience is more
comfortable that way.

Finally, I note that you mentioned Xcode. That's a Mac/Apple thing. Is
this "Miller" a specifically Apple thing?

--
To be evangelical is to spend every waking moment hovering around
two emotional states: fear and rage. Evangelicals are seriously the
angriest and most vicious bunch of self-pitying, constantly-moaning
whinybutts I've ever encountered.