#1233 options for lsort have no effect when only one list element

obsolete: 8.2
closed-fixed
4
2001-03-29
2000-10-26
Anonymous
No

OriginalBugID: 3330 Bug
Version: 8.2
SubmitDate: '1999-11-05'
LastModified: '1999-11-11'
Severity: MED
Status: Assigned
Submitter: techsupp
ChangedBy: hobbs
OS: Windows 95
FixedDate: '2000-10-25'
ClosedDate: '2000-10-25'

Name: keith lea

ReproducibleScript:
% lsort -integer f
f
%

DesiredBehavior:
i'd rather get an error message!

An error would be correct in this case, while the current source
just assumes this is a quick noop.
-- 11/11/1999 hobbs

Discussion

1 2 > >> (Page 1 of 2)
    • priority: 5 --> 4
     
  • I don't know whether an error is correct; surely the options just control the nature of the ordering function. No ordering required, all ordering functions are happy. Plus, how could you test in the first place? Calling the ordering function with the same element for both values is a much worse idea, particularly if the ordering function was specified using -command...

     
    • labels: 104238 --> 17. Commands I-L
     
    • assigned_to: nobody --> dkf
     
  • Hmm. This needs a rewrite of the manual page to state that the conversion to integer/float happens as part of the comparison, and not prior to the overall sort (which I believe to be the correct behaviour.)

     
  • Logged In: YES
    user_id=79902

    Trying to attach a patch that fixes this...

     
  • Logged In: YES
    user_id=79902

    I really meant to say:
    http://www.cs.man.ac.uk/~fellowsd/tcl/patches/lsortdoc.patch

    (I think I can see why uploading patches is not entirely
    evil, since then at least the links don't get broken by
    stupid typos... :^)

     
  • Logged In: YES
    user_id=79902

    Trying to upload the patch here...

     
  • Documentation Update

     
    Attachments
1 2 > >> (Page 1 of 2)