Subject: Re: Re: [ast-developers] Variable expansion in js_JP.SJIS locale failswithin double quotes --------
Dr. Werner Fink, <[EMAIL PROTECTED]> wrote: > On Tue, Nov 20, 2007 at 04:50:57PM +0100, Roland Mainz wrote: > > > > Misc questions and some review bickering (mainly based on > > http://mail.opensolaris.org/pipermail/shell-discuss/2007-June/000993.html > > and http://www.opensolaris.org/os/project/shell/shellstyle/) follows: > > Nevertheless I prefere my personal style. Ok it has changed during > the years but it is much older than opensolaris ;) > > > Is "ja_JP.SJIS" the official name of the locale (I'm asking because > > Solaris uses "ja_JP.PCK" for the same stuff and right now it doesn't > > recognise "ja_JP.SJIS" which causes the test to go down in flames) ? > > AFAIK the keyword SJIS or SHIFTJIS or SHIFT_JIS are common for > this encoding. Personal I prefere UTF-8 due to the fact that > UTF-8 does not mix ASCII bytes with 8bit bytes for encoding > non ASCII characters and *preserve* the ASCII character standard. > > > > +for second in $(seq 64 126); do > > > > Erm... "seq" is only available in Linux (or bette: GNU coreutils). AFAIK > > it's better to use > > for ((second=64 ; second <= 128 ; second++ )) ; do > > > > > + : $((chr++)) The AST Toolkit contains a shell version of seq which should be GNU compatable. The problem with seq is that it doesn't scale since it cause the list to be generated before the loop begins. Thus, for second in $(seq 1 1000000) will use several extra megabytes of memory compared to ((second=1; second<1000000; seconds++)) > > I'm aware, nevertheless I prefere it this way from the old days > of bash 2.0 (configured without --enable-dparen-arithmetic for > smallness). But I was not aware that opensolaris does not > have the equivalent of `seq'. They could add the ksh93 version. > > > AFAIK a plain... > > (( chr++ )) > > ...works, too (see > > http://svn.genunix.org/repos/on/branches/ksh93/gisburn/scripts/mandelbrotset1. > ksh > > for more examples). > > > > > + second=$(printf '%x' ${second}) > > > + mbchar="$(printf "\x81\x${second}")" > > > + if test -z "${mbchar}" ; then > > > + : $((err++)) # ERROR in builtin printf > > > > AFAIK a plain... > > (( err++ )) > > ...works, too... > > > > > + continue > > > + fi > > > + if test -x "${printf}" ; then > > > + if test $(${printf} "\x81\x${second}") != ${mbchar} ; then > > > + : $((err++)) # ERROR in builtin printf > > > > See above, AFAIAK the ": $" can be skipped. > > > > > + continue > > > + fi > > > + fi > > > + uq=$(echo ${mbchar}) > > > + dq=$(echo "${mbchar}") > > > + test "$uq" != "$dq" && let err+=1 > > > > AFAIK it may be better to use [[ ]] instead of using the "test" builtin. > > I'm aware of conditional expressions `[[...]]'. I use this only if > I really depend on conditional expressions combined with extended > regular expressions and use a bash 3.0 or above. The problems with test are well known and if you really know what you are doing, then there is no problem. However, for a novice, test is a problem. You need to worry about word splitting and file name generation changing the meaning. You also need to worry about words that expand to a leading - chaning the meaning. In my experience with users, this is one of the major causes for script failure. > > If I do not depend on extended regular expressions then I prefere > to use the builtin `test' by its name and never the `[...]'. IMHO > this makes script code more readable especially if combined with > the exit status of other builtins or programs. > > > Werner David Korn [EMAIL PROTECTED] _______________________________________________ ast-developers mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-developers
