Re: [bug-gawk] asort 3rd argument does not work as documented

[Aharon Robbins]

Hi Andy.

Harumph.  The doc is wrong.  The code and doc were evolving in parallel
and at some point got out of sync.

I'm not going to mess with the code at this point, so I will have
to fix the doc.

Thanks for pointing this out.

Arnold

P.S. On a different note, this is serioulsy discouraging. It's been 
wrong for over three years and noone noticed until now. Sigh.

> Date: Fri, 8 Nov 2013 12:49:01 -0500
> From: "Andrew J. Schorr" <address@hidden>
> To: address@hidden
> Subject: [bug-gawk] asort 3rd argument does not work as documented
>
> Hi,
>
> In doc/gawk.texi, it says:
>
>    The optional third argument @var{how} is a string which controls the rule
>    for comparing values, and the sort direction.  A single space is required
>    between the comparison mode, @samp{string} or @samp{number}, and the
>    direction specification, @samp{ascending} or @samp{descending}.  
>
> I tried using asorti with "number ascending", and I got a fatal error:
>
> gawk: cmd. line:35: (FILENAME=- FNR=182) fatal: `number ascending' is invalid 
> as a function name
>
> Based on inspection of the source code, it seems that the actual 3rd argument
> should be one of the PROCINFO["sorted_in"] values, such as "@val_num_asc".
>
> So it seems that there is either a documentation bug, or the code should
> be enhanced to support these more user-friendly values for describing the
> sort function.
>
> In this context, it is easy to be confused about whether to use "@ind_num_asc"
> or "@val_num_asc", so it would be nice to implement the documented behavior.
> By experimentation, I found that "@val_num_asc" for my asorti case where I
> want "number ascending".
>
> Regards,
> Andy