I have successfully installed WSL 2 and Ubuntu on my windows machine. If I start PowerShell and type bash it successfully starts bash.
However if I run PowerShell as Administrator and type bash I get the following message:
Windows Subsystem for Linux has no installed distributions.
Distributions can be installed by visiting the Microsoft Store:
https://aka.ms/wslstore
Worst part is that I'm pretty sure this worked yesterday(!)
I downloaded Git Bash then my laptop crashed once it got installed. It won't restart at all.. it is windows 10.. I am using DEll. what should i do?
by crash i mean my laptop is off completely.
I have built an linux application by python, pyqt5, django and pyinstaller and I have added desktop shortcut to lunch from start menu. When I run the app on command line there is no problem. But when I run the app by desktop shortcut and exit it then the app close everything on genome session and log out.
The app is working well. Only the problem is happening when I exit the app.
My system is Ubuntu 18.04 and I keep latest upgraded.
The app use QWebEngineView on pyqt5.
I recently installed Ubuntu for Windows and now inside the Start Menu there are 2 new items:
Bash
Bash
This terminal opens in:
root#myName-PC:/mnt/c/Windows/System32#
Ubuntu
Ubuntu
This terminal opens in:
root#myname-PC:~#
What is the difference between the two?
For example, we want to install Git and Utils, RVM (Ruby) then clone a Git project and deploy via SSH with Capistrano commands. Should that be run with Bash or Ubuntu as above?
Also, should the commands be run in system32 or C:/ folder when inside the terminal?
Thanks
The Bash terminal is the old style (prior to Windows 10 v1790 a.k.a. Fall Creator Update). It resides in %LocalAppData%\Lxss and is managed using lxrun.exe.
The Ubuntu terminal is the new style, downloaded from Microsoft Store. The launcher part is a Windows App (%ProgramFiles%\WindowsApp) and its data resides in %LocalAppData%\Packages.
Those are two isolated installation of Windows Subsystem for Linux and do not interfere with each other. Practically you need only one of them, so choose one at your own preference.
I personally dislike the Windows Store version as it can be easily removed, which isn't a good thing for a productivity environment.
I was trying to delete the legacy "Bash on Windows" and wasn't unable to because lxrun.exe is not available in my system. But in case anyone needs it, here's how:
If you wish, you can manually delete your legacy instance. This may be required if you encounter issues uninstalling the legacy distro using lxrun.exe, or are running Windows 10 Spring 2018 Update (or later) which do not ship with lxrun.exe.
To forcefully delete your legacy WSL distro, delete the %localappdata%\lxss\ folder (and all it's sub-contents) using Windows' File Explorer, or the command-line: (using PowerShell)
rm -Recurse $env:localappdata/lxss/
The git bash vs the Ubuntu bash.
Basically there is nothing much different except maybe the versions of the bash. Because bash is bash. It's most likely different versions of bash were installed at different times for different purposes on the PC. And they will also likely be found in different folders on the PC.
Run the following code from the two different shells. This returns the version of bash:
echo "$BASH_VERSION"
On this PC, using the two terminals (MinGW and Ubuntu) returned the following versions of bash: (see image link below)
5.0.17(1) - release
4.4.23(1) - release
It's likely most people using PCs that have been around a while will find that there are two (or more) different versions of bash installed on their PCs. On this PC, the older version of bash was installed some time back.
That older version of bash might have been installed when Cygwin was installed on this PC. Or maybe the older version of bash was installed when Git was installed long ago. It really doesn't matter now. On this PC, bash is found in at least these following locations:
C:\cygwin64\bin\bash.exe
C:\Program Files\Git\bin\bash.exe
C:\Program Files\Git\git-bash.exe
The Windows 10 on this PC was updated. Specifically, the WSL kernel was updated from WSL to WSL2. Part of this update involved turning on some Windows features, including the: Windows Subsystem for Linux.
There was an old (virtual) version of Ubuntu (18.04) that had been installed on this PC some time back. But that old version of Ubuntu went away with this update. This WSL2 update changes the way Linux (Ubuntu) operates on this PC. After the WSL2 update, Ubuntu was installed from the Microsoft Store. This is Ubuntu 20.04.
This WSL2 update and the newly installed version of Ubuntu also installed a newer version of bash on this PC. And this newer version of bash is the newer version of bash that is showing above.
Another good way to understand the difference between these two versions of bash would be to enter the following into each shell:
type ping
The result should clearly show that one version of bash is providing the source from Windows while the other version of bash provides the source from Ubuntu.
ping is /c/windows/system32/ping
ping is /usr/bin/ping
Sometimes a picture is worth more than a thousand words. Attached below are two of the new Windows Terminals side by side.
These terminals show the two different versions of bash. Echo returns the older version of bash being used in the MinGW shell and Echo returns a newer version of bash being used in the Ubuntu shell.
Okay so I am deploying a program via SCCM 2012 to all of our laptops at our corporate office. I have the program for the package install with administrative rights so it is running under the SYSTEM account. This works perfectly on all of our Windows 7 PC's, however all of my Windows 8.1 laptops/tablets are returning error code -3 to SCCM. This means the required data was not found in the setup.iss file. I did some testing and ran the batch file that is kicking all of this off with PSEXEC -s on a windows 7 machine and it exited with code 0, so a successful install as I had expected. When I run this same test on a Windows 8.1 machine it exits with code -3 just as I was seeing in my SCCM console. I tried to recapture a new setup.iss by recording the install on that windows 8.1 machine and used that .iss in the PSEXEC test and got the same result. The kicker is that if I open an elevated command prompt and kick off the batch the program installs! So there seems to be something different with how the SYSTEM account is handling this batch file in Windows 7 vs Windows 8. Has anyone else seen something like this or have any idea why it would be failing when run as SYSTEM only on Windows 8.1?