On Tue, Apr 10, 2012 at 07:00, Lionel Cons <[email protected]>wrote:
> Hello, we're encountering a serious bug when migrating some of our > data processing scripts from bash to ksh93. After a lengthily > investigation we traced the problem down to ksh93's read command not > supporting non-ASCII characters as delimiters (read -d) in the Unicode > locale (en_GB.UTF-8). > > Testcase: > Try to read the string "x123€hello" via read and use the EURO symbol > (Unicode 20AC) as delimiter: > > zsh returns the expected behaviour: > > zsh -c 'printf "x123€hello\n" | (read -d "€" r ; printf "|%s|\n" "$r")' > |x123| > > bash returns the expected behaviour, too: > > bash -c 'printf "x123€hello\n" | (read -d "€" r ; printf "|%s|\n" "$r")' > |x123| > > ksh93 in Redhat and Debian Linux FAILS: > > ksh -c 'printf "x123€hello\n" | (read -d "€" r ; printf "|%s|\n" "$r")' > |x123€hello > | > > > Any help would be appreciated because our migration deadline is soon > (end of may 2012). > Not sure how heavily you depend on this feature. Do other utils like awk help? BTW, why the bash to ksh migration for existing scripts? If you prefer ksh you can write new scripts in ksh. I don't think it's a good idea to convert lots of bash scripts which are working well to ksh. :) > > Lionel > > _______________________________________________ > ast-users mailing list > [email protected] > https://mailman.research.att.com/mailman/listinfo/ast-users >
_______________________________________________ ast-users mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-users
