bug-coreutils
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]