Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Microsoft Programming Windows IT Technology

Microsoft Unveils a New Terminal for Windows 10 and Windows Subsystem for Linux 2 (techcrunch.com) 198

Windows 10 is getting a new terminal for command-line users, Microsoft announced at its Build developer conference today. The new so-called "Windows Terminal" will launch in mid-June and promises to be a major update of the existing Windows Command Prompt and PowerShell experience. From a report: Indeed, it seems like the Terminal will essentially become the default environment for PowerShell, Command Prompt and Windows Subsystem for Linux users going forward. The new terminal will feature faster GPU-accelerated text rending and "emoji-rich" fonts, because everything these days needs to support emojis, and those will sure help lighten up the command-line user experience. More importantly, though, the Windows Terminal will also support shortcuts, tabs, tear-away windows and theming, as well as extensions. It also will natively support Unicode and East Asian fonts. Microsoft also unveiled a new update to WSL, a compatibility layer for running Linux binary executables natively on Windows. From a report: WSL 2 is based on a Linux 4.19 kernel coming soon to Windows. This kernel uses technology built for Azure. In both cases, it helps to reduce Linux boot time and streamline memory use. In fact, Microsoft is promising developers "twice as much speed for file-system heavy operations, such as Node Package Manager install." WSL 2 will also support running Linux Docker containers natively, so that VMs are no longer required. WSL 2, like Windows Terminal, is coming in mid-June.
This discussion has been archived. No new comments can be posted.

Microsoft Unveils a New Terminal for Windows 10 and Windows Subsystem for Linux 2

Comments Filter:
  • by fluffythedestroyer ( 2586259 ) on Monday May 06, 2019 @12:33PM (#58547100) Homepage
    I never used emoji in CLI...WHY THE HELL WOULD I ANYWAYS ? I always used CLI for tech stuff let say. I don't even know where to start as to why would I use emoji's in CLI anyways
    • If your job involves processing through and filtering and human-written logs written without (usual) managerial oversight (such as chat logs or internal changelogs), a disturbing amount of your day is spent trying to determine whether a particular byte sequence is "poop", "happy", or "explosion".

    • People do still use terminals for chat, and I'm sure it's there for more wysiwyg purposes when embedding them in code.

      But they're wasting their time with powershell. Improved terminal support for graphics is a good first step. But they need to do away with the last vestiges of DOS and just embrace bash/tcsh/unix. It flat out works better.

      If they want to add proprietary windows commands on top, go nuts, I will never learn them or use them or waste even a second worrying about them. I might be compelled to us

      • They do offer bash, at least on WSL. But they also have a version of PowerShell for Linux, and it actually has more users than the Windows version!

        The Linux version is open source, unlike the Windows version. But Microsoft is working on a future version for Windows that will use the same code base as the Linux version and that one will be open source. (The open PowerShell is not 100% bug for bug compatible with the classic PowerShell so both will be available on Windows.) A big part of that is that Windows

    • You may not want to, I also don't use Unicode. That doesn't mean I like seeing Slashdot display gibberish just because someone else didn't account for the lowest common denominator.

    • by Anonymous Coward

      I never used emoji in CLI...WHY THE HELL WOULD I ANYWAYS ? I always used CLI for tech stuff let say. I don't even know where to start as to why would I use emoji's in CLI anyways

      How else can you get a millennial to learn how to use the black box thing with writing in it?

    • I am not saying these are good ideas...
      1. More complexity to your passwords.
      2. Enhanced Character Set for your applications (and text based games can have some graphics)
      3. Text based versions of your chatting software.
      4. Some Emoji's can be a little more functional. Such as picking the Flag for your international settings.
      5. Enhanced comments in code.
      6. Parsing data from other applications that use Emojis. Grep for the eggplant emoji to weed out troubling users.
      7. In general just keeping the import functio

    • I never used colors in CLI...WHY THE HELL WOULD I ANYWAYS ? I always used CLI for tech stuff let say. I don't even know where to start as to why would I use color in CLI anyways

      • I don't even know where to start as to why would I use color in CLI anyways

        I often have multiple terminal windows open, with different settings (credentials, environment settings, etc). I use different font and background colors, which lets me quickly and easily switch to the appropriate one when multitasking.

        Of course, the default is VT220 P3 phosphor amber on black, as God intended it

        • by jabuzz ( 182671 )

          I have to say I have been doing something similar for decades as well (I use the same font, and just change the colours). It makes it easy to determine what the terminal window is logged into and reduces the chances of any wrong window action.

        • *whooosh*

      • Linux terminal windows have had color for many years. Many people find it useful.
    • I think they were being snarky. But I may be wrong, too many things these days that I assume are spoofs turn out to be serious.

    • Irc has emoji support now.

    • It's a javascript hipster thing. Including rainbows with your status messages, etc.
    • by GuB-42 ( 2483988 )

      Emoji by itself doesn't really matter. However it is part of Unicode, and I expect a modern terminal to have complete Unicode support.
      If there is an emoji in a log file, file name, etc... it should show as an emoji on the terminal, just as Japanese text should look like Japanese text and diacritics should be at their proper place. It is just about supporting a standard.

      It anything, Arabic may be a more touchy subject, with all that right-to-left business and control characters that can really mess things up

    • Full Unicode support is important in a terminal in 2019; not all users are using English. Once you do that you get emoji support for free because they are part of the Unicode specification.
  • by QuietLagoon ( 813062 ) on Monday May 06, 2019 @12:39PM (#58547142)
    ... to get away from emojis and other garbage that needs to be "rendered." How is this new command line with rendered fonts and emojis a good thing?
    • Re: (Score:2, Funny)

      by Anonymous Coward

      It's called Unicode, dad.

    • If you write code that renders Unicode, this can be helpful.

      A more likely case is that you end up grepping through logs that contain Unicode from human-generated text. You never know what you'll run into... or need to compare.

    • For the past 30+ years. Most computers supported an adjustable True Type font which is rendered on the fly. Unless you are in a non-gui screen. your text is being rendered.

    • How is this new command line with rendered fonts and emojis a good thing?

      "Rendering" in this case means that the Windows Terminal will be able to use outline fonts instead of raster fonts. This will allow for much better font scaling, and a wider variety of font size choices.

      Emojis are just a byproduct of Windows Terminal finally supporting Unicode properly, as Emojis are part of the Unicode spec. It probably sounds more interesting to the MS marketing droids to put in a press release than to state that the Windows Terminal now correctly supports Anatolian Hieroglyphs [unicode.org].

      It's abo

    • You already need to go there to do support of typefaces with more than 256 characters. A modern full Unicode typeface has tens of thousands of characters to enable multi-language support, a necessity in the modern world of computing. Emojis just come along for the ride.

      With even the lowest end integrated graphics in modern computers, the burden of rendering those characters is minimal. You might feel the burden on a microcontroller but not on anything you would use for desktop computing.

      • Afaik, very few fonts render "tens of thousands of characters"; Microsoft's Arial Unicode (which came on the scene decades ago) is one of the few. Generally, one needs fall-back fonts for different scripts.

        But there's a lot more to rendering some languages' scripts than having the right Unicode code points or even glyphs. Like right-to-left support; joining characters (as in Arabic script); character X that needs to appear before character Y on the screen, even though X follows Y in the string (certain De

  • by TechyImmigrant ( 175943 ) on Monday May 06, 2019 @12:54PM (#58547280) Homepage Journal

    I've run into Unicode on the Windows command line before.

    It's not proper UTF-8 encoded Unicode like God and Dennis Ritchie intended. It's forced 16 bits per character unicode. So when you recompile your C linux command line tool, after fixing the lack of getopt support in Windows, you find all the character I/O has been completely screwed up. Try comparing a signature on a text file when the characters have all been changed out with 16 bit encodings.

    I was starting to make peace with Windows - I could almost get by with a bash shell and MinGW. But the way Windows does Unicode messed it all up again.

    • by thegarbz ( 1787294 ) on Monday May 06, 2019 @01:11PM (#58547386)

      If you're looking for an emotional support network because something doesn't support unicode, you've come to the wrong place.

      • I'm giving people fair warning.

      • by epine ( 68316 )

        If you're looking for an emotional support network because something doesn't support Unicode, you've come to the wrong place.

        I disagree. You couldn't find more emotional support in a M*A*S*H outpatient ward, unless you're unfortunately mired in the mindset "what do cripples know about anything?"

    • Most text editors and terminal settings, can be forced to UTF-8 if it really creates a problem. But we shouldn't feel constrained on an 8 bit character set .

      • Most text editors and terminal settings, can be forced to UTF-8 if it really creates a problem. But we shouldn't feel constrained on an 8 bit character set .

        We should be confident that when outputting a byte from C, we get one byte, not two.
        Now it's become a chore, to accommodate the backwards unicode encoding on ANSI C programs compiled into Windows land.

        • by rastos1 ( 601318 )
          Can you provide a small example of code? Because I have no idea what you talk about. Unless you talk about EOL.
          • Yes. But it's at work, I'm not and I don't have a machine at home exhibiting the same behaviour to test the example tonight.

    • Microsoft has a history of embracing some standards before theyr'e fully standardized or thought out. The 16-bit characters was one of these as at the time I think they honestly assume that this was the proper way to do things; never mind that it's not a big enough space and that even at the time multi-byte character sets were standard in Chinese, Japanese, and Korean. Sometimes Microsoft embraces standards just as they're about to die as well, witness code pages. I think it's the NIH attitude that drive

      • The 16 bit characters were adequate at the time they adopted them. Unicode did not yet have more than 64K glyphs. But it was rapidly growing and Microsoft should have seen the problem approaching. 32 bit characters would have been a better solution, but they were reluctant to go to that because computers of the day still had very small amounts of RAM and storage by modern standards.

        The first hard drive I personally owned stored 20MB and I used even smaller ones. I remember being thrilled when 1GB drives fir

        • 32-bit characters are dumb though. A massive waste of space and multi-byte characters are very simple to use (simpler than wide characters in many cases). The vast majority of the time you do not need to know all bytes of a character until the moment when you're ready to display it. For a file name specifially, there's never a need to interpret the full character when doing file operations, just treat the string as an opaque key.

          (with UTF-8 and other well formed multi-byte character sets there are never a

    • That should be fixed in 1903. And since WSL 2 is an actual Linux kernel, things will be getting more Linuxy.

      • You mean just after the Wright brothers flew their plane?

        (Sorry, I couldn't resist. I know what you're saying...but my first reading, well...)

    • If you're willing to pay the size overhead, the fastest way to handle Unicode is with 32 bit characters. No fussing around with characters of different sizes. 16 bit characters were a solution for a while but Unicode now includes more than 64K glyphs, but I don't think we'll reach 4G glyphs for a while so 32 bit character sets will be adequate.

      Handling UTF-8 gets you into messy problems like dealing with the possibility that you're jumping into the middle of a multi-byte character. The code for any sort of

  • by RogueWarrior65 ( 678876 ) on Monday May 06, 2019 @01:05PM (#58547350)

    Who the hell needs emojis in a shell? Da fuq, Microsoft?!

    • I agree! The command line is for software engineers, to script actions that need repeat-ability or scheduled execution. An eff'ing emoji? Who would I send one to - Microsoft support, when my Zune crashes?

    • I've seen many projects that use emoji in git commits for various things. I would assume being able to see these Unicode characters would be a big help to some people.

    • by Waffle Iron ( 339739 ) on Monday May 06, 2019 @08:05PM (#58549488)

      Who the hell needs emojis in a shell? Da fuq, Microsoft?!

      To be fair, I just tried pasting a chunk of text from the Wikipedia "emoji" article into my XFCE terminal in Linux, and all the emojis rendered correctly (although in monochrome) in the terminal. It's a feature that I never knew I had.

      Maybe I should use this capability to have the prompt string display a pile of poop whenever the previous command failed.

      • I just tried pasting a chunk of text from the Wikipedia "emoji" article into my XFCE terminal in Linux, and all the emojis rendered correctly (although in monochrome) in the terminal.

        They should have rendered in color, they do in my xfce-terminal. What happens if you enter a unicode sequence by hand? Ctrl+LeftShift+u and then the sequence, try 1f6a6 That should get you a vertical traffic light with red, yellow and green lights.

        Maybe I should use this capability to have the prompt string display a pile of poop whenever the previous command failed.

        This will work:

        command && echo ðY(TM) || echo ðY'©

    • I prefer Unicode to ASCII in a shell because then I can process my native language. One man's heavy metal emoji is another man's regular letter.

      Now, having Unicode contain emojis is another problem. Back in the day, we had things like :-j and d^_^b and we liked it! It's basically forming words out of letters, instead of using a separate "letter" for each meaning. Kids today will have trouble expressing themselves in written language if all they learn is to use ready-made emojis. Probably affects their cr

    • No one. That doesn't mean it is better if the shell prints gibberish just because someone put an emoticon in something else and you happened to use the shell to display the text in question.

  • Like support for copy and paste via standard shortcuts, and mouse support so we can select text by dragging.

    • Like support for copy and paste via standard shortcuts, and mouse support so we can select text by dragging.

      You're in luck! Those are both available already in the Windows 10 console. Right-click on the title select properties. Then under the "options" tab you will find the following:
      Enable Ctrl key shortcuts
      Enable line wrapping selection

      • That does work in cmd.exe, but I can't make it work in the Linux subsystem bash shell; I get nothing the first time I hit ^V, and I get a literal ^V (the control character) if I hit ^V again. Have you been able to make it work in the Linux subsystem shell?

    • That's just crazy talk! Who would want basic functionality we've had in linux for 20+ years?

      • That's just crazy talk! Who would want basic functionality we've had in linux for 20+ years?

        Microsoft, which is why the Windows 10 console has supported this basic functionality out of the gate.

  • WSL is mostly a toy (Score:5, Informative)

    by execthis ( 537150 ) on Monday May 06, 2019 @01:37PM (#58547552)

    I have used Cygwin heavily for years and not long ago evaluated WSL and found it mostly worthless for anything serious. The inability to run daemons at startup severely limits its usefulness. It cannot replace Cygwin which is still much more mature and valuable.

    That emoji support is being touted kind of confirms the toy-ness of it.

    • By the way, as far as terminals go, ConEmu [github.io] is the best.

      • by Dunkirk ( 238653 ) *

        And it's telling, that this is the best alternative.

        I read an article awhile back (which I can't find now) that talked about the deep and extensive work it's taking to allow us to finally (finally!) have a real terminal on Windows. It's not surprising that they've taken this long to do so, and tied it in with a new WSL. It's a LOT of work, which will impact a LOT of existing code.

      • You can run wsl with conemu. And yes, works great.

    • pffff. cygwin is the toy. you can easily run wsl at startup.

    • WSL also has threading issues and os issues. This will be fixed in later versions. I went back to cygwin because its faster. Cygwin is great, WSL might over take it someday, you can also follow the WSL github to see whats going on. But for now, Cygwin is much faster.

      • JEsus, that's saying something if the monumental kludge that is Cygwin is faster than WSL. Using Cygwin was like extracting toenails with a prybar.

        • Using Cygwin was like extracting toenails with a prybar.

          What part of it did you find to be especially painful, besides all the stuff that won't compile cleanly under it?

          • That it wasn't that fast. It was really quite agonizingly slow. But it has been about ten years since I last used it, so perhaps it's come a long way.

            I did manage to get a Radius server to compile in Cygwin, so while it was painful, it actually saved my skin back in the day.

            • I've noticed that the time to acquire an I/O handle under Windows is exceedingly slow all which affects all manner of Un*x operations (you can write a toy program in C which simply opens a file, writes a single character and then exits). Since everything from 'git status' to 'grep myString * -R' requires using file handles, Unix-y command line stuff is several orders of magnitude slower on a Windows system. It's not the file system either -- you can mount a drive FAT32 in Linux and still notice that Windows

    • It cannot replace Cygwin which is still much more mature and valuable.

      It can replace cygwin just fine. Your little edge case just affects you.

      That emoji support is being touted kind of confirms the toy-ness of it.

      So you understand such little about what you're talking about that you combined news of emojis and WSL even though the former is being talked about in relation to a completely different project than WSL?

      To clarify the stupidity, no WSL is not getting "emoji support". The two aren't even in the same paragraph in the summary.

      Now please, less frothing at the mouth and more using that squishy thing between your ears.

  • by PPH ( 736903 ) on Monday May 06, 2019 @02:20PM (#58547836)

    ... John Deere unveils a new spoiler for its line of backhoes.

  • The enhanced terminal will also improve the experience of using the native ssh program in Windows inside a command prompt or PowerShell window. (Also true for telnet but who uses that any more?) Serious ssh users probably have putty or something like it installed, but if you only occasionally use ssh to connect to remote systems it's a significant plus.

Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P.D. Ouspensky

Working...