hplip seems to be broken for non-en_US locales
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
HPLIP |
New
|
Undecided
|
Unassigned | ||
hplip (Debian) |
Confirmed
|
Unknown
|
Bug Description
Various scripts in hplip source code are dependent on locale,
for e.g. take a look at this demonstration:
# LC_ALL=pl_PL hp-check 2>&1 | grep -A 7 QUEUES
| INSTALLED CUPS PRINTER QUEUES |
-------
-------
| SANE CONFIGURATION |
-------
# _
hp-check found no queues with LC_ALL=pl_PL environment on my system.
The same with LC_ALL=C:
# LC_ALL=C hp-check 2>&1 | grep -A 6 QUEUES
| INSTALLED CUPS PRINTER QUEUES |
-------
F380
----
Type: Printer
# _
At this time ("C" locale) the printer queue was found.
Other components of hplip doesn't work on my system neither
in non-en_US locales: hp-toolbox doesn't find any HP devices
nor does the printing work at all.
Above example was tested on hplip 2.8.2, but 2.8.4 source code
seems to have the same bugs.
For e.g. in check.py (line 503) available printers are filtered using output of
`lpstat -v` and the regular expression:
lpstat_pat = re.compile(
In non-en_US locale `lpstat` output starts with localised message
instead of "device for", so check.py doesn't find any devices
and printing doesn't work at all.
Maybe all external programs should be executed from hplip in C locale?
(Though I'm not sure, if that would suffice to fix this bug).
description: | updated |
Changed in hplip: | |
status: | Unknown → Confirmed |
See the possibly related bug /bugs.launchpad .net/hplip/ +bug/162196
https:/
In general, when external programs are run
and their output is parsed, a plain ASCII locale
should be used.
Furthermore when external programs are run
the PATH must be set sufficiently secure to
avoid that unwanted programs are run.
For example I use in my bash scripts to get
a hopefully sufficiently secure environment:
export PATH="/ sbin:/usr/ sbin:/usr/ bin:/bin"
export LC_ALL="POSIX"
export LANG="POSIX"
umask 022