On Sat, Feb 10, 2007 at 12:30:11PM -0800, Roger Marquis wrote:
Good question. The only answer is that 'sort -M' works as expected
on the other platforms where we use it, including earlier versions of
gnu coreutils.
It doesn't seem to work the way you seem to expect it to, anywhere I
tested it (including previous versions of coreutils--tested on 5.2.1).
Maybe it works that way on solaris?
sort -u -k 1,1M -k 2,2n -k 3
Thanks. This may be a good workaround
It's not a workaround, it's how it works. If you want different fields
sorted in different ways, you need to specify that.
It wasn't an accusation, it was a statement of fact. I was also
the only reason I could think of why a problem with a relatively
uncommon option to a non-critical text processing utility would
be called "important".
Interesting response, though both subjective and incorrect.
What part is subjective and incorrect? It's a fact that the severity
level doesn't change the response time. It's also a fact that I couldn't
think of good reason to label that sort of report "important". Were you
objecting to uncommon? -M isn't POSIX, and shouldn't even be used where
portability is important--which I'd consider a prerequisite for calling
an option in a POSIX utility "common". Maybe "non-critical"? Lack of
sort won't cause the system not to boot (it's even in /usr/bin rather
than /bin) and I think that's a fair definition of non-critical.
Can't recall another like it in over 20 years of Unix/Linux bug reports
Maybe you've been submitting reports for too long to just say "yup,
maybe I overstated the severity"? If nothing else, when increasing the
severity over the default, it's good to at least explain a rationale.
The person getting the report may still disagree with the rationale, but
at least it doesn't look as much like automatic priority inflation.
Mike Stone
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
