Bug#320078: whiptail is unable to handle special characters not present in current locale
On Wed, Jul 27, 2005 at 09:11:21AM -0400, Thomas Dickey wrote: On Wed, Jul 27, 2005 at 02:50:06PM +0200, Micha Lenk wrote: Is it even not possible to prevent the user from entering non-locale characters? As a user I would prefer to get multiple other but legal characters when I enter a non-locale character, wich I am able to delete just after. In cases where I enter such a non-locale character by accident I would at least be able to correct my mistake. There are two cases: displaying data that it reads from some other location and data entered from the keyboard. whiptail should of course distinguish between the two. If it cannot at least let you delete the keyboard entry, that's a defect in whiptail. Hi, Alastair Regarding this I would like to point to a closely related problem that should probably fit into this bugreport (please let me know if you prefer me to open a new one). When some utf-8 text is injected into whiptail, and seen from a single byte environment, utf8 strings are shown as a concatenation of the single byte chars, not funny, but really the expected behavior. However, when those single byte chars contain any char that is not displayable in the local encoding, whiptail seems to be confused in menu items, and anything after that char is skipped on display for that item, although if selected returns the complete string as expected. Surprisingly in text the non-displayable char is shown as a code, and further text is properly displayed, what seems acceptable. I am attaching a sample script to reproduce that, to be run in a latin1 environment. It contains bulgarian in cyrillic followed by a 7bit string, $the_utf8_string means bulgarian and displays it both as text and as a menu item. The problem is that the utf8 string contains \212, which is not displayable for latin1, as fourth char, and some similar chars afterwards, so menu is shown as (what is in square brackets is what should be the first menu item, after non-displayable-something) - Here goes the text with [бÑ8AлгаÑ80Ñ81ки means bulgarian] Ð±Ñ normal text - and in menu item everything after \212 is ignored, and only Ð±Ñ is shown in that item. dialog works as expected, but on display replaces non-displayable chars by ~ Cheers, -- Agustin #!/bin/sh # -*- coding: utf-8 -*- : ${DIALOG=whiptail} tempfile=`tempfile 2/dev/null` || tempfile=/tmp/test$$ trap rm -f $tempfile 0 1 2 5 15 function analyze { retval=$1 option=$2 case $retval in 0) echo [`cat $tempfile`] chosen fror $option;; 1) echo Cancel pressed.;; 255) if test -s $tempfile ; then cat $tempfile else echo ESC pressed. fi ;; esac } text=бÑлгаÑÑки means bulgarian #--msgbox text height width $DIALOG --msgbox $text 30 50 # --menu text height width menu-height [ tag item ] ... $DIALOG --menu Here goes the text with\n[$text] 30 50 20 $text normal text 2 $tempfile analyze $? --menubox
Bug#320078: whiptail is unable to handle special characters not present in current locale
tags 320078 -wontfix severity 320078 normal thanks On Céad, 2005-07-27 at 09:11 -0400, Thomas Dickey wrote: On Wed, Jul 27, 2005 at 02:50:06PM +0200, Micha Lenk wrote: Is it even not possible to prevent the user from entering non-locale characters? As a user I would prefer to get multiple other but legal characters when I enter a non-locale character, wich I am able to delete just after. In cases where I enter such a non-locale character by accident I would at least be able to correct my mistake. There are two cases: displaying data that it reads from some other location and data entered from the keyboard. whiptail should of course distinguish between the two. If it cannot at least let you delete the keyboard entry, that's a defect in whiptail. Ok. Agreed. re-opening the bug. The solution is to ensure such garbage characters don't get entered into whiptail, etc. (or other X programs). Use a non C locale, in particular use UTF-8, and make sure all programs produce UTF-8. whiptail isn't an X program, btw. oops, yes. I'd mean't to put an or X programs, etc in there. Regards Alastair -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320078: whiptail is unable to handle special characters not present in current locale
tags 320078 wontfix thanks I'm tagging this 'wontfix' as its unfixable. The problem is that 'characters not in the current locale' are garbage bytes as far as _any_ software is concerned: if you enter some 'non-locale character' whiptail gets a bunch of uninterpretable bytes. it can't even reliably figure out what was the last 'real' character before these. whiptail is not unique in this: it is true of all software. Its just that whiptail is in the front of the pipeline to receive and display them. The solution is to ensure such garbage characters don't get entered into whiptail, etc. (or other X programs). Use a non C locale, in particular use UTF-8, and make sure all programs produce UTF-8. Regards Alastair On Máirt, 2005-07-26 at 22:42 +0200, Micha Lenk wrote: Package: whiptail Version: 0.51.6-28 Severity: wishlist If I feed my whiptail with characters which aren't present in the current locale whiptail is unable to handle these characters. You can't delete the feeded input whithin the input box. This occurs for instance with the locale LANG=C, LC_CTYPE=C and characters like '???'. This problem is somewhat relevant for debconf (with which I discovered this bug) as debconf accepted a special character and saved it. In a second run of debconf I wasn't able to fix the bad input of the run before. Between both debconf runs I didn't touch the locale (locales haven't been installed at that stage). For easier understanding of the problem I attached a simple small shell script which calls whiptail with potentially evil options... Micha -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages whiptail depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libnewt0.51 0.51.6-28Not Erik's Windowing Toolkit - tex ii libpopt01.7-5lib for parsing cmdline parameters ii libslang2 2.0.4-4 The S-Lang programming library - r whiptail recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320078: whiptail is unable to handle special characters not present in current locale
Hello Alastair, Alastair McKinstry schrieb: The problem is that 'characters not in the current locale' are garbage bytes as far as _any_ software is concerned: if you enter some 'non-locale character' whiptail gets a bunch of uninterpretable bytes. it can't even reliably figure out what was the last 'real' character before these. whiptail is not unique in this: it is true of all software. Its just that whiptail is in the front of the pipeline to receive and display them. Is it even not possible to prevent the user from entering non-locale characters? As a user I would prefer to get multiple other but legal characters when I enter a non-locale character, wich I am able to delete just after. In cases where I enter such a non-locale character by accident I would at least be able to correct my mistake. The solution is to ensure such garbage characters don't get entered into whiptail, etc. (or other X programs). Use a non C locale, in particular use UTF-8, and make sure all programs produce UTF-8. Well, but that's what I'm asking for: Whiptail shouldn't accept those garbage characters if the locale doesn't support them. Remeber: I wasn't even willing to enter these ugly garbage characters... Please think it over again. Yours Micha -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320078: whiptail is unable to handle special characters not present in current locale
On Wed, Jul 27, 2005 at 02:50:06PM +0200, Micha Lenk wrote: Is it even not possible to prevent the user from entering non-locale characters? As a user I would prefer to get multiple other but legal characters when I enter a non-locale character, wich I am able to delete just after. In cases where I enter such a non-locale character by accident I would at least be able to correct my mistake. There are two cases: displaying data that it reads from some other location and data entered from the keyboard. whiptail should of course distinguish between the two. If it cannot at least let you delete the keyboard entry, that's a defect in whiptail. The solution is to ensure such garbage characters don't get entered into whiptail, etc. (or other X programs). Use a non C locale, in particular use UTF-8, and make sure all programs produce UTF-8. whiptail isn't an X program, btw. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpoyubWGgtYL.pgp Description: PGP signature
Bug#320078: whiptail is unable to handle special characters not present in current locale
Package: whiptail Version: 0.51.6-28 Severity: wishlist If I feed my whiptail with characters which aren't present in the current locale whiptail is unable to handle these characters. You can't delete the feeded input whithin the input box. This occurs for instance with the locale LANG=C, LC_CTYPE=C and characters like '???'. This problem is somewhat relevant for debconf (with which I discovered this bug) as debconf accepted a special character and saved it. In a second run of debconf I wasn't able to fix the bad input of the run before. Between both debconf runs I didn't touch the locale (locales haven't been installed at that stage). For easier understanding of the problem I attached a simple small shell script which calls whiptail with potentially evil options... Micha -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages whiptail depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libnewt0.51 0.51.6-28Not Erik's Windowing Toolkit - tex ii libpopt01.7-5lib for parsing cmdline parameters ii libslang2 2.0.4-4 The S-Lang programming library - r whiptail recommends no packages. -- no debconf information whiptailbug.sh Description: Bourne shell script