SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I connected this morning, trapped the 70k or so of errors. Rather than pollute this forum, they are on pastebin.com in case they give anyone any insights. I checked, and am connected, but it's ugly, if repetitive.
which means incorrect/invalid locale settings (or something similar), but it is just the logging.
Otherwise you can see lines beginning with Message:{SNIPPED!}
Bang on, @pan64 & thanks for the reply. I ran the line
Code:
root@Ebony:~# protonvpn connect --cc ie 2>/dev/null
ProtonVPN now offers an official Linux app which includes a graphical user interface.
Visit https://protonvpn.com/support/official-linux-client to upgrade.
There is already a VPN connection running.
Terminating previous connection...
Connecting to IE#3 via UDP...
Connected!
and it connected normally. The funny thing, when the init scripts are running, the protonvpn output is fairly normal
So it is logging errors only, and not function. I then compared the user & root environments, went through /etc/environment (but everything is set elsewhere), /etc/profile & /etc/profile.d/ to no avail. I'm on en_IE@euro and the Europe/Dublin timezone, which was no issue before. Yet I see that error with "\u2014" as well. Just in case I'm missing the obvious, here's root's printenv o/p. I unset $LS_COLORS because it reads some lengthy file in which has nothing to do with this issue.
$LC_ALL is unset, but I set it to "en_IE@euro", and "C" and things behaved no better. /var/log/messages just logs creating tun0 (=proton0) when the vpn is booted, /var/log/syslog logs nothing. On bootup, the protonvpn output that I see looks clean, and doesn't throw errors. But if I re-run it later, it's the usual mess. What is character 'u\2014' anyhow?
Weird. I'm presuming the python code doesn't have it, and English doesn't use it. Russian does use it, and some derivitative languages may do also. I even took it out of my hacked keyboard file, it’s not in the configs. It seems to be a shortcoming in python’s charmap, wherever that comes from. But I have no clue why it's trying to interpret it.
> What is character 'u\2014' anyhow?
Unicode. What encoding is your python using by default? '\u2014' is a 16 bit hex value.
Thanks for the reply. Yes, u\2014=emdash, an overly long hyphen. It's all part of this vast spew of error messages which I am piping to /dev/null, atm. It's not a solution I like, but I can't do much else. Python3.9.x worked fine, python3.11.x throws a major hissy fit, but actually works for connect and disconnect commands. That's about the last thing I thought was happening.
I don't know if this is a python3.11 bug, or protonvpn-cli bug. I suspect python3.11.x because protonvpn are a Swiss outfit, and are surrounded by Unicode. The pastebin output from post #16 (all 70k of it) shows what I'm seeing. I have a protonvpn issue open, so I'll update that.
No, it is definitely not a python bug, but an incorrect setup/env. Most probably encoding is not set properly. In post #21 you can see it works. Python is not responsible for the encoding you set and the text you want to handle (containing whatever is inside).
No, it is definitely not a python bug, but an incorrect setup/env. Most probably encoding is not set properly. In post #21 you can see it works. Python is not responsible for the encoding you set and the text you want to handle (containing whatever is inside).
Nice try, but I'm on Slackware and the approach is very different. Slackware is a distro from the early days. Slackware installs all the common locales and they just percolate down once you set them. My fairly bare slackware install here is 26G. Debian, by contrast installs only about 6G.
I guess there would be no problem with 'en_IE.utf8'.
Yep, because en_IE@euro locale uses ISO-8859-15 encoding which can't handle Unicode symbol EM DASH:
Code:
$ LANG=en_IE@euro python
>>> print('\u2014')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib64/python3.11/encodings/iso8859_15.py", line 19, in encode
return codecs.charmap_encode(input,self.errors,encoding_table)[0]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
UnicodeEncodeError: 'charmap' codec can't encode character '\u2014' in position 0: character maps to <undefined>
Need to use locale with UTF-8 encoding for that to work.
Thanks for the continued interest in this thread, guys.
Quote:
Originally Posted by Petri Kaukasoina
I guess there would be no problem with 'en_IE.utf8'.
Brilliant. There isn't, and I never appreciated the difference. That solves all of the log spam. I tried all the suggestions, and you can see the results in the terminal o/p below.
Code:
dec@Ebony:~$ locale
LANG=en_IE.utf8
LC_CTYPE="en_IE.utf8"
LC_NUMERIC="en_IE.utf8"
LC_TIME="en_IE.utf8"
LC_COLLATE=C
LC_MONETARY="en_IE.utf8"
LC_MESSAGES="en_IE.utf8"
LC_PAPER="en_IE.utf8"
LC_NAME="en_IE.utf8"
LC_ADDRESS="en_IE.utf8"
LC_TELEPHONE="en_IE.utf8"
LC_MEASUREMENT="en_IE.utf8"
LC_IDENTIFICATION="en_IE.utf8"
LC_ALL=
dec@Ebony:~$ su -
Password:
-su: export: `1': not a valid identifier
root@Ebony:~# protonvpn status
ProtonVPN now offers an official Linux app which includes a graphical user interface.
Visit https://protonvpn.com/support/official-linux-client to upgrade.
Traceback (most recent call last):
File "/usr/bin/protonvpn", line 33, in <module>
sys.exit(load_entry_point('protonvpn-cli==2.2.12', 'console_scripts', 'protonvpn')())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/protonvpn_cli/cli.py", line 72, in main
cli()
File "/usr/lib/python3.11/site-packages/protonvpn_cli/cli.py", line 144, in cli
connection.status()
File "/usr/lib/python3.11/site-packages/protonvpn_cli/connection.py", line 444, in status
+ "Features: {0}\n".format(all_features[feature])
~~~~~~~~~~~~^^^^^^^^^
KeyError: 8
root@Ebony:~# python -c 'import sys; print(sys.getdefaultencoding())'
utf-8
root@Ebony:~# python -c 'import sys; print(sys.stdin.encoding, sys.stdout.encoding)'
utf-8 utf-8
root@Ebony:~# LANG=en_IE@euro
root@Ebony:~# python -c 'import sys; print(sys.getdefaultencoding())'
utf-8
root@Ebony:~# python -c 'import sys; print(sys.stdin.encoding, sys.stdout.encoding)'
iso8859-15 iso8859-15
root@Ebony:~# LANG-en_IE.utf-8
-su: LANG-en_IE.utf-8: command not found
root@Ebony:~# LANG=en_IE.utf-8
root@Ebony:~# python -c 'import sys; print(sys.getdefaultencoding())'
utf-8
root@Ebony:~# python -c 'import sys; print(sys.stdin.encoding, sys.stdout.encoding)'
utf-8 utf-8
root@Ebony:~#
The error on the 'protonvpn status' command happens only under X. If I hit 'Ctrl_Alt_F3' and open a root console there, no such error occurs The init scripts all run in runlevel 3 anyhow, so everything behaves cleanly. I also discovered the hard way that "2 > /dev/null" throws errors, but '2> /dev/null' does not.
@tekk: Thanks for the test lines. As the $LANG variable set in /etc/profile.d/lang.sh sets all the other $LC_* variables, I feel the 'utf-8' which I coloured in red would be gone at the next reboot. I only set the old value in one terminal, which didn't affect any other setting.
I'm now only left with the error on the 'protonvpn status' command, which occurs under X only. I also have that nutty "-su: export: `1': not a valid identifier" thing. It occurs for users and root. Every environment variable exported seems well formed.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
The init scripts all run in runlevel 3 anyhow, so everything behaves cleanly. I also discovered the hard way that "2 > /dev/null" throws errors, but '2> /dev/null' does not. 
