People,
For the attached file these work:
sort -k 1.11,1.18n t sort -k 1.3,1.6n t
but this doesn't:
sort -k 1.8 -k 1.3,1.6n t
Why is this?
Thanks,
Phil.
On Sun, 27 Apr 2025 20:12:55 +1000, Philip Rhoades via users wrote:
People,
For the attached file these work:
sort -k 1.11,1.18n t sort -k 1.3,1.6n t
but this doesn't:
sort -k 1.8 -k 1.3,1.6n t
Why is this?
Add option --debug, show the output you get, and describe what you believe doesn't work.
On 2025-04-27 21:15, Michael Schwendt wrote:
On Sun, 27 Apr 2025 20:12:55 +1000, Philip Rhoades via users wrote:
People,
For the attached file these work:
sort -k 1.11,1.18n t sort -k 1.3,1.6n t
but this doesn't:
sort -k 1.8 -k 1.3,1.6n t
Why is this?
Add option --debug, show the output you get, and describe what you believe doesn't work.
sort: text ordering performed using simple byte comparison sort: leading blanks are significant in key 1; consider also specifying 'b' sort: note numbers use '.' as a decimal point in this locale E_20.0_GB_20060611.smartctl ____________________ ____ . .
Chars 3-6 are not being sorted numerically after lines are sorted by char 8.
P.
Michael,
On 2025-04-28 00:35, Michael Schwendt wrote:
On Sun, 27 Apr 2025 22:02:47 +1000, Philip Rhoades wrote:
sort: text ordering performed using simple byte comparison
What's your locale?
C
If you prefix your command with e.g. LC_ALL=en_AU.UTF-8 what happens?
No difference / improvement.
P.
On Mon, 28 Apr 2025 02:59:55 +1000, Philip Rhoades wrote:
If you prefix your command with e.g. LC_ALL=en_AU.UTF-8 what happens?
No difference / improvement.
Then I repeat my request to see example output.
Your first key's stop position is at end of line, which is very generous. So, for many of the lines in your file the YYYYMMDD portion may be equal, and since the rest of the line will be significant, the second key doesn't matter anymore then. It only becomes significant, if the first key's comparison is equal.
Michael,
On 2025-04-28 04:42, Michael Schwendt wrote:
On Mon, 28 Apr 2025 02:59:55 +1000, Philip Rhoades wrote:
If you prefix your command with e.g. LC_ALL=en_AU.UTF-8 what happens?
No difference / improvement.
Then I repeat my request to see example output.
Your first key's stop position is at end of line, which is very generous. So, for many of the lines in your file the YYYYMMDD portion may be equal, and since the rest of the line will be significant, the second key doesn't matter anymore then. It only becomes significant, if the first key's comparison is equal.
Ah! - I see the problem now - I thought "-k 1.8" would only look at one char - in fact I have to use: "-k 1.8,1.8"
Thanks for that!
P.
-
Michael Schwendt -
Philip Rhoades