[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Sort by version number (patch included)
From: |
Pádraig Brady |
Subject: |
Re: Sort by version number (patch included) |
Date: |
Thu, 03 Nov 2005 09:52:20 +0000 |
User-agent: |
Mozilla Thunderbird 1.0.7 (X11/20051013) |
Ian Dall wrote:
>Padraig Brady writes:
> > Ian Dall wrote:
> >
> > >I needed to sort by version number so that 1.2.12 > 1.2.3
> > >
> > >[...]
> > >
> > >2005-11-02 Ian Dall <address@hidden>
> > >
> > > * coreutils.texi (sort invocation): Document new option
> > > --version-sort (-v).
> >
> > Thanks.
> > I agree that this would be very useful.
> > Please compare to the existing functionality in ls though.
> > I prefer the more general mechanism of a --sort= parameter
> > as I can see many other possible methods (like random for e.g.).
> >
> > For reference here is what ls does:
> >
> > $ ls -1
> > file1-1.23.tar.gz
> > file1-1.4.tar.gz
> > file2-1.4-12.tar.gz
> > file2-1.4-1.tar.gz
> > file2-1.4-2.tar.gz
> > file2-1.4.tar.gz
> >
> > $ ls -1 --sort=version
> > file1-1.4.tar.gz
> > file1-1.23.tar.gz
> > file2-1.4-1.tar.gz
> > file2-1.4-2.tar.gz
> > file2-1.4-12.tar.gz
> > file2-1.4.tar.gz
>
>This is just a question about the syntax for the option right? The
>sort behaviour is exactly the same because they use the same
>comparison function.
>
>
yes
>I can see why it would be good to be consistant with the option syntax
>between ls and sort, on the other hand, sort is an auxillary feature
>of ls, but the prime feature of sort.
>
fair enough. I was thinking of extensibility and ease of reference
for the --sort option.
> Also, in sort, each sort method
>needs a single character "short" option so it can be used as a per
>field flag.
>
>
You run out of these quickly. Also -v is usually used for verbose in
other utils.
>There is no real reason why one can't have a mixture --sort=version is
>the long option and -k n,mv for the field option and either -v for the
>short global option or disallow the short global option. To be
>consistent though really the other long sort options should be
>--sort=numeric --sort=month etc., but changing that is going to break
>scripts which use the existing long options.
>
>
Yes we will need to keep the existing options I'm afraid.
>I can see a tension between stability and consistency within sort and
>across utilites. I am happy to use the --sort=version form, but want to know:
>
>1. Is this just for new sort options?
>
>
no
>2. If not, should all the various --sort=xxx options be added
>
>
yes
>3. If so, are the old long options to be removed, depeciated or kept
> indefinitely
>
>
Document existing options as deprecated
>4. Should there be a global short option and should it be "-v"?
>
>
>
That's a bit tricky. I would say no (and also deprecate other global
short options)
>5. If not, is it OK to use 'v' as a flag for version sorting of a
> field?
>
>
Yes.
thanks for the lucid email.
Pádraig.