A circumflex a circumflex a circumflex a circumflex a circumflex a circumflex a circumflex a circumflex



  • AN IMPORTANT MESSAGE FROM UBUNTU DO-RELEASE UPGRADE!



  • Hey, at least they prepopulated the list for you.



  • So... the unicode map happens to be slightly screwed on the terminal you're using and line-drawing characters got improperly converted? Or are you commenting on the message itself?



    If this were Windows, you would just need to reboot, and it would all be better. Heck, that'll work here, but it's better to restart only the necessary services.




  • ┌────────── Looks like your... ───────────┐
    │ │
    │ ...terminal emulator doesn't support │
    │ UTF-8. │
    │ │
    │ <OK> │
    └─────────────────────────────────────────┘

    ┏━━━━━━━━━━━━━━ ISO-8859-1 ━━━━━━━━━━━━━━━┓
    ┃ ┃
    ┃ encodes the letter "â" as 226, which ┃
    ┃ is the first byte in the UTF-8 seq- ┃
    ┃ uence for all these goofy line char- ┃
    ┃ acters. ┃
    ┃ ┃
    ┃ <Well, fuck me runnin'> ┃
    ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛



  • @Circuitsoft said:

    If this were Windows, you would just need to reboot, and it would all be better. Heck, that'll work here, but it's better to restart only the necessary services.
     

    Oh no, not THAT argument again.



  • Looks like someone ran utf8_encode too many times...



  •  Circumflex is vowel mutilation! Sign the bill to end it!



  •  If you don't have already (what is possible in an old instalation), install console-setup.

     

    As plenty of people already explained, that's created because dpkg is outputing in utf-8, but your terminal is running in an old ISO8859-X encoding.



  • @Circuitsoft said:

    Or are you commenting on the message itself?

    That fake-o "dialog box" just made me chuckle. The mesage is actually reasonable, although a smarter process would have realized I need to restart the entire system anyway when done so it's kind of silly to restart those services now. Edit: it would also have been nice to know what those services were actually for, like why the shit was rsync running?

    If you've ever done a "release-upgrade" on Ubuntu, which I think nobody at Canonical has ever done, you'll notice there's about 4-5 places where it needs your input, randomly sprinkled throughout the process. ALL of them are different. This one drew a little fake blue dialog box. One drew a fake black dialog box with a border. Some just ask you on the CLI itself, a couple with a simple "Y/N" prompt, and a couple with a hugely complex 6-7 option prompt*.

    Compare to Windows, where it'll ask you for input ONLY at the very start or the very end of the process, so you don't have to sit there and babysit the thing. Windows is also smart enough to be able to reliably merge changes in configuration due to a version upgrade with configuration changes created by the user on the old version, so there's no need for that awful "how do I resolve this conflict?" prompt. (Mostly because configuration-due-to-software-version-change is all system-level, while configuration-user-changed is all user-level, so they don't conflict. Linux could technically pull that off, it just... doesn't bother? Linux apps are too lazy to read settings from a system-level file and from a user-level file and merge them? Man, they sure could use something like a Registry!)

    Now I understand this is a Linux server with no GUI, so maybe the GUI version of this process is really well-engineered. But as-is, upgrading Linux is like going back in time 15 years to the Windows 98 installer.

    *) (from memory) "Your file differs from the new one in the upgrade repository, Keep Yours, Keep Theirs, Keep Both, Merge Both into One (EXPERIMENTAL!!!), Show Differences, Go to Command Line to manually resolve". The real answer to which is "fuck if I know", but there's no option for that.



  •  blakeyrat why don't you just stay the fuck away from Linux if it annoys you so much all the time? Or do you also buy an iPhone 5 (or Android Phone, or Windows Phone, or Blackberry; pick the one you like the least) and then bitch all day about fucking horrible it is?

    Jeez



  • @pbean said:

    blakeyrat why don't you just stay the fuck away from Linux if it annoys you so much all the time?

    I fucking try to.

    Look, I got the assignment at work to take over some other group's servers on the theory that, while I'm not remotely qualified to do that, I'm at least not as much a fuckwit as the people who were managing the servers before. (Turned out correct-- they had no backups, no monitoring, were running an unsupported version, no load-balancing, everything in one AWS availability zone-- if it's possible to do wrong in a cloud hosting environment they did it fucking wrong.) The apps are all MySQL/PHP/Apache.

    This isn't a big enough deal to quit over or anything, but it's not like I had the choice when the server OS was chosen in the first place, and I'm certainly not going to put my ass on the line by moving all the apps to a Windows server, especially when I know from experience that PHP apps usually are written like shit and break on Windows because they contain things like hard-coded paths, or weird assumptions about character encodings.

    Which means I'm in charge of these Ubuntu servers, like it or not. And I don't like it.

    @pbean said:

    Or do you also buy an iPhone 5 (or Android Phone, or Windows Phone, or Blackberry; pick the one you like the least) and then bitch all day about fucking horrible it is?

    I bitched about my iPhone 3G, but mostly about the iTunes I was required to use to run the fucking thing. I'm actually reasonably happy with my Windows Phone 7, except the browser needs some love and a lot of websites treat it stupidly (like this one).

    But see, your premise here? That I picked Ubuntu Server? Is wrong. Why would you assume I picked it? Did I say I picked it? Did I give any impression I picked it? Have you never, ever, in your professional career be tasked with doing something you're not qualified to do and don't enjoy doing? Never?



  • @blakeyrat said:

    Have you never, ever, in your professional career be tasked with doing something you're not qualified to do and don't enjoy doing?

    The only things I get tasked to do require no qualifications, and I've not enjoyed any of them.



  • @blakeyrat said:

    Compare to Windows, where it'll ask you for input ONLY at the very start
    or the very end of the process, so you don't have to sit there and
    babysit the thing.
     

     That's not really true btw. Whenever Windows Update encounters a new version of IE, or directx,  or .net framework, or pretty much anything which also has a redistributable, it will block the entire update until you click OK or whatever to continue

     



  • The varying UIs are actually understandable- each one is provided by the application itself's update script, not the updater.

    Granted that's not entirely non-wtf...



  • @blakeyrat said:

    That fake-o "dialog box" just made me chuckle.

    That's a standard UI for Debian – if you install Debian from scratch, that's the installation UI that you get. It's pretty reasonable IMO. Some packages also use that as their configuration UI – I forget whether I've seen it with postfix or Exim, one of the two anyway.

    The character set confusion is weird though. I get that myself because I run PuTTY with Consolas, and I figured it was due to Consolas not having the Unicode line-drawing-characters range. However, you appear to be using Courier New, which definitely has that range. Royal TS uses a different library for SSH sessions and that manages to do line drawing with Consolas just fine, so it's maybe a PuTTY bug. It's some sort of terminal encoding mix-up somewhere – not sure who's truly to blame here, only that if you tried investigating the UNIX terminal system, your reaction would be priceless.

    btw, are you familiar with ncurses? PuTTY supports it – basically mouse support for terminal sessions, like MS-DOS programs that used a solid character cell for a cursor, except in PuTTY it just uses your regular Windows cursor.



  • @Daniel Beardsmore said:

    btw, are you familiar with ncurses?

    Yes, dealing with this has made me familiar with n^2 curses actually.



  • @blakeyrat said:

    That fake-o "dialog box" just made me chuckle.
    It's drawn by ncurses library, and pretty standard during dpkg installs/upgrades. The border's wrong because your terminal is not set to interpret the data it's getting as UTF-8 (the question is why - I don't think there's been any Linux distros that haven't used UTF-8 in console for years).
    @blakeyrat said:
    Compare to Windows, where it'll ask you for input ONLY at the very start or the very end of the process, so you don't have to sit there and babysit the thing.
    It's obvious that you never tried upgrading Internet Explorer or Security Essentials through Windows/Microsoft Update. They'll pop up an installer in the middle of the process requiring you to click a few things (in IE's case there's just the Continue and Cancel buttons - just in case you'd want to abort IE install at the last moment)...
    @blakeyrat said:
    Linux could technically pull that off, it just...
    It's not really Linux - each package comes from a different source, and often has it's own custom configuration format. Some programs actually have a distribution-default config file, and a separate config file where you actually do localized settings, which will work the way you imagine during upgrades. Most don't though, and require you to merge the config changes manually - OTOH, many administrators like this, because it means that the settings won't change just because somebody decided that different default settings should be used by the new program version.
    @blakeyrat said:
    But as-is, upgrading Linux is like going back in time 15 years to the Windows 98 installer.
    Windows 98 let you upgrade all software on your computer with a single suite of tools? Wow, how did I miss that, and why was it removed?



  • @Daniel Beardsmore said:

    The character set confusion is weird though. I get that myself because I run PuTTY with Consolas,

    Wild guess: Did you tell PuTTY to use UTF-8?



  • @ender said:

    @blakeyrat said:
    Linux could technically pull that off, it just...
    It's not really Linux - each package comes from a different source, and often has it's own custom configuration format. Some programs actually have a distribution-default config file, and a separate config file where you actually do localized settings, which will work the way you imagine during upgrades. Most don't though, and require you to merge the config changes manually - OTOH, many administrators like this, because it means that the settings won't change just because somebody decided that different default settings should be used by the new program version.

    Stop confusing the issues with the facts.



  • @fatbull said:

    Wild guess: Did you tell PuTTY to use UTF-8?

    Of course. But I was just thinking, I don't know whether that server is set as UTF-8 or not … TRWTF is that one still has to lark about manually configuring pointless details in SSH when the stupid thing should figure itself out. It's not the 1970s any more.



  • @Daniel Beardsmore said:

    TRWTF is that one still has to lark about manually configuring pointless details in SSH when the stupid thing should figure itself out. It's not the 1970s any more.

    Wow, what a remarkably sane comment. And exactly right, why should I have to spent a single millisecond thinking about character encoding in 2012? I can guarantee I don't if I'm using Microsoft's RDP.



  • @ender said:

    It's not really Linux - each package comes from a different source, and often has it's own custom configuration format.

    Yes, that is the WTF.

    @ender said:

    Some programs actually have a distribution-default config file, and a separate config file where you actually do localized settings, which will work the way you imagine during upgrades.

    So at least some programs have sane design.

    @ender said:

    Most don't though, and require you to merge the config changes manually - OTOH, many administrators like this, because it means that the settings won't change just because somebody decided that different default settings should be used by the new program version.

    If done right, why would those administrators ever have to think about it? They've already made the configuration they want, and the program will "overwrite" its default settings with the ones the administrator made. Assuming it's working in a sane way.

    @ender said:

    Windows 98 let you upgrade all software on your computer with a single suite of tools? Wow, how did I miss that, and why was it removed?

    I don't appreciate people being purposefully stupid. You know what I meant. You can make your point without pretending to be retarded. If you pretend to be retarded, I'll just start assuming you actually are. You know, like I do with Boomzilla.



  • @blakeyrat said:

    @ender said:
    Windows 98 let you upgrade all software on your computer with a single suite of tools? Wow, how did I miss that, and why was it removed?

    I don't appreciate people being purposefully stupid. You know what I meant. You can make your point without pretending to be retarded. If you pretend to be retarded, I'll just start assuming you actually are. You know, like I do with Boomzilla.

    It's funny because blakey demonstrated in that other thread about how he was too retarded to understand basic modern Linux package management. You have to be careful about pointing this sort of thing with him, though, or he'll lie about how you're being rude to him.



  • @blakeyrat said:

    Wow, what a remarkably sane comment. And exactly right, why should I have to spent a single millisecond thinking about character encoding in 2012?
    You don't - set it to UTF-8 and be done (unless you're accessing a legacy system).@blakeyrat said:
    I can guarantee I don't if I'm using Microsoft's RDP.
    Not as long as your local keyboard and the server's keyboard layout match.
    @blakeyrat said:
    You know what I meant.
    No, I actually don't - if I want to update Microsoft's programs, I have to use Microsoft Update (unless I want to update Windows Live stuff, which has it's own updater for some reason; I also pointed out two cases where you will be asked questions in the middle of installing). If I want to update Adobe's programs, I have to use Adobe's updater. Instead of using one command and answering some questions during the install phase, I have to manually run several updaters (and in many cases download and install updates manually). Sure, the updater on Linux could've deferred those questions till the end of the process, but it's still much better than anything available on Windows (btw, some distros actually work like that - Gentoo's portage will fetch, compile and install in one go, and at the end it'll tell you if there's any config file conflicts you need to solve, and offer you two tools to help you solve those conflicts; of course, since it's Gentoo, you'll be wasting a lot of time compiling, which is it's own downside).
    Things may change with the Windows Store, but I'm not expecting too much from that.



  • The screenshots on this page might give you an idea …

    (Not sure whether LOL or WTF?)



  • @blakeyrat said:

    @Daniel Beardsmore said:
    TRWTF is that one still has to lark about manually configuring pointless details in SSH when the stupid thing should figure itself out. It's not the 1970s any more.

    Wow, what a remarkably sane comment. And exactly right, why should I have to spent a single millisecond thinking about character encoding in 2012? I can guarantee I don't if I'm using Microsoft's RDP.

     

    Thanks, that made me laugh a bit.

    Blakeyrat, you are far from understanding why Linux does any of those "WTFs"  you point here. Either get some humility and learn a bit, or get out of Linux and stop stressing about it.

    By the way, people won't want a remote login program that mangles the binary data they give it. Get over it and configure your Putty (I didn't notice you were using SSH at first) to use UTF-8.



  • @Mcoder said:

    Blakeyrat, you are far from understanding why Linux does any of those "WTFs" you point here. Either get some humility and learn a bit, or get out of Linux and stop stressing about it.

    I don't want to learn about the problems, I want the problems fixed so I (and everybody else) doesn't have to fucking deal with them. Whether or not I know "why" the WTF exists doesn't change the fact that the WTF exists.

    Christ, the concept of "quality" is really that foreign to you? Really? Or do you just actively hate things that are well-designed?

    Fix it.



  • @blakeyrat said:

    Fix it.

    No, thanks. Just like at the vi thread, I don't want my ssh software "fixed".

    You may understand it when you grow up... Or you may keep acting as a child and refuse to learn anything.

     



  • @Mcoder said:

    No, thanks. Just like at the vi thread, I don't want my ssh software "fixed".
     

    The screen shows wrong characters. This is a bug. It must be fixed.



  • @Mcoder said:

    You may understand it when you grow up... Or you may keep acting as a child and refuse to learn anything.

    How far back should we go? Back to when there was no ROM and the bootloader had to be entered word by word using toggle switches? Should we have display screens, or stick with printers?

    What's wrong with people? Why is it that the only thing we manage to do with the unthinkable amounts of CPU power at our fingertips, is write shoddy, bloated code that doesn't work and thinks that hex numbers are acceptable error messages?

    You don't bark for your dog, so why have a computer if you have to do all the computing for it? Isn't that what these infernal machines are there for? SSH isn't Telnet: SSH is a modern protocol, invented in a age where having more than seven or eight bits per character is possible! Seriously, no-one should have to care how the remote machine is managing to get the correct letters to appear on the screen. The 1980s is over, man!



  • @dhromed said:

    @Mcoder said:
    No, thanks. Just like at the vi thread, I don't want my ssh software "fixed".
    The screen shows wrong characters. This is a bug. It must be fixed.

    Nice succinct way of putting it. I don't understand how there could possibly be a debate here. Edit: Even Beardsmore agrees and he never agrees with me.

    Mcoder, do you think fixing the character encoding bug would somehow "ruin" the tool for you? Do you somehow rely on having to manually select the character encoding when connecting to a server? What exactly are you afraid of?



  • @dhromed said:

    @Mcoder said:
    No, thanks. Just like at the vi thread, I don't want my ssh software "fixed".

    The screen shows wrong characters. This is a bug. It must be fixed.

    Yes, it sounds like a problem with whatever client blakeyrat is using. Do we even know what it is? Since we know he's on windows, the most likely seems to be putty, but I don't recall him ever saying. ssh just provides the transport. There's nothing stopping blakey's client from figuring out the encoding and doing the right thing.

    I blame Windows, and its ridiculous legacy character encoding environment that encourages sloppy programming.



  • @blakeyrat said:

    If you've ever done a "release-upgrade" on Ubuntu, which I think nobody at Canonical has ever done, you'll notice there's about 4-5 places where it needs your input, randomly sprinkled throughout the process. ALL of them are different. This one drew a little fake blue dialog box. One drew a fake black dialog box with a border. Some just ask you on the CLI itself, a couple with a simple "Y/N" prompt, and a couple with a hugely complex 6-7 option prompt*.

    In fact, most of those are created by a tool called debconf, which can itself be configured using

    dpkg-reconfigure debconf

    and there (at least on Debian) you can choose if you prefer ncurses based dialogs, simple text-based prompts scrolling through your screen or if you want to have all configs for one package (if there is more than one - which is quite common for Debian but the Ubuntu people disabled most of those configs so there it happens much rarer) into a temporary text file (pseudo config file) which you can then read with your editor, enable the options, save the temp file and apply it.

    In fact, I generally suggest staying with the ncurses dialogs (as they are tested most), but if you are working over a really slow link, if you want to log your backlog to a file or if you just think those dialogs are silly, you can switch it to text-based prompts.

    The editor based config feature is nice for some packages that have a dozen or more questions (xserver-xorg was such a candidate a few years ago), as you can read all the questions and can "go back" a question without starting over from the beginning; however, it is least tested, and it may contain questions that would have got skipped when you answered the questions in one of the other interfaces.

    As a side note, you can also disable debconf completely (in the command mentioned above), so that it won't ask you any questions any more and answer all of them with the defaults. As debconf uses debconf itself to configure itself though, you'll need some command line switches to get it out of that state again, if you change your mind.

    But to be honest, upgrading Debian from Woody to Sarge had dozens of prompts all in the middle of everything (caused mainly because every package is maintained by its own maintainer and there was no way of informing about important changes in a package other than adding some debconf questions), so it might have gotten better with Ubuntu, but seems that the heritage is still noticable. Maybe the Canonical people should just set Debconf messages to disabled (auto-answer all questions with the default answer) to avoid confusing newbies?



  • @blakeyrat said:

    Mcoder, do you think fixing the character encoding bug would somehow "ruin" the tool for you? Do you somehow rely on having to manually select the character encoding when connecting to a server? What exactly are you afraid of?
     

    What I don't want is a ssh protocol that is aware of character encoding. And if it is not aware of character encoding, it can't automaticaly negotiate it with the client. Updating sshd to make it aware of encoding will break a hell of a lot of tools and protocols that run over it. It could literaly put half of the Internet offline. It would also make ssh way less usefull.

    Now, your client does either use a dated encoding by default, or had its configuration missed with. If it is Putty (well, I don't remember WTF Putty defaults to, I just remember that I can't stand it) you just reconfigure the default session, and you are done with it.

    Text encoing was indeed a huge WTF untill everybody decided tho use UTF-8. Now it is just a Windows WTF, since MS refuses to use whatever everybody else is using (instead, it has 3 standards - I don't know whatever they prefer now). It is natural that Windows software still gets it wrong.



  • @Mcoder said:

    What I don't want is a ssh protocol that is aware of character encoding.

    ... why?

    @Mcoder said:

    Updating sshd to make it aware of encoding will break a hell of a lot of tools and protocols that run over it. It could literaly put half of the Internet offline.

    Well gee whiz I guess the genius who invented it should have maybe spent 0.213 milliseconds thinking about his design.

    BTW, your ridiculous hyperbole doesn't help matters.

    @Mcoder said:

    It would also make ssh way less usefull.

    ... how?

    @Mcoder said:

    Text encoing was indeed a huge WTF untill everybody decided tho use UTF-8.

    Apparently it still is. There's this one post on DailyWTF about a guy who was having character encoding problems with SSH! Hah.

    @Mcoder said:

    Now it is just a Windows WTF, since MS refuses to use whatever everybody else is using (instead, it has 3 standards - I don't know whatever they prefer now).

    Windows adopted UTF before UTF-8 existed, which is the source of all Windows WTFs. What's SSH's excuse?


  • Winner of the 2016 Presidential Election

    It seems like most well-designed protocols provide forward-compatibility by either doing some kind of version negotiation (I'm a v3 server, I support Unicode character encodings! You're a v2 client? OK, we'll fall back to legacy ASCII.) or allowing unrecognized tokens to be ignored ("I'm using UTF-8!" "Duh, what?" "U-T-F... Never mind. ASCII it is."). This allows the specification to add arbitrary new features without totally breaking backwards compatibility (the cardinal sin in a Unix-like environment).

    I don't know much about the plumbing of the SSH protocol but if it doesn't support some kind of future-proofing mechanism like that, it's not well designed.



  • @joe.edwards said:

    I don't know much about the plumbing of the SSH protocol but if it doesn't support some kind of future-proofing mechanism like that, it's not well designed.

    On my system, ssh is set up (by default) to send all of the locale information, which includes the encoding. But then, if your client decides it doesn't really care about any of this stuff and is going to just use whatever its favorite encoding is...



  • Depends on the server. In the case of the ones I'm looking at, PuTTY is set to UTF-8 with "Poor man's line drawing", but the server's locale is as follows:

    Old server:

    $ locale
    LANG=en_US
    LC_CTYPE="en_US"
    LC_NUMERIC="en_US"
    ...
    LC_IDENTIFICATION="en_US"
    LC_ALL=
    

    New server:

    [admin@mailfilter ~]$ locale
    LANG=
    LC_CTYPE="POSIX"
    LC_NUMERIC="POSIX"
    ...
    LC_MEASUREMENT="POSIX"
    LC_IDENTIFICATION="POSIX"
    LC_ALL=
    
    

    The problem isn't PuTTY, it's the server being set to whatever "en_US" and "POSIX" (!!) mean as character encodings — they work fine if I set PuTTY down to ISO-8859-1. These are appliance servers, so I don't get any choice of system language.



  •  0xE2 0xA4 is not even a valid UTF-8 code (0xE2 indicates a three-byte code point).



  • @Daniel Beardsmore said:

    @fatbull said:
    Wild guess: Did you tell PuTTY to use UTF-8?

     

    Of course. But I was just thinking, I don't know whether that server is set as UTF-8 or not … TRWTF is that one still has to lark about manually configuring pointless details in SSH when the stupid thing should figure itself out. It's not the 1970s any more.

     

     ssh doesn't have anything to do with terminal configuration. Putty's terminal emulator is not part of ssh, it's part of the putty application which embeds ssh.

     

     



  • @jes said:

    ssh doesn't have anything to do with terminal configuration. Putty's terminal emulator is not part of ssh, it's part of the putty application which embeds ssh.

    ... and therefore?

    You forgot to include whatever point you were building up to there.



  • @blakeyrat said:

    @jes said:
    ssh doesn't have anything to do with terminal configuration. Putty's terminal emulator is not part of ssh, it's part of the putty application which embeds ssh.

    ... and therefore?

    You forgot to include whatever point you were building up to there.

    Is this one of those being deliberately retarded moments that you claim to loathe? Or did you just not read the thread?


  • Discourse touched me in a no-no place

    I'm just wondering wtf UTF-8 has to do with sftp, or reverse tunnels for things like vnc...



  • @PJH said:

    I'm just wondering wtf UTF-8 has to do with sftp ...

    Besides file paths, you mean?



  • @Daniel Beardsmore said:

    @PJH said:
    I'm just wondering wtf UTF-8 has to do with sftp ...

    Besides file paths, you mean?

    '

    Yeah it only affects the by-far most important thing SFTP as to do

    People like PJH are writing code for Linux, I wager, which explains a lot about its functioning.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    @Daniel Beardsmore said:
    @PJH said:
    I'm just wondering wtf UTF-8 has to do with sftp ...

    Besides file paths, you mean?

    '

    Yeah it only affects the by-far most important thing SFTP as to do

    Strange, I thought the most important thing was to copy the contents of the files verbatim. Nice of you (both) to ignore the tunnelling example by the way.



    My point being, was that since sftp uses ssh for the transfer, why on earth should ssh be UTF-8 aware? That's sftp's job. @blakeyrat said:
    People like PJH are writing code for Linux, I wager, which explains a lot about its functioning.
    Idiot.



  • @PJH said:

    Strange, I thought the most important thing was to copy the contents of the files verbatim. Nice of you (both) to ignore the tunnelling example by the way.

    I admit, I don't know the intricacies of the protocol. So far as I understand, SSH (the shell part of it that is, not the tunnelling system mis-titled a "shell", which is a WTF of its own) is not Telnet wrapped up inside SSL (like how HTTPS is just HTTP wrapped up in SSL); rather, the shell part is a whole new protcol. Now, it dates back to 1995, and Unicode 1.0 dates back to 1991. HTTP 1.0 (1996) fully understands the issue of character encoding – from section 3.4 of the RFC:

         charset = "US-ASCII"
                 | "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3"
                 | "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6"
                 | "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9"
                 | "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR"
                 | "UNICODE-1-1" | "UNICODE-1-1-UTF-7" | "UNICODE-1-1-UTF-8"
                 | token

    IMO there's no excuse by 1995 for new protocols to ignore character encodings, since it was by then widely understood that there was no agreement on how to represent characters. Ideally the encoding would be made part of the standard (i.e. you WILL use UTF-8, or you DIE!) but I can accept in 1995 just noting what encoding is in use, as there was no viable standard to enforce. No use requiring Unicode if the OS didn't support it natively. However, so long as the host machine states what encoding is in use, the client can convert accordingly.



  • @blakeyrat said:

    @jes said:
    ssh doesn't have anything to do with terminal configuration. Putty's terminal emulator is not part of ssh, it's part of the putty application which embeds ssh.

    ... and therefore?

    You forgot to include whatever point you were building up to there.

     

    No, you forgot to read the quoted text in my posting.

     



  • @Daniel Beardsmore said:

    @PJH said:
    Strange, I thought the most important thing was to copy the contents of the files verbatim. Nice of you (both) to ignore the tunnelling example by the way.

    I admit, I don't know the intricacies of the protocol. So far as I understand, SSH (the shell part of it that is, not the tunnelling system mis-titled a "shell", which is a WTF of its own) is not Telnet wrapped up inside SSL (like how HTTPS is just HTTP wrapped up in SSL); rather, the shell part is a whole new protcol. Now, it dates back to 1995, and Unicode 1.0 dates back to 1991. HTTP 1.0 (1996) fully understands the issue of character encoding – from section 3.4 of the RFC:

         charset = "US-ASCII"
                 | "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3"
                 | "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6"
                 | "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9"
                 | "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR"
                 | "UNICODE-1-1" | "UNICODE-1-1-UTF-7" | "UNICODE-1-1-UTF-8"
                 | token

    IMO there's no excuse by 1995 for new protocols to ignore character encodings, since it was by then widely understood that there was no agreement on how to represent characters. Ideally the encoding would be made part of the standard (i.e. you WILL use UTF-8, or you DIE!) but I can accept in 1995 just noting what encoding is in use, as there was no viable standard to enforce. No use requiring Unicode if the OS didn't support it natively. However, so long as the host machine states what encoding is in use, the client can convert accordingly.

     

     

    You could well claim that ssh's name  is less than ideal, it's not a shell. It's a protocol providing the ability to authenticate and authorise connections which will be carried encrypted. It has 3 sections - one for authentication, after which it does whatever level of authorisation the users have configured. Once past those stages, it creates byte streams which can be sent encrypted and may contain whatever byte sequences the users wish to put into those streams. It doesn't know about character encodings as there is no intention of restricting the transport layer to anything character related. If it is used to carry text data, it still doesn't care what the encoding of text is - EBCDIC, Unicode, UTF-8, Windows-xxx, whatever - they are just byte streams.

    CLients such as putty wrap the transport layer in a terminal emulator to work with the environment in which the client runs. As ssh doesn't deal with encodings, the onus is on the wrapper to deal with such issues.

     

     



  • @jes said:

    technically accurate but point-missing babbling …

    Which is all well and good, but in no way does anything you wrote excuse the design. That's the whole point.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.