What's the difference between using an Ubuntu tab on Windows Terminal vs using the Ubuntu app for Windows (ubuntu.exe)?
I've only noticed that each start at a different directory:
WT: :/mnt/c/Users/username
Ubuntu: /home/username
There are many differences between using an Ubuntu tab on Windows Terminal vs using ubuntu.exe on it's own:
Both are terminal applications that use 'Console Windows Host' (conhost.exe) however Windows Terminal is superior in features, is open source, has many improvements over 'ubuntu.exe' (and wsl.exe) and Windows Terminal utilizes two additional programs when it is run, OpenConsole.exe and windowsTerminal.exe.
These two programs OpenConsole.exe and windowsTerminal.exe are what makes all the new features in Window Terminal possible such as configurable starting locations, custom color schemes, full color support and much much more. There is a little history as to the origins of Windows Terminal and what I am talking about here.
ubuntu.exe and wsl.exe on their own (with plain old conhost.exe) are really just here for backwards compatibility at this point.
Related
Recently switched to new windows terminal, and after hours of searching on internet I was not able to find anything helpful, all what I want is to set up cmd inside new windows terminal to show git branches just like it's achievable for powershell.
eg like this
I have been very comfortable with cmd especially with its ability to use additional linux commands and don't wanna switch to powershell only because of nice displays of git branches. this is a source where everything is nicely explained for powershell, all I want is to do the same for CMD.
thanks in advance
In order to use Oh My Posh for shell-prompt customization from cmd.exe, the legacy Windows shell (citing from the docs (tab cmd)):
There's no out of the box support for Windows CMD when it comes to custom prompts. There is however a way to do it using Clink, which at the same time supercharges your cmd experience. Follow the installation instructions and make sure you select autostart.
As you later discovered, this issue on GitHub has background information on why native cmd.exe support isn't possible (even though Oh My Posh is generally shell-agnostic) and why third-party software is needed to make it work.
As for your comments re preferring cmd.exe:
I have been very comfortable with cmd
Migrating from the shell one is used to a new one is undoubtedly a painful transition, but well worth considering in this case:
While not without its quirks, PowerShell is vastly superior in just about every respect to cmd.exe, and enables you to do things you simply cannot do in cmd.exe
its ability to use additional linux commands
Linux (WSL) commands called from the Windows side are all mediated via executables (notably wsl.exe and bash.exe), which you can equally call from PowerShell.
Before I knew about the remote WSL extension for vscode, I had been using bash in it by selecting it as the default shell from the terminal option. What is the advantage of using remote WSL if all I wanted was to just use bash as the default terminal?
Hi Rohan and welcome to SO!
I'll have a shot at answering this, though someone more knowledgeable might have better insight.
When you load VSCode in windows, it accesses your various PC resources as windows resources. For example your files will be from the windows folder structure. Even if you use WSL bash as your terminal, VSCode is still acting on a windows basis.
If you use the remote WSL extension, it leverages VSCodes separation of UI and Backend by remotely starting a VSCode backend in the WSL layer, and connecting the windows UI to that backend ('remotely' although on the same PC). Due to running the backend in a linux environment, the files are loaded as linux files and handled via the WSL system, rather than normal windows access.
With regard to the question 'What is the advantage?' I would suggest the advantage is that now instead of having a split between VSCode in windows and command line in WSL, you now have both acting in harmony through WSL. It should provide some benefits (especially when WSL2 hits properly and performance increases) around things not messing in a windows manner on files you are trying to use in a linux way, and just make things feel a bit more connected.
However if you're using WSL bash just as a command line replacement and not using it for it's linux goodness (though I don't know if this would be the case), there may be less of an advantage.
It's a stepping stone to switching to devcontainers, which are really neat.
This page might help more, but that's my understanding! https://code.visualstudio.com/docs/remote/wsl
I have been looking for a way to open a cmd on my Chromebook. I have tried downloading file converters that aren't blocked. That didn't work. Any one know how to open a cmd on Chromebook. Also by the way this is my school computer.
I assume you meant "shell".
Press CTRL – ALT – T and you will have a browser-based shell known as Crosh.
You can't. CMD is a Windows NT and OS/2 command prompt (plus there is a NT4 and Win2000 port to Win9x). It doesn't work on other operating systems. You can't run Windows programs on toy OSs like Chrome.
What's the difference between a graphical shell and a desktop environment?
I keep hearing how
GNOME 3, KDE Plasma Shell and Unity are shells.
and how GNOME 2, XFCE and LXDE are desktop environments.
Is it that the interface is the Shell and all the rest of the software is the desktop environment, if this where true wouldn't that make GNOME Panel a shell?
"Desktop environment" (DE) is the whole shebang. The "desktop shell", on the other hand, is just the bit that provides the background, task-bar, desktop icons, desktop context menus: generally the "home" interface for a particular DE. (The functionality/scope of the shell can vary greatly as well as include and/or overlap the roles of a Window Manager, especially in an X-based system.) The "shell" for Windows is "explorer.exe" but Windows itself is the "desktop environment".
Generally file managers, like Nautilus, are not [desktop] shells: e.g. they can [often] be run without the standard "shell" (or with a different shell). However, it is quite possible that a file-manager acted as a shell. In the case of [modern] Windows the same executable is used for both the shell and the file-manager, but perhaps hosted in a different process, and yet it serves a different purpose in both roles. (Windows 3.1 had a separate FileMan program.)
Happy exploring.
Desktop environments, such as Explorer, ARE graphical shells because they provide an interface for users to access the services of the kernel.
I'm doing a fair bit of work in Ruby recently, and using
ruby script/console
Is absolutely critical. However, I'm really disappointed with the default Windows console in Vista, especially in that there's a really annoying bug where moving the cursor back when at the bottom of the screen irregularly causes it to jump back. Anyone have a decent console app they use in Windows?
I use Console2.
I like the tabbed interface and that copy works properly if text breaks at the end of a line.
Are you resizing the console window? I've found that the ruby scripts (irb, etc) that use the readline library don't work correctly with resized console windows (in XP or Vista).
Effectively I believe that the readline library expects the console window to be 80 characters wide, anything else and it goes bezerk. So far I haven't found a way to fix it on windows without giving up other nice features.
I have had some pleasant experiences with rxvt (comes with cygwin, does not need an x server running). Putty is also often mentioned as a good alternative.
You could also try to get xterm working :)
Powershell
Windows PowerShell is Microsoft's task automation framework, consisting of a command-line shell and associated scripting language built on top of, and integrated with the .NET Framework. PowerShell provides full access to COM and WMI, enabling administrators to perform administrative tasks on both local and remote Windows systems.