Email List: Xaustin-group-lX
[All Lists]

Locale command doc clarifications needed

To: austin-group-l@xxxxxxxxxxxxx
Subject: Locale command doc clarifications needed
From: Wayne Pollock <pollock@xxxxxxx>
Date: Wed, 13 May 2009 23:56:31 -0400
I have the following two issues with locale:

The documentation for the locale command at
http://www.opengroup.org/onlinepubs/009695399/utilities/locale.html
includes the following in the examples section:

<quote>
The following command shows an application of locale to determine whether a
user-supplied response is affirmative:

if printf "%s\n" "$response" | grep -Eq "$(locale yesexpr)"
then
    affirmative processing goes here
else
    non-affirmative processing goes here
fi
</quote>

Stephane CHAZELAS <stephane_chazelas@xxxxxx> pointed out
(comp.unix.shell posting "Re: [ksh93] Use of =~" on
2009-01-21) that this may not work correctly in some cases,
and provided a working alternative:

<quote>
We'd have to rule out
 grep -E (printf '%s\n' "$ans" | grep -Ee "$(locale yesexpr)")
because it acts on every line of
$ans, instead of the whole of it (for instance, in an english
locale, it would wrongly say that 'no!\nY' means yes.

One could use awk:

   if awk 'BEGIN { exit(ARGV[1] !~ ARGV[2]) }' "$ans" "$(
      locale yesexpr)"
   then ...
</quote>

Either the example in the docs should be updated, or
the explanation for "yesexpr" and "noexpr" in section
7.3.6 should be updated to reflex that if the response
string contains newlines the results are undefined.  Or
both.

The second issue is that the POSIX definition for yesexpr
and noexpr (in LC_MESSAGES) is anchored at the beginning.
The fact that the EREs are anchored or not makes a
difference:

   grep -E "^$(locale yesexpr)$"

won't (or at least may not) work if the ERE returned
by locale is already anchored.  I believe the wording
should be changed to reflect that the ERE returned is
always anchored at the beginning and not at the end.
(I think this reflects current and historical practice).

[Issue 3]
On a related note, is there any reason why these are
defined as EREs?  If they were BREs (and known to be
anchored at the beginning) then you could use this code:

   yesRE=$(locale yesexpr)
   if expr "$ans" : "${yesRE#?}" >/dev/null
   ...

which somehow appeals to me more than the printf plus grep
pipeline or the awk solutions.  Even if the definition isn't
changed to state these are BREs, maybe it could be noted
that the ERE returned by locale for these must be suitable
for use with expr (with the leading anchor removed).

-- 
Wayne Pollock

<Prev in Thread] Current Thread [Next in Thread>