On 7/5/11 8:59 AM, Bruce Korb wrote:
>> The issue is extremely nontrivial.
>
> The normal case is to sort full releases. The goal in "sort -V" was to make
> the usual case easy, not to make an authoritative solution to the intractable
> problem. In any event, Chet doesn't think there is sufficie
On 07/06/11 10:19, Eric Blake wrote:
Oh, that's rather heavyweight - a command substitution and 3 pipeline
components. Why not just one child process, by using sort -c and a heredoc?
is_eq=false is_lt=false
if test "x$1" = "$x2"; then
is_eq=true
elif sort -cV el
On 07/06/2011 10:37 AM, Bruce Korb wrote:
> On 07/06/11 09:03, Chet Ramey wrote:
>>> /usr/bin/test ?
>>>
>>> Do this first in the binary then migrate to bash's test?
>>
>> I was actually making an argument for an entirely separate utility to do
>> this. That could be a shell script encapsulating t
Hello y'all,
First, I need to say that I'm writing this after some measure of pause, because
bash is already so richly-featured, and is the product of so much development
over so much time. However, in my recent use of bash, the following could have
been useful, and y'all might think would be u
On 7/6/11 1:52 PM, Bruce Korb wrote:
>>> I would not expect "sort -V" and a version test to disagree.
>>
>> The code that coreutils uses for 'sort -V' is part of gnulib - the
>> filevercmp module. That file (filevercmp.c) is pretty stable nowadays,
>> with the last algorithmic change being in Apr
