[opensuse-factory] Yast (and some console programs) not correctly displaying
From my point of view this can only come from a poor usage of ncurses, if it would nbe ncurses itself, my programs would also have troubles (but they don't). Perhaps there is another layer of software on top of ncurses and that one is not correctly written? Or are this tools not using ncurses and doing everything "manually"? -> This is a many years persisting issue and shows that even Leap (many years after UTF8 introduction) is not tested well in this
Hello. I do not want to start a discussion here about advantages/disadvantages of one or the other encoding (ISO-8859-1, UTF8, ...) and/or why I should use UTF8. I have good reasons why I don't want to do that and stay with ISO-8859-1, and it also is a question of principle that an OS and all its programs have to correctly (and not mostly) support them. Linux is offering a huge number of different encodings and should be aware of correctly supporting all of them, as it did before UTF8. If not, it is a question of careless coding or implementation. I use still ISO-8859-1 on all of my servers and workstations because of several reasons (and I do not want to change something in this point). Most of my self-written programs are based on ncurses, using the fuill set of features (also windows and window layers). All of the, are working perfectly and are displaying correctly, so I am pretty sure that ncurses and all related libs _are_ correct. So what? I see that many programs (i.e. YaSt in textmode, but also several other tools) are not correctly displaying, they show sometimes 2-Byte characters and distort hereby the output. This happens more on real text screens (i.e. Ctrl-Alt-F1 console) and is slightly better in a graphical "konsole" of KDE, but it happens. point and/or fixed. I watch this phenomen since UTF8 came out. Because I do remote administration often in text mode (ssh or in a few cases even by modem dial in), a properly working handling of encodings has to work. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 18/01/2019 08.17, Rainer Hantsch wrote:
Hello.
I do not want to start a discussion here about advantages/disadvantages of one or the other encoding (ISO-8859-1, UTF8, ...) and/or why I should use UTF8. I have good reasons why I don't want to do that and stay with ISO-8859-1, and it also is a question of principle that an OS and all its programs have to correctly (and not mostly) support them. Linux is offering a huge number of different encodings and should be aware of correctly supporting all of them, as it did before UTF8. If not, it is a question of careless coding or implementation.
I use still ISO-8859-1 on all of my servers and workstations because of several reasons (and I do not want to change something in this point). Most of my self-written programs are based on ncurses, using the fuill set of features (also windows and window layers). All of the, are working perfectly and are displaying correctly, so I am pretty sure that ncurses and all related libs _are_ correct.
So what? I see that many programs (i.e. YaSt in textmode, but also several other tools) are not correctly displaying, they show sometimes 2-Byte characters and distort hereby the output. This happens more on real text screens (i.e. Ctrl-Alt-F1 console) and is slightly better in a graphical "konsole" of KDE, but it happens. From my point of view this can only come from a poor usage of ncurses, if it would nbe ncurses itself, my programs would also have troubles (but they don't). Perhaps there is another layer of software on top of ncurses and that one is not correctly written? Or are this tools not using ncurses and doing everything "manually"? -> This is a many years persisting issue and shows that even Leap (many years after UTF8 introduction) is not tested well in this point and/or fixed.
I watch this phenomen since UTF8 came out. Because I do remote administration often in text mode (ssh or in a few cases even by modem dial in), a properly working handling of encodings has to work.
What could be a reason is that the YaST programs use https://github.com/libyui e.g. https://github.com/libyui/libyui-ncurses and not ncurses directly. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello Oliver. Thank you for this very quick answer. Am Freitag, 18. Jan 2019, 08:21:43 schrieb Oliver Kurz:
On 18/01/2019 08.17, Rainer Hantsch wrote:
I watch this phenomen since UTF8 came out. Because I do remote administration often in text mode (ssh or in a few cases even by modem dial in), a properly working handling of encodings has to work.
What could be a reason is that the YaST programs use https://github.com/libyui e.g. https://github.com/libyui/libyui-ncurses and not ncurses directly.
I already thought that such thing with some kind of overlaying software might be the reason. So the problem can now be... a.) A fault in this overlaying toolbox b.) An incorrect use of this toolbox. As I am no developer and it exceeds my knowledge to reverse-engineer YaST and/or libyui (I program only in FreePascal), I can only tell that something is not working properly. Those people developing libyui and YaST can check their software much quicker and reliably than I ever could. I am pretty sure that several tools in openSUSE will use libyui-ncurses, otherwise it would not have been mentioned on github: "... Libyui is a widget abstraction library providing Qt, GTK and ncurses frontends. Originally it was developed for YaST but it can be used in any independent project. ..." It appears to me that this libyui-ncurses is much more likely the reason in this case. This would explain why other programs also have sometimes displaying issues. But it also might be the case that in some lines of code this libgui-ncurses is not correctly used (i.e. a somewhere forgotten string-conversion between different codesets). This should be fixed anyways. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2019-01-18 08:39, Rainer Hantsch wrote:
On 18/01/2019 08.17, Rainer Hantsch wrote:
I do not want to start a discussion here about advantages/disadvantages of one or the other encoding (ISO-8859-1, UTF8, ...) and/or why I should use UTF8. I have good reasons why I don't want to do that and stay with ISO-8859-1, and
I watch this phenomen since UTF8 came out. Because I do remote administration often in text mode (ssh or in a few cases even by modem dial in), a properly working handling of encodings has to work. [...]
[yast] This should be fixed
So should your local encoding. But we already know *that's* not going to happen.. Mexican standoff. For as long as we "should" do something, I'll point out a thing you "should" be doing. ------- To interested people wanting to debug: * start putty native on openSUSE (this is set to UTF-8), ssh to localhost, run "hte" — mc and yast are fine —, observe. * start putty.exe on openSUSE through wine (this defaults to ISO IIRC), ssh to localhost, run hte or yast — mc is fine —, observe. * hte on xterm directly is fine.. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
[yast] This should be fixed
So should your local encoding. But we already know *that's* not going to happen..
I've seen yast with the block-drawing characters replaced by two other characters (with at least one non-ASCII character) on occasions and did not change the encoding. This wasn't even remote but on the console. It always was when I had no time to investigate and/or file a bug report. If I remember right, navigation didn't work, or at least it was not possible to see what menu entry is highlighted. My workaround was to only switch the system target from "graphical interface" to "multi-user system" after running online updates. I don't remember whether this was in 42.2, 42.3 or 15.0. Joachim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Freitag, 18. Jan 2019, 08:43:13 schrieb Joachim Wagner:
[yast] This should be fixed
So should your local encoding. But we already know *that's* not going to happen..
I've seen yast with the block-drawing characters replaced by two other characters (with at least one non-ASCII character) on occasions and did not change the encoding. This wasn't even remote but on the console. It always was when I had no time to investigate and/or file a bug report.
If I remember right, navigation didn't work, or at least it was not possible to see what menu entry is highlighted. My workaround was to only switch the system target from "graphical interface" to "multi-user system" after running online updates. I don't remember whether this was in 42.2, 42.3 or 15.0.
Joachim
Joachim, you are talking of 42.x,? The problem exists since UTF8 came out. Don't know if it was SuSE 7/8/9/10, but this is at least 6-7 years ago, if not more. At that time I started pointing out this problems, The solution coming from SuSE (or was it meanwhile Novell?) was simple: The entire issue was simply *ignored*. Sad to say, but this is not the first and only case that this "way of solution" happened. So I primarily give it a new try in Leap 15 times (meanwhile enough time is gone, I assume) and I am very interested to watch what happens now, many years later. :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
you are talking of 42.x,? The problem exists since UTF8 came out.
It was less than 3 years ago, probably less than 2. Considering that you report this problem for when you switch the encoding and I didn't switch it, I suspect that I got the problem when I chose "Server" instead of "Desktop with KDE" in the installer and that the "Server" profile doesn't set an UTF-8 locale (which is reasonable for a server). (Reading https://en.opensuse.org/SDB:Plain_Text_versus_Locale Johannes pointed to in the other thread, it probably is set to "POSIX".) Joachim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
[...] I suspect that I got the problem when I chose "Server" instead of "Desktop with KDE" in the installer and that the "Server" profile doesn't set an UTF-8 locale (which is reasonable for a server).
Negative. I just tried default server installs with 15.0 and 42.3 without updates in a VM and yast is fine on the console. Searching for LC, en_, ISO and UTF in `env` I only see LC_CTYPE=en_US.UTF-8. If I change this variable to POSIX (export LC_CTYPE=POSIX), yast is still fine. Joachim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Freitag, 18. Jan 2019, 16:24:46 schrieb Joachim Wagner:
[...] I suspect that I got the problem when I chose "Server" instead of "Desktop with KDE" in the installer and that the "Server" profile doesn't set an UTF-8 locale (which is reasonable for a server).
Negative. I just tried default server installs with 15.0 and 42.3 without updates in a VM and yast is fine on the console. Searching for LC, en_, ISO and UTF in `env` I only see LC_CTYPE=en_US.UTF-8.
If I change this variable to POSIX (export LC_CTYPE=POSIX), yast is still fine.
Joachim
Sorry, but it appears here totally different, even when using a SSH connection (and in this case it is usually better). My local machine: openSUSE 13.2 x64, KDE, konsole window opened rainer@majestix:~> locale LANG=de_DE@euro LC_CTYPE="de_DE@euro" LC_NUMERIC="de_DE@euro" LC_TIME="de_DE@euro" LC_COLLATE="de_DE@euro" LC_MONETARY="de_DE@euro" LC_MESSAGES="de_DE@euro" LC_PAPER="de_DE@euro" LC_NAME="de_DE@euro" LC_ADDRESS="de_DE@euro" LC_TELEPHONE="de_DE@euro" LC_MEASUREMENT="de_DE@euro" LC_IDENTIFICATION="de_DE@euro" LC_ALL= rainer@majestix:~> -------- Now I do a ssh to my friend's server (also acting as firewall): openSUSE 42.2 (x86_64) idefix:~ # locale LANG=de_DE@euro LC_CTYPE="de_DE@euro" LC_NUMERIC="de_DE@euro" LC_TIME="de_DE@euro" LC_COLLATE="de_DE@euro" LC_MONETARY="de_DE@euro" LC_MESSAGES="de_DE@euro" LC_PAPER="de_DE@euro" LC_NAME="de_DE@euro" LC_ADDRESS="de_DE@euro" LC_TELEPHONE="de_DE@euro" LC_MEASUREMENT="de_DE@euro" LC_IDENTIFICATION="de_DE@euro" LC_ALL= The machine is actually configured to locally use UTF-8, but I login from my iso-8859-1 machine, therefore I see here (again) thew same locale settings. I can open YaST and everything is fine (as it is no local physical console). I see nothing wrong in main window and also in any sub-window (when opening i.e. System / Services. See this screenshots: www.hantsch.co.at/_temp/Snap140.jpg www.hantsch.co.at/_temp/Snap141.jpg (A sub-module) -------------- Now I do another SSH from this machine to a client machine behind it (in LAN) by another SSH to that machine: cat /etc/os-release shows: openSUSE Leap 15.0 , KDE. ... norbert:~ # locale LANG=de_DE@euro LC_CTYPE="de_DE@euro" LC_NUMERIC="de_DE@euro" LC_TIME="de_DE@euro" LC_COLLATE="de_DE@euro" LC_MONETARY="de_DE@euro" LC_MESSAGES="de_DE@euro" LC_PAPER="de_DE@euro" LC_NAME="de_DE@euro" LC_ADDRESS="de_DE@euro" LC_TELEPHONE="de_DE@euro" LC_MEASUREMENT="de_DE@euro" LC_IDENTIFICATION="de_DE@euro" LC_ALL= And now I execute again 'yast' (so this is again the textmode version). Here is are link to screenshots of what I get now (same windows of yast): www.hantsch.co.at/_temp/Snap138.jpg www.hantsch.co.at/_temp/Snap139.jpg (A sub-module) --------------- Looks a "little bit" different. -- mit freundlichen Grüßen Ing. Rainer Hantsch (Firmeninhaber) -- ------------------------------------------------- ING. RAINER HANTSCH - Hardware & Software Khunngasse 21/20 A-1030 Wien *** Austria *** Tel.: +43-1-7988538-0 Fax : +43-1-7988538-18 Mobil: +43-664-9194382 UID-Nr: ATU11134002 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 18/01/2019 18.13, Rainer Hantsch wrote:
Am Freitag, 18. Jan 2019, 16:24:46 schrieb Joachim Wagner:
...
Now I do a ssh to my friend's server (also acting as firewall): openSUSE 42.2 (x86_64)
idefix:~ # locale LANG=de_DE@euro LC_CTYPE="de_DE@euro" LC_NUMERIC="de_DE@euro" LC_TIME="de_DE@euro" LC_COLLATE="de_DE@euro" LC_MONETARY="de_DE@euro" LC_MESSAGES="de_DE@euro" LC_PAPER="de_DE@euro" LC_NAME="de_DE@euro" LC_ADDRESS="de_DE@euro" LC_TELEPHONE="de_DE@euro" LC_MEASUREMENT="de_DE@euro" LC_IDENTIFICATION="de_DE@euro" LC_ALL=
The machine is actually configured to locally use UTF-8, but I login from my iso-8859-1 machine, therefore I see here (again) thew same locale settings.
You can tell your ssh to use the remote locale instead of yours. I think it is this: /etc/ssh/ssh_config #CER - remove to pass the locale # This enables sending locale enviroment variables LC_* LANG, see ssh_config(5). # SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES # SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT # SendEnv LC_IDENTIFICATION LC_ALL -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Am Freitag, 18. Jan 2019, 16:24:46 schrieb Joachim Wagner:
And now I execute again 'yast' (so this is again the textmode version). Here is are link to screenshots of what I get now (same windows of yast): www.hantsch.co.at/_temp/Snap138.jpg www.hantsch.co.at/_temp/Snap139.jpg (A sub-module)
The problem on these screenshots doesn't look like it's related to the locale at all. It's likely rather this I think: https://bugzilla.opensuse.org/1054448 https://bugzilla.opensuse.org/1056020 https://bugs.kde.org/384620 In short, recent ncurses versions use the RPT control sequence to repeat characters when $TERM is set to "xterm". But older konsole versions didn't support that. As a workaround, set TERM to e.g. "konsole" or "linux", you can change that in konsole's profile settings or manually with "export TERM=xxx". Or use xterm, which supports RPT since something like 20 years... If you're inclined to, it should be easy to backport the fix to older konsole versions too: https://phabricator.kde.org/D10064 Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
This I only wanted to show you because it was so distorted. Sorry to say, but my setting is everywhere »TERM="xterm"«, also on my openSUSE 13.2 x64 (I am working on.) I entered now this two commands LOCALLY (in Konsole of KDE, configured to use xfree4): export TERM="linux" yast Yast pops up with this appearance (see Link below). www.hantsch.co.at/_temp/Snap142.jpg <-- "Wonderful" borders So this must be another "silent change" between 42.3 and 15.0 deep inside. I cannot imagine that Leap 42.3 didn't use RPT while Leap 15 does? So I found another issue with Yast. (rofl) #1: Why was -> System -> Language -> Detail "Locale-Settings for user root" removed from Yast? Should be re-inserted. There is absolutely no reason for removing it, it only forces users to namually edit /etc/sysconfig/language. #2: I don't know what has changed from 42.3 -> 15.0. If 42.3 didn't use RPT, it would be smart to stick with that. Compatibility is often of higher value than saving a few milliseconds by using "RPT". Or add a setting to YaST to enable/disable using of RPT. ------------- But this has nothing to do with my iso-8859-x <--> utf8 problem. sometimes I watch that lines show 2-byte characters (as an UTF-8 char shows up in a 8-bit only terminal). This is not easily to reproduce, but I will look carefully and report where I saw that when it happens again. I use always the settings »ROOT_USES_LANG="yes"«, because I prefer everything being in German language, also when logged in as root. :) Am Samstag, 19. Jan 2019, 09:36:58 schrieb Wolfgang Bauer:
Am Freitag, 18. Jan 2019, 16:24:46 schrieb Joachim Wagner:
And now I execute again 'yast' (so this is again the textmode version). Here is are link to screenshots of what I get now (same windows of yast): www.hantsch.co.at/_temp/Snap138.jpg www.hantsch.co.at/_temp/Snap139.jpg (A sub-module)
The problem on these screenshots doesn't look like it's related to the locale at all. It's likely rather this I think: https://bugzilla.opensuse.org/1054448 https://bugzilla.opensuse.org/1056020 https://bugs.kde.org/384620
In short, recent ncurses versions use the RPT control sequence to repeat characters when $TERM is set to "xterm". But older konsole versions didn't support that.
As a workaround, set TERM to e.g. "konsole" or "linux", you can change that in konsole's profile settings or manually with "export TERM=xxx". Or use xterm, which supports RPT since something like 20 years...
If you're inclined to, it should be easy to backport the fix to older konsole versions too: https://phabricator.kde.org/D10064
Kind Regards, Wolfgang
Kind Regards, Rainer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday, January 19, 2019 10:28 AM Rainer Hantsch wrote:
Sorry to say, but my setting is everywhere >TERM="xterm"<, also on my openSUSE 13.2 x64 (I am working on.)
And that's exactly the problem, because that causes newer ncurses to use the REP sequence. (it's called REP not RPT, sorry for my mistake)
I entered now this two commands LOCALLY (in Konsole of KDE, configured to use xfree4):
xfree4 is the keyboard layout, the $TERM is set in the environment settings IIRC (can't check at the moment).
Yast pops up with this appearance (see Link below). www.hantsch.co.at/_temp/Snap142.jpg <-- "Wonderful" borders
See? ;-)
So this must be another "silent change" between 42.3 and 15.0 deep inside. I cannot imagine that Leap 42.3 didn't use RPT while Leap 15 does?
But that's how it is. Ncurses on Leap 42.3 doesn't use REP, while the version in Leap 15.0 does with $TERM=xterm (on 8-bit locales at least, as apparently xterm doesn't support it with UTF-8...). Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday, January 19, 2019 11:28 AM Wolfgang Bauer wrote:
Yast pops up with this appearance (see Link below). www.hantsch.co.at/_temp/Snap142.jpg <-- "Wonderful" borders
See? ;-)
Erm, I meant that the character repetition is fine now. The strange characters do look like a Latin<->UTF-8 problem now though... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
19.01.2019 13:32, Wolfgang Bauer пишет:
On Saturday, January 19, 2019 11:28 AM Wolfgang Bauer wrote:
Yast pops up with this appearance (see Link below). www.hantsch.co.at/_temp/Snap142.jpg <-- "Wonderful" borders
See? ;-)
Erm, I meant that the character repetition is fine now.
The strange characters do look like a Latin<->UTF-8 problem now though...
As it is not observed using other terminals (xterm, linux console) it looks more like konsole specific issue. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday, January 19, 2019 12:33 PM Andrei Borzenkov wrote:
As it is not observed using other terminals (xterm, linux console) it looks more like konsole specific issue.
Indeed. That's why I suggested to try xterm as workaround too. And it's a very old version as well... (both konsole and openSUSE, 13.2 is out of support since two years now already) Or maybe it's related to TERM=linux and e.g. TERM=konsole or TERM=xterm-color would work better? I'm not sure if that can play a role here though. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Samstag, 19. Jan 2019, 13:32:44 schrieb Wolfgang Bauer:
On Saturday, January 19, 2019 12:33 PM Andrei Borzenkov wrote:
As it is not observed using other terminals (xterm, linux console) it looks more like konsole specific issue.
Indeed.
That's why I suggested to try xterm as workaround too.
And it's a very old version as well... (both konsole and openSUSE, 13.2 is out of support since two years now already)
I can't stop laughing. Ever heared of STANDARDS to be kept? I can tell you (and confirm) that everything works perfectly in this point up to and *including* Leap 42.3.
Or maybe it's related to TERM=linux and e.g. TERM=konsole or TERM=xterm-color would work better? I'm not sure if that can play a role here though.
Kind Regards, Wolfgang
I have no idea what was changed here. I guess someone set himself a new monument and changed something in Yast in Leap 15. The list of _reasonless_ changes from 42.3 -> 15.0 fills meanwhile 2 pages. Changes over changes, often causing difficulties. Leap 15 is really running fast and well (when you get it installed and running), but I can only shake my head about several changes.4 Cheers. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Rainer, Am 19.01.19 um 13:53 schrieb Rainer Hantsch:
Am Samstag, 19. Jan 2019, 13:32:44 schrieb Wolfgang Bauer:
On Saturday, January 19, 2019 12:33 PM Andrei Borzenkov wrote:
As it is not observed using other terminals (xterm, linux console) it looks more like konsole specific issue.
Indeed.
That's why I suggested to try xterm as workaround too.
And it's a very old version as well... (both konsole and openSUSE, 13.2 is out of support since two years now already)
I can't stop laughing. Ever heared of STANDARDS to be kept?
Ever heard of bugs in software? But bugs in openSUSE 13.2 konsole are not likely to get fixed.
I can tell you (and confirm) that everything works perfectly in this point up to and *including* Leap 42.3.
Or maybe it's related to TERM=linux and e.g. TERM=konsole or TERM=xterm-color would work better? I'm not sure if that can play a role here though.
Kind Regards, Wolfgang
I have no idea what was changed here.
And you are not willing to help fix the issues.
I guess someone set himself a new monument and changed something in Yast in Leap 15. The list of _reasonless_ changes from 42.3 -> 15.0 fills meanwhile 2 pages. Changes over changes, often causing difficulties. Leap 15 is really running fast and well (when you get it installed and running), but I can only shake my head about several changes.4
Insulting the people that might be able to help you looks like a suboptimal tactic. Just go and set up some reasonable bounties on bountysource.com for your problems, then maybe someone will wade through your rants and produce fixes for you. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Samstag, 19. Jan 2019, 14:44:58 schrieb Stefan Seyfried:
Ever heard of bugs in software? But bugs in openSUSE 13.2 konsole are not likely to get fixed.
And who sais that teh bug is in 13.2? You know that, right? So explain me, why starts this bug to exist with Leap 15, while it did not exist will ALL RELEASES OF OPENSUSE before ?????
I have no idea what was changed here.
And you are not willing to help fix the issues.
Sorry. Now it starts to become bit strange. If I buy a car, I do not have to be able to know it in every particular detail or to be a mechanic specialist to USE IT. But I am still able to tell the mechanic what is not working as before. The mechanic has the knowledge to find out the reason and to fix it, not me. I hope you can find some analogy by yourself? I am a user and can only try to show what is different. I do not have the background of a developer.
I guess someone set himself a new monument and changed something in Yast in Leap 15. The list of _reasonless_ changes from 42.3 -> 15.0 fills meanwhile 2 pages. Changes over changes, often causing difficulties. Leap 15 is really running fast and well (when you get it installed and running), but I can only shake my head about several changes.4
Insulting the people that might be able to help you looks like a suboptimal tactic.
I am far away from insulting people. Perhaps I translated too hard from german speaking - I apologize if I insulted somebody. If I wanted to insult somebody, it would sound a lot different. :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 19 Jan 2019 at 15:00, Rainer Hantsch <office@hantsch.co.at> wrote:
If I buy a car, I do not have to be able to know it in every particular detail or to be a mechanic specialist to USE IT. But I am still able to tell the mechanic what is not working as before. The mechanic has the knowledge to find out the reason and to fix it, not me.
I hope you can find some analogy by yourself? I am a user and can only try to show what is different. I do not have the background of a developer.
Your analogy is fundamentally flawed You did not _buy_ anything.You downloaded _for free_ something which is produced, developed, and distributed by _volunteers_ working in their _spare time_ You then entered a mailinglist intended for the volunteering developers as part of that Project and have repeatedly made your demands. Your repeated posts on this mailinglist have, in my eyes, the following issues - Many of them are arguably off-topic, as they are related to issues which you personally have with your systems, due to choices you have made which run counter to that which the vast majority of this community supports. I would recommend any conversation which could be described in this manner is best served by our opensuse-support@ mailinglist or our forums. This mailinglist is primarily intended for openSUSE developers, to discuss the development of future versions of openSUSE. This purpose of this list is well documented [1][2][3] - The tone of your emails most certainly convey an assumption that the openSUSE project somehow owes you something or should undoubtedly do what you tell them to do. As openSUSE is an organisation driven by voluntary contributions, I can assure you that approaching anything in the openSUSE Project in such a manner will not have positive results. - Many contributors have tried sincerely to give you feedback about why many of your assumptions are wrong (for example, the reality of UTF8's dominance in the world, and the fallacy that a kernel in one distribution having ANY relation to the kernel in Leap, when Leap has hundreds if not thousands of backported patches). You have ignored that feedback, and instead repeatedly dug your heels in and repeated your demands in a way that leads me to think that you believe we should do exactly what you tell us to do. To give you a more apt analogy than your original one If I visit a charity soup kitchen providing free soup, and started shouting how their soup tasted terrible and demanding that they cook me a 4 course meal, I am likely to find myself either kicked out, or if I'm lucky, served soup (and if I'm really lucky, the volunteers wont spit in my soup). Welcome to the openSUSE Project. Enjoy our soup. You're welcome to help us make it better. But your disruptive shouting and demands do not help that, and you are starting to not only annoy our kitchen staff, but the other people waiting in line for soup. Regards, Richard Brown Head Chef [1] https://lists.opensuse.org/ ("Discussions about the development of the openSUSE distributions. (Bug reports => Bugzilla, Support => User/Support lists!)") [2] https://en.opensuse.org/openSUSE:Communication_channels ("This is the list for technical discussions related to the development of the openSUSE Distributions") [3] https://en.opensuse.org/Portal:Factory -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday, January 19, 2019 1:53 PM Rainer Hantsch wrote:
Or maybe it's related to TERM=linux and e.g. TERM=konsole or TERM=xterm-color would work better? I'm not sure if that can play a role here though.
Kind Regards, Wolfgang
I have no idea what was changed here.
I guess someone set himself a new monument and changed something in Yast in Leap 15.
One thing that definitely changed is that ncurses now uses REP if TERM=xterm, as explained. That's an upstream change in ncurses btw, nothing (open)SUSE specific (so you would have the same problems connecting to a different recent Linux system). And it's not specific to YaST either, it should affect all applications that use ncurses. That's not even about STANDARDS though. The "xterm" terminfo entry describes the capabilities of xterm (obviously), other terminals/emulators may not necessarily support the same features. And TERM=linux describes the Linux console (I think), and not *k*onsole. On your screenshots to which I referred to, one can only see the REP problem. The characters themselves are rendered correctly (just not repeated). And the only change now was that you set TERM=linux... I can build you a 13.2 konsole with REP support patched in if you want, maybe that would work fine for you then... (with TERM=xterm) Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Wolfgang. Thank you very much for this offer. I highly appreciate to you. My system is openSUSE 13.2 x64, with KDE. I will be happy to test it and also give you feedback. Is this only replacing one particular executable, or is it more? (in case it makes troubles, I need to be able to switch back (otherwise I cannot operate my invoicing software). Am Samstag, 19. Jan 2019, 15:19:17 schrieb Wolfgang Bauer:
On Saturday, January 19, 2019 1:53 PM Rainer Hantsch wrote:
Or maybe it's related to TERM=linux and e.g. TERM=konsole or TERM=xterm-color would work better? I'm not sure if that can play a role here though.
Kind Regards, Wolfgang
I have no idea what was changed here.
I guess someone set himself a new monument and changed something in Yast in Leap 15.
One thing that definitely changed is that ncurses now uses REP if TERM=xterm, as explained. That's an upstream change in ncurses btw, nothing (open)SUSE specific (so you would have the same problems connecting to a different recent Linux system). And it's not specific to YaST either, it should affect all applications that use ncurses.
That's not even about STANDARDS though. The "xterm" terminfo entry describes the capabilities of xterm (obviously), other terminals/emulators may not necessarily support the same features. And TERM=linux describes the Linux console (I think), and not *k*onsole.
On your screenshots to which I referred to, one can only see the REP problem. The characters themselves are rendered correctly (just not repeated). And the only change now was that you set TERM=linux...
I can build you a 13.2 konsole with REP support patched in if you want, maybe that would work fine for you then... (with TERM=xterm)
Kind Regards, Wolfgang
-- mit freundlichen Grüßen Ing. Rainer Hantsch (Firmeninhaber) -- ------------------------------------------------- ING. RAINER HANTSCH - Hardware & Software Khunngasse 21/20 A-1030 Wien *** Austria *** Tel.: +43-1-7988538-0 Fax : +43-1-7988538-18 Mobil: +43-664-9194382 UID-Nr: ATU11134002 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday, January 19, 2019 3:29 PM Rainer Hantsch wrote:
I will be happy to test it and also give you feedback. Is this only replacing one particular executable, or is it more?
It will replace one particular package on your system, namely konsole. Shouldn't affect anything else, and it should work fine. The package is available here meanwhile: https://download.opensuse.org/repositories/home:/wolfi323:/konsole_with_REP/ openSUSE_13.2 Add this as repo with YaST or zypper, and switch the konsole package to the one from that repo. E.g. by clicking on "Switch system packages" in YaST, or choosing it in YaST's "Versions" tab, or via "zypper dup --from repo". See also https://en.opensuse.org/SDB:Vendor_change_update You can of course also download the appropriate .rpm file manually and install it with rpm. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 1/19/19 10:27 AM, Rainer Hantsch wrote:
[...]
#1: Why was -> System -> Language -> Detail "Locale-Settings for user root" removed from Yast? Should be re-inserted. There is absolutely no reason for removing it, it only forces users to namually edit /etc/sysconfig/language.
You seem to assume that YaST developers enjoy removing functionality just for the fun of it. I did a little bit of research and it looks like that option was removed as part of a needed adaptation to systemd. Unfortunately, systemd has changed a lot how the locale management works. Adapting YaST to it may have consequences that are not obvious to everybody at first glance. Which is quite different from "absolutely no reason for removing it". Sometimes (not always), things can be re-engineered to find a way to bring some old functionality back, but in a way that is systemd-compliant and avoids side effects. Unfortunately, that's more complex than "should be re-inserted". For further reference, this is the change in Github: https://github.com/yast/yast-country/pull/149 Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 21/01/2019 10.48, Ancor Gonzalez Sosa wrote:
On 1/19/19 10:27 AM, Rainer Hantsch wrote:
[...]
#1: Why was -> System -> Language -> Detail "Locale-Settings for user root" removed from Yast? Should be re-inserted. There is absolutely no reason for removing it, it only forces users to namually edit /etc/sysconfig/language.
You seem to assume that YaST developers enjoy removing functionality just for the fun of it.
I did a little bit of research and it looks like that option was removed as part of a needed adaptation to systemd. Unfortunately, systemd has changed a lot how the locale management works. Adapting YaST to it may have consequences that are not obvious to everybody at first glance. Which is quite different from "absolutely no reason for removing it".
Ok, but you see, we have no way to know unless you tell us in the release notes, for instance. I had not noticed the change in YaST, because I don't change root's locale. I see in "/etc/sysconfig/language" for 15.0 this paragraph: # This defines if the user "root" should use the locale settings # which are defined here. # Value "ctype" means that root uses just LC_CTYPE. # Value "yes" means that root uses the full settings.. # ROOT_USES_LANG="ctype" If the variable is there, why can't YaST touch it? Why is this affected by systemd? I'm not complaining, but I simply do not understand. Maybe YaST did something more than change that variable, or maybe the variable is also ignored.
Sometimes (not always), things can be re-engineered to find a way to bring some old functionality back, but in a way that is systemd-compliant and avoids side effects. Unfortunately, that's more complex than "should be re-inserted".
For further reference, this is the change in Github: https://github.com/yast/yast-country/pull/149
Huh. That's like greek to me, sorry. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 1/21/19 12:07 PM, Carlos E. R. wrote:
On 21/01/2019 10.48, Ancor Gonzalez Sosa wrote:
On 1/19/19 10:27 AM, Rainer Hantsch wrote:
[...]
#1: Why was -> System -> Language -> Detail "Locale-Settings for user root" removed from Yast? Should be re-inserted. There is absolutely no reason for removing it, it only forces users to namually edit /etc/sysconfig/language.
You seem to assume that YaST developers enjoy removing functionality just for the fun of it.
I did a little bit of research and it looks like that option was removed as part of a needed adaptation to systemd. Unfortunately, systemd has changed a lot how the locale management works. Adapting YaST to it may have consequences that are not obvious to everybody at first glance. Which is quite different from "absolutely no reason for removing it".
Ok, but you see, we have no way to know unless you tell us in the release notes, for instance.
There are 10+ people working on YaST full-time, every working day before one release and the next one. That's A LOT of changes and adaptations. I guess bigger figures apply to Gnome, Plasma, the kernel, YourFavouriteSoftwareInTheDistribution. I don't think it's realistic to cover all changes to all pieces of the distribution in the release notes. You may say we should cover the important changes, or the unexpected ones, or the visible ones... Which brings the question about what "important", "unexpected" or "visible" means for everyone (spoiler: it's completely different for every reader). We blog about the changes every two weeks, we have detailed changelog files for each component of YaST, we contribute to the distribution release notes with things we consider worth mentioning there and we do all the development openly (i.e. for every character changed in the YaST code you can find the Github's pull request). Please don't ask us to, in addition to all the above, know what is important to every one of our users and knock on their doors to present an individual report for each of them covering their interests.
I had not noticed the change in YaST, because I don't change root's locale. I see in "/etc/sysconfig/language" for 15.0 this paragraph:
# This defines if the user "root" should use the locale settings # which are defined here. # Value "ctype" means that root uses just LC_CTYPE. # Value "yes" means that root uses the full settings.. # ROOT_USES_LANG="ctype"
If the variable is there, why can't YaST touch it? Why is this affected by systemd?
I'm not complaining, but I simply do not understand.
Maybe YaST did something more than change that variable, or maybe the variable is also ignored.
I would need to invest some time researching in order to provide an answer to each of those questions. Specially since the transition from the old way of managing locale to the systemd one has been (and still is) a tortuous path full of pitfalls. I fear I don't have the time for that right now (working on pushing Leap 15.1 out). Sorry. But I'm pretty sure it was not done lightheartedly. Maybe the developer who did the change (Jiri Srain) can tell you more if you are interested enough and ask him.
Sometimes (not always), things can be re-engineered to find a way to bring some old functionality back, but in a way that is systemd-compliant and avoids side effects. Unfortunately, that's more complex than "should be re-inserted".
For further reference, this is the change in Github: https://github.com/yast/yast-country/pull/149
Huh. That's like greek to me, sorry.
Fortunately is not Greek, but Ruby. ;-) Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 21/01/2019 12.53, Ancor Gonzalez Sosa wrote:
On 1/21/19 12:07 PM, Carlos E. R. wrote:
...
I fear I don't have the time for that right now (working on pushing Leap 15.1 out). Sorry.
But I'm pretty sure it was not done lightheartedly. Maybe the developer who did the change (Jiri Srain) can tell you more if you are interested enough and ask him.
Fair enough. Thanks :-)
Sometimes (not always), things can be re-engineered to find a way to bring some old functionality back, but in a way that is systemd-compliant and avoids side effects. Unfortunately, that's more complex than "should be re-inserted".
For further reference, this is the change in Github: https://github.com/yast/yast-country/pull/149
Huh. That's like greek to me, sorry.
Fortunately is not Greek, but Ruby. ;-)
Same thing :-) -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On Fri, Jan 18, 2019 at 10:39 AM Rainer Hantsch <office@hantsch.co.at> wrote:
This should be fixed anyways.
This thread is on development list. It contains zero factual information (openSUSE version, exact locale settings, exact terminal, exact $TERM value, screenshot of incorrect display, programs that exhibit problem and their invocation) that would allow someone to at least attempt to reproduce this issue. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 18/01/2019 11.09, Andrei Borzenkov wrote:
On Fri, Jan 18, 2019 at 10:39 AM Rainer Hantsch <> wrote:
This should be fixed anyways.
This thread is on development list. It contains zero factual information (openSUSE version, exact locale settings, exact terminal, exact $TERM value, screenshot of incorrect display, programs that exhibit problem and their invocation) that would allow someone to at least attempt to reproduce this issue.
I suggest one way (Leap 15.0 here) to reproduce. I use this script to get iso encoding terminal: Telcontar:~ # cat /usr/local/bin/isoxterm #!/bin/sh LANG=en_US.ISO-8859-1 LC_ALL=en_US.ISO-8859-1 /usr/bin/xterm -bd blue & Telcontar:~ # Then I call it: Telcontar:~ # isoxterm & I get an xterm with the appropriate locale: Telcontar:~ # locale LANG=en_US.ISO-8859-1 LC_CTYPE="en_US.ISO-8859-1" LC_NUMERIC="en_US.ISO-8859-1" LC_TIME="en_US.ISO-8859-1" LC_COLLATE="en_US.ISO-8859-1" LC_MONETARY="en_US.ISO-8859-1" LC_MESSAGES="en_US.ISO-8859-1" LC_PAPER="en_US.ISO-8859-1" LC_NAME="en_US.ISO-8859-1" LC_ADDRESS="en_US.ISO-8859-1" LC_TELEPHONE="en_US.ISO-8859-1" LC_MEASUREMENT="en_US.ISO-8859-1" LC_IDENTIFICATION="en_US.ISO-8859-1" LC_ALL=en_US.ISO-8859-1 Telcontar:~ # Then run yast: Telcontar:~ # yast sw_single I can't paste the result, because there is translation, but I see that the arrows are incorrect. This is a quick test, I don't know which windows show more errors, and this one is not that important; maybe Rainer can point others? Also, you can see that the "view by repository" is missing. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Hello, Carlos. Older versions of YaST showes so massive distortions that it was close to unreadable on a plain text console. In last versions of openSuSE this became better, it is now reduced to what you (Carlos) actually described. So it can be used, but it does not appear 100% correctly (compared to a system using the default UTF8 settings. I use this locales, btw., if I am correct this is 8859-15: rainer@majestix:~> locale LANG=de_DE@euro LC_CTYPE="de_DE@euro" LC_NUMERIC="de_DE@euro" LC_TIME="de_DE@euro" LC_COLLATE="de_DE@euro" LC_MONETARY="de_DE@euro" LC_MESSAGES="de_DE@euro" LC_PAPER="de_DE@euro" LC_NAME="de_DE@euro" LC_ADDRESS="de_DE@euro" LC_TELEPHONE="de_DE@euro" LC_MEASUREMENT="de_DE@euro" LC_IDENTIFICATION="de_DE@euro" LC_ALL= I also see (i.e. during updates with zypper) that the progress line is showing sometimes a 2-byte character (two wrong characters instead of one correct char). Zypper - I *guess* - will use the same libraries as Yast? (Also I am not sure about what will happen if I connect some of my serial terminals. In this case we are somewhere between VT100/VT220 and ANSI terminal, but again far away from UTF8 ability. I only want to point out how important it is to solve this bug.) Am Freitag, 18. Jan 2019, 11:28:33 schrieb Carlos E. R.:
On 18/01/2019 11.09, Andrei Borzenkov wrote:
On Fri, Jan 18, 2019 at 10:39 AM Rainer Hantsch <> wrote:
This should be fixed anyways.
This thread is on development list. It contains zero factual information (openSUSE version, exact locale settings, exact terminal, exact $TERM value, screenshot of incorrect display, programs that exhibit problem and their invocation) that would allow someone to at least attempt to reproduce this issue. ... Then run yast:
Telcontar:~ # yast sw_single
I can't paste the result, because there is translation, but I see that the arrows are incorrect. This is a quick test, I don't know which windows show more errors, and this one is not that important; maybe Rainer can point others?
Also, you can see that the "view by repository" is missing.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 18/01/2019 11.58, Rainer Hantsch wrote:
Hello, Carlos.
Older versions of YaST showes so massive distortions that it was close to unreadable on a plain text console. In last versions of openSuSE this became better, it is now reduced to what you (Carlos) actually described. So it can be used, but it does not appear 100% correctly (compared to a system using the default UTF8 settings.
I'm afraid you will have to report each occurrence on a system that is currently under support, like 15.* or TW. It is too late for 42.* or older.
I also see (i.e. during updates with zypper) that the progress line is showing sometimes a 2-byte character (two wrong characters instead of one correct char). Zypper - I *guess* - will use the same libraries as Yast?
Not curses, I guess, just "plain text".
(Also I am not sure about what will happen if I connect some of my serial terminals. In this case we are somewhere between VT100/VT220 and ANSI terminal, but again far away from UTF8 ability. I only want to point out how important it is to solve this bug.)
When I use old software that is not UTF aware, like would be serial tools, then I open that xterm I mentioned on the other post, so that it works as expected. However, if it writes filenames, they may look incorrect on other tools. That's expected. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On Fri, Jan 18, 2019 at 1:28 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 18/01/2019 11.09, Andrei Borzenkov wrote:
On Fri, Jan 18, 2019 at 10:39 AM Rainer Hantsch <> wrote:
This should be fixed anyways.
This thread is on development list. It contains zero factual information (openSUSE version, exact locale settings, exact terminal, exact $TERM value, screenshot of incorrect display, programs that exhibit problem and their invocation) that would allow someone to at least attempt to reproduce this issue.
I suggest one way (Leap 15.0 here) to reproduce. I use this script to get iso encoding terminal:
Telcontar:~ # cat /usr/local/bin/isoxterm #!/bin/sh LANG=en_US.ISO-8859-1 LC_ALL=en_US.ISO-8859-1 /usr/bin/xterm -bd blue & Telcontar:~ #
...
Telcontar:~ # yast sw_single
I can't paste the result, because there is translation, but I see that the arrows are incorrect.
I see single incorrect down arrow symbol. If you look at terminfo for xterm, definition for down arrow (actually all four arrows) is missing. It works correctly on Linux console. So this particular case does not appear to be YaST issue at all. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 18/01/2019 12.31, Andrei Borzenkov wrote:
On Fri, Jan 18, 2019 at 1:28 PM Carlos E. R. <> wrote:
I suggest one way (Leap 15.0 here) to reproduce. I use this script to get iso encoding terminal:
Telcontar:~ # cat /usr/local/bin/isoxterm #!/bin/sh LANG=en_US.ISO-8859-1 LC_ALL=en_US.ISO-8859-1 /usr/bin/xterm -bd blue & Telcontar:~ #
...
Telcontar:~ # yast sw_single
I can't paste the result, because there is translation, but I see that the arrows are incorrect.
I see single incorrect down arrow symbol. If you look at terminfo for xterm, definition for down arrow (actually all four arrows) is missing. It works correctly on Linux console. So this particular case does not appear to be YaST issue at all.
You mean alt-F1? I don't know how to switch that to non-utf. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
18.01.2019 14:31, Andrei Borzenkov пишет:
Telcontar:~ # yast sw_single
I can't paste the result, because there is translation, but I see that the arrows are incorrect.
I see single incorrect down arrow symbol. If you look at terminfo for xterm, definition for down arrow (actually all four arrows) is missing. It works correctly on Linux console. So this particular case does not appear to be YaST issue at all.
BTW this is also displayed incorrectly in UTF-8 locale which means it is totally unrelated to discussed issue. Down arrow is the only character that is displayed incorrectly. ncurses-based programs actually send 'v' character (which is ASCII approximation) after shifting to ACS which is displayed by terminal as something resembling up tack character (except it looks shifted up half line height). This happens in xterm, xfce terminal and gnome terminal. ... 'v' indeed is translated to this character at least by gnome terminal and I suppose others too - which maps to special DEC line graphics. It looks like like ncurses issue. It probably should not emit smacs sequence when it is going to emit plain ASCII approximation instead of character from acsc. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
20.01.2019 23:24, Andrei Borzenkov пишет:
18.01.2019 14:31, Andrei Borzenkov пишет:
Telcontar:~ # yast sw_single
I can't paste the result, because there is translation, but I see that the arrows are incorrect.
I see single incorrect down arrow symbol. If you look at terminfo for xterm, definition for down arrow (actually all four arrows) is missing. It works correctly on Linux console. So this particular case does not appear to be YaST issue at all.
BTW this is also displayed incorrectly in UTF-8 locale which means it is totally unrelated to discussed issue.
Down arrow is the only character that is displayed incorrectly. ncurses-based programs actually send 'v' character (which is ASCII approximation) after shifting to ACS which is displayed by terminal as something resembling up tack character (except it looks shifted up half line height). This happens in xterm, xfce terminal and gnome terminal.
... 'v' indeed is translated to this character at least by gnome terminal and I suppose others too - which maps to special DEC line graphics. It looks like like ncurses issue. It probably should not emit smacs sequence when it is going to emit plain ASCII approximation instead of character from acsc.
This is fixed in current ncurses (and Tumbleweed) which correctly displays 'v' for down arrow in this case. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
V Fri, 18 Jan 2019 08:17:43 +0100 Rainer Hantsch <office@hantsch.co.at> napsáno:
Hello.
I do not want to start a discussion here about advantages/disadvantages of one or the other encoding (ISO-8859-1, UTF8, ...) and/or why I should use UTF8. I have good reasons why I don't want to do that and stay with ISO-8859-1, and it also is a question of principle that an OS and all its programs have to correctly (and not mostly) support them.
Well, YaST supports only UTF-8. Reason is that guessing enconding just from text is unreliable, so we pick one format that works well for various locale. Originally we use locale to set enconding, but it leads to many issues with config files that user download, with locale set to C, but config files in UTF and others similar issues. So unless there is reliable and fast way how to detect encoding of text, we do not plan to modify it unless there is a good reason for it and that won't break cases mentioned above. Josef
Linux is offering a huge number of different encodings and should be aware of correctly supporting all of them, as it did before UTF8. If not, it is a question of careless coding or implementation.
I use still ISO-8859-1 on all of my servers and workstations because of several reasons (and I do not want to change something in this point). Most of my self-written programs are based on ncurses, using the fuill set of features (also windows and window layers). All of the, are working perfectly and are displaying correctly, so I am pretty sure that ncurses and all related libs _are_ correct.
So what? I see that many programs (i.e. YaSt in textmode, but also several other tools) are not correctly displaying, they show sometimes 2-Byte characters and distort hereby the output. This happens more on real text screens (i.e. Ctrl-Alt-F1 console) and is slightly better in a graphical "konsole" of KDE, but it happens. From my point of view this can only come from a poor usage of ncurses, if it would nbe ncurses itself, my programs would also have troubles (but they don't). Perhaps there is another layer of software on top of ncurses and that one is not correctly written? Or are this tools not using ncurses and doing everything "manually"? -> This is a many years persisting issue and shows that even Leap (many years after UTF8 introduction) is not tested well in this point and/or fixed.
I watch this phenomen since UTF8 came out. Because I do remote administration often in text mode (ssh or in a few cases even by modem dial in), a properly working handling of encodings has to work.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Josef. The situation you describe lead me into using everywhere iso-8859-1/15. This incoding is closest to DOS codepage, a 1-Byte charset, and causing no troubles when interacting with microcontrollers (also usually only using 8-Bit charsets). For me "UTF8 everywhere" would be an odyssee. I would have to implement UTF8 into microcontrollers with a few k of ROM (a no-go), or everywhere implement a translation. It is lots easier to have everywhere 8859-1 in use. About YaST: I see that Yast can perfectly work with config files edited with 'joe' on 8859-1 system. So I see no need to change something in this part? The problem YaST has, is controlling the screen/terminal in text mode! It is fully ok if you internally always use UTF8, but it appears there is a problem with correctly controlling the terminal. Therefore it works fine on screens/terminals using UTF8, but it has some glitches when controlling a terminal on 8859-1 (as an example). So YaST *must* read the locale settings and then do some kind of translation before writing to the screen. This is the only way to get this working. Noone can use YaST without logging in. And with logging in, a locale setting is already assigned. No? Btw: I do the same (internally using a standard encoding) in my programs. The only difference is that my standard is iso-8859-15 while your standard is utf8. Doesn't really matter, we (both) have to convert while reading/writing. But it seems that some of this conversions have been not implemented in Yast, and this causes the described distortions. Am Freitag, 18. Jan 2019, 12:06:32 schrieb Josef Reidinger:
V Fri, 18 Jan 2019 08:17:43 +0100
Rainer Hantsch <office@hantsch.co.at> napsáno:
Hello.
Well, YaST supports only UTF-8. Reason is that guessing enconding just from text is unreliable, so we pick one format that works well for various locale. Originally we use locale to set enconding, but it leads to many issues with config files that user download, with locale set to C, but config files in UTF and others similar issues.
So unless there is reliable and fast way how to detect encoding of text, we do not plan to modify it unless there is a good reason for it and that won't break cases mentioned above.
Josef
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday, January 18, 2019 12:34:05 PM CET Rainer Hantsch wrote:
Hello, Josef.
The situation you describe lead me into using everywhere iso-8859-1/15. This incoding is closest to DOS codepage, a 1-Byte charset, and causing no troubles when interacting with microcontrollers (also usually only using 8-Bit charsets). For me "UTF8 everywhere" would be an odyssee. I would have to implement UTF8 into microcontrollers with a few k of ROM (a no-go), or everywhere implement a translation. It is lots easier to have everywhere 8859-1 in use.
But UTF-8 is compatible with ASCII as well. There should be no issues as long as you don’t do anything silly like adding a BOM to the start of each file. Also, implementing support for handling basic UTF-8 (as opposed to full Unicode support) is in fact trivial. Remember it was conceived in a time when what you describe as a microcontroller might well have been a PC.
participants (12)
-
Ancor Gonzalez Sosa -
Andrei Borzenkov -
Carlos E. R. -
Jan Engelhardt -
Joachim Wagner -
Josef Reidinger -
Martin Herkt -
Oliver Kurz -
Rainer Hantsch -
Richard Brown -
Stefan Seyfried -
Wolfgang Bauer