On Mon, Feb 25, 2013 at 5:54 AM, Cedric Blancher
<[email protected]> wrote:
> On 25 February 2013 01:20, Cedric Blancher
> <[email protected]> wrote:
>> On 23 February 2013 08:40, Glenn Fowler <[email protected]> wrote:
>>>
>>> the AT&T Software Technology ast alpha 2013-02-22 source
>>> has been posted to the download site
>>> http://www.research.att.com/sw/download/alpha/
>>> the package names and md5 checksums are
>>> INIT 3a3a881b9bb16c8d1268517a0702fa43
>>> ast-ksh 1d3f9a8da99d1fa32f5fe124e39e5eeb
>>> the md5 sums should match the ones listed on the download page
>>> if not then don't download
>>>
>>> this release contains a few more ksh93v- fixes
>>
>> The l10n bug is still there and *cripples* our scripts:
>>
>> ---------- Forwarded message ----------
>> From: Cedric Blancher <[email protected]>
>> Date: 21 February 2013 18:08
>> Subject: Re: [ast-developers] 2013-02-14 alpha
>> To: Irek Szczesniak <[email protected]>
>> Cc: Glenn Fowler <[email protected]>,
>> [email protected], Roland Mainz
>> <[email protected]>, Susan Korn <[email protected]>
>>
>>
>> On 21 February 2013 12:21, Irek Szczesniak <[email protected]> wrote:
>>> On Mon, Feb 18, 2013 at 5:51 PM, Glenn Fowler <[email protected]> wrote:
>>>>
>>>> 2013-02-14 alpha posted to www.research.att.com/download/alpha/
>>>> INIT.2013-02-14.tgz
>>>> ast-ksh.2013-02-14.tgz
>>>> this is a work in progress
>>>> there are known problems on some architectures
>>>
>>> Has anyone encountered problems with LANG/LC_ALL switching and ksh93
>>> $"..." based localization? We've seen weired issues but haven't found
>>> a test case yet.
>>
>> I see that, too. The tests Roland Mainz wrote go berserk for this ksh93
>> version:
>> script_l10n_literals.ksh[64]: test_basic1:t1: Expected stderr=='', got
>> 'Usage: unset [-nfv] name...'
[snip]
>
> ast-ksh.20121121 passes Roland's test module without trouble:
> (export SHELL=~/prod/ast/20121121/build686/arch/linux.i386-64/bin/ksh
> ; $SHELL ./src/cmd/ksh93/tests/shtests -l LC_ALL=C
> ./src/cmd/ksh93/tests/script_l10n_literals.sh )
> test script_l10n_literals begins at 2013-02-25+05:48:47
> test script_l10n_literals passed at 2013-02-25+05:48:48 [ 12 tests 0 errors ]
> test script_l10n_literals(shcomp) begins at 2013-02-25+05:48:48
> test script_l10n_literals(shcomp) passed at 2013-02-25+05:48:48 [ 12
> tests 0 errors ]
>
> The following ast-ksh version (ast-ksh.20130214) fails as I reported earlier.
>
> I think the problem is because of the LC_ALL=C, removing it from the
> shtests call fixes the failures - but why did ast-ksh.20121121 not
> fail for the same test?
Erm... it's not really the tests which fail... the "unsetting" of all
LC_* variables fails because ${!LC_*} expands to nothing in ksh93 >=
ast-ksh.2013-02-14 ...
... example:
-- snip --
# ksh93 u+ prints:
$ myvar_moo=C /bin/ksh -c 'printf "|%s|\n" "${!myvar_*}"'
|myvar_moo|
# bash 4 prints:
$ myvar_moo=C /bin/bash -c 'printf "|%s|\n" "${!myvar_*}"'
|myvar_moo|
#
# but ast-ksh.2013-02-14 prints:
$ myvar_moo=C ~/bin/ksh -c 'printf "|%s|\n" "${!myvar_*}"'
||
-- snip --
Same applies to "${!var@}" expansion:
-- snip --
# ksh93 u+ prints:
$ myvar_moo=C myvar_chicken=D /bin/ksh -c 'printf "|%s|\n" "${!myvar_@}"'
|myvar_chicken|
|myvar_moo|
# bash 4 prints:
$ myvar_moo=C myvar_chicken=D /bin/bash -c 'printf "|%s|\n" "${!myvar_@}"'
|myvar_chicken|
|myvar_moo|
#
# but ast-ksh.2013-02-14 prints:
$ myvar_moo=C myvar_chicken=D ~/bin/ksh -c 'printf "|%s|\n" "${!myvar_@}"'
||
-- snip --
The script l10n test module fails because it unsets _all_ LC_*
variables using $ unset ${!LC_*} # (new version wil use $ unset
"${!LC_*}" #) ... which no longer works in ast-ksh.2013-02-14+ and
therefore causes other malfunctions...
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
