Bug#320078: whiptail is unable to handle special characters not present in current locale

2005-10-06 Thread Agustin Martin
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

2005-07-28 Thread Alastair McKinstry
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

2005-07-27 Thread Alastair McKinstry
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

2005-07-27 Thread Micha Lenk
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

2005-07-27 Thread Thomas Dickey
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

2005-07-26 Thread Micha Lenk
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