Dear Maintainer,

Suspecting a bug in psutils.

Bug causes tool to die to assert failure, if locale is set. Affects at least fi_FI.UTF-8.
Suspecting that affects all that use decimal comma instead of a decimal dot, but this is a guess.

Tool fails, when I run a command like 'psnup -p a4 -P a4 -4 < infile.ps > outfile.ps'

Tool runs normally, if I change that to 'LC_ALL="C" psnup -p a4 -P a4 -4 < infile.ps > outfile.ps'

When the tool fails, there is an assert failure in /usr/lib/python3/dist-packages/psutils/libpaper.py method get_paper_size()
and output file is zero size.

Hi, I encountered the same issue as described in this bug report,
I think I was able to narrow down the root cause more precisely.

My problem occurs in psutils/libpaper.py.
Here the regex pattern for parsing paper dimensions assumes decimal
points, but the input string (from libpaper) uses decimal commas in
certain locales (e.g., nl_NL).

**Root Cause:**
The regex in libpaper.py (line 41) is: m = re.search("
([.0-9]+)x([.0-9]+) pt$", dimensions)

However, when the system locale uses a decimal comma (e.g., nl_NL), the
output from libpaper is formatted with the dutch decimal comma: "A4:
595,276x841,89 pt"
Subsequently, the regex fails to match because it only expects decimal
points.

**Proposed Solutions:**
1. **Locale-neutral parsing**: Ensure that the string passed to
`re.search` always  uses decimal points, regardless of the user's
locale. This could be done by  temporarily setting `LC_ALL=C` when
calling libpaper functions.

2. **Explicit comma handling**: Modify the regex to accept both commas
and points:
m = re.search(" ([.,0-9]+)x([.,0-9]+) pt$", dimensions)
And replace commas with points before converting to float: w, h =
float(m[1].replace(",", ".")), float(m[2].replace(",", "."))

**Why Solution 1 is Preferred:**
Handling locale-specific formatting at the point where libpaper outputs
the dimensions (rather than in the regex) is cleaner and more
maintainable. It ensures that the rest of the code does not need to
(also) account for locale-specific quirks.

**Additional Context:**

- Setting `LC_ALL=C` works as a temporary workaround, but it is not
ideal for  users who need to retain their locale settings.
- The issue affects all tools in psutils that rely on libpaper (e.g.,
psbook, psnup, etc.).

Let me know if you need further clarification or testing.
Regards,
  Hans de Jonge

Hans de Jonge writes ("Bug#1135344: Additional details on locale-related AssertionError in psutils/libpaper.py"):

Did you use an LLM to generate some of this text?  If so please send
the prompt.  If not, sorry for impugning you...

Ian.

(Moving the conversation back to the bug.)

Hans de Jonge writes ("Additional information."):

Yes, the function of LC_ALL is to override all other LC_* settings.
It's not normally a good idea to set it routinely in your shell.
You probably wanted to set LANG.

https://unix.stackexchange.com/questions/87745/what-does-lc-all-c-do

I don't think psutils ought to set LC_ALL itself when running
paper(1), because that would result in (for example) error messages in
English rather than the user's language.  (paper(1) seems not to
produced localised error messages anyway right now, but that might
change and also libc messages might be affected.)

I RTFM paper(1) and it says:

  paper prints information about the given paper sizes, which can
  include the standard form of its name, its width and height. The
  output is designed to be both human- and machine-readable.  ...

I think the mention of a machine-readable format implies that use of
the localised numeric format is a bug.  I have filed a separate bug
abaout that, #1148277.

Thanks.  Like I say I prefer to avoid reading LLM output, so
unfortunately given the way it's all mixed together there, that wasn't
what I hoped for.

Thanks for the clarification.  I prefer not to read LLM output because
I consider it hazardous (due to adverse cognitive effects on users, as
well as the propensity for bullshit) and because I consider the means
by which LLMs are produced to be highly unethical and destructive.

I'm happy to read text in Dutch if you prefer.  My Dutch isn't great
but should be enough.  I'm also very happy with imperfect English.

Ian.