Der Befehl wsl ist entweder falsch geschrieben oder konnte nicht gefunden werden

Führt man Linux in einer VM unter Hyper-V oder VMware aus, dann findet sich das gesamte Dateisystem des Open-Source-OS gekapselt in einer VHD- oder VMDK-Datei. Das neue Subsystem für Linux hingegen verwendet keinen Hypervisor, vielmehr sorgt es dafür, dass ELF64-Binaries unmodifiziert unter Windows 10 starten können.

Windows-Subsystem für Linux aktivieren

Voraussetzung für den Linux-Support ist eine 64-Bit Version von Windows 10 ab Build 14316. Die Inbetriebnahme erfolgt relativ einfach. Zuerst wechselt man unter Einstellungen => Update und Sicherheit => Für Entwickler in den Entwicklermodus.

Anschließend kann man in der Systemsteuerung unter Programme => Windows-Features aktivieren oder deaktivieren die Komponente Windows-Subsystem für Linux auswählen. Damit diese Aktion wirksam wird, muss man den Rechner neu starten.

Update: In den letzten Releases von Windows 10 ist es nicht mehr nötig, den Entwicklermodus zu aktivieren. Über PowerShell lässt sich das Feature nun so installieren:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Eigene Ubuntu-Umgebung für jeden Benutzer

Nach dem Reboot ist das Ubuntu on Windows noch nicht zu sehen. Gibt man den Begriff bash in das Suchfeld ein, dann öffnet sich ein Konsolen­fenster, das die Linux-Programme erst einrichtet. Aufschlussreich ist dabei, dass die Ubuntu-Umgebung als Appx-Paket vom Windows Store heruntergeladen wird.

Update: Seit das Subsystem für Linux das Beta-Stadium verlassen hat, kann man es explizit über die Store App installieren.

Bekanntlich installiert Windows diese neuen Anwendungen nicht für alle Benutzer gemeinsam unter %ProgramFiles%, sondern für jedes Konto separat. Mithin erhält jeder Benutzer auf einem Windows-10-Rechner eine eigene Kopie der Linux-Shell und der dazugehörigen Konsolen­programme.

Linux-Verzeichnisstruktur unter %LOCALAPPDATA%

Die von Linux bekannte Verzeichnisstruktur mit /etc, /bin, /sbin, /usr, /var, etc. findet sich deshalb im jeweiligen Profil des Users, und zwar unter %LOCALAPPDATA%\­lxss\rootfs. Dort existiert auch wie gewohnt ein Verzeichnis /home, aber das Linux-Subsystem nutzt für die Heimat­verzeichnisse stattdessen den Pfad %LOCALAPPDATA%\lxss\­home\%USERNAME%.

Wechselt man in der Eingabeauf­forderung nach %LOCALAPPDATA%\­lxss\rootfs\bin und versucht dort die bash zu starten, dann ist es keine Überraschung, dass dies nicht gelingt. Die Shell liegt im ELF64-Format vor, mit dem cmd.exe nichts anzufangen weiß.

Update: Unter Windows 10 1809 haben sich die Pfade geändert. Das rootfs findet sich hier unter

%LOCALAPPDATA%\Packages\<PackageFamilyName des AppX-Pakets>\LocalState

Den Namen des Appx-Verzeichnisses kann man in PowerShell mit

(Get-AppxPackage -Name *ubuntu*).PackageFamilyName

erfragen. Um zum übergeordneten Verzeichnis von rootfs zu wechseln, könnte man

cd (-join("$env:LocalAppData\Packages\", `
(Get-AppxPackage -Name *ubuntu*).PackageFamilyName + "\LocalState"))

eingeben.

Windows-Laufwerke unter /mnt

Startet man die Shell hingegen über das bash-Icon im Startmenü und bewegt sich durch den Verzeichnisbaum, dann ist man nicht auf die Struktur unterhalb von %LOCALAPPDATA%\lxss beschränkt. Vielmehr mountet das Subsystem für Linux alle Windows-Laufwerke unter /mnt, beispielsweise c: unter /mnt/c. Dies erfolgt allerdings nicht von innerhalb der Ubuntu-Instanz, wie man sich mit mount mnt überzeugen kann.

Auf diese Weise hat man Zugriff auf das gesamte Dateisystem von Windows und kann beispielsweise Dateien kopieren zwischen den beiden Home-Verzeichnissen, die jeder Benutzer erhält. Jenes für Ubuntu befindet sich innerhalb der bash unter $HOME, während sich das von Windows über /mnt/c/users/<username> erreichen lässt.

Verschiedene Dateisysteme

Hinter rootfs von Linux liegt ein anderes Dateisystem als in /mnt/, Microsoft bezeichnet es als VolFs (im Gegensatz zum DriveFS unter /mnt). Dieser Unterschied ist nicht nur theoretischer Natur, sondern hat praktische Konsequenzen.

Nur unter VolFs lassen sich Dateirechte mit Unix-Tools wie chmod oder chown verwalten, außerdem sind dort Dateinamen zulässig, die Windows sonst nicht akzeptiert (die etwa einen Doppelpunkt enthalten können). Außerdem unterscheidet dieses Dateisystem zwischen Groß- und Kleinschreibung, so dass test.dat und Test.dat im gleichen Verzeichnis existieren können.

Erhöhte Rechte über sudo

Bevor man sich nach der Installation des Ubuntu-Packages am Linux-Subsystem anmelden kann, erwartet es seit dem Build 14328 die Eingabe eines Namens und des Passworts für einen User, den das System danach anlegt. Man arbeitet mithin jetzt nicht mehr wie in der ersten Beta unter der root-Kennung.

Der frisch angelegte User ist mit reduzierten Rechten ausgestattet, die man bei Bedarf mit Hilfe von sudo anheben kann. Dies ist etwa notwendig, wenn man das Passwort eines anderen Kontos mit passwd zurücksetzen oder einen neuen User mit adduser anlegen möchte.

Auch hier dürfte es keine Überraschung sein, dass ein neues Konto, welches man innerhalb der Linux-Parallelwelt anlegt, unter Windows unbekannt bleibt. Wie üblich trägt adduser den Account in /etc/passwd ein, hat aber keinen Zugriff auf die Benutzerverwaltung von Windows. Und nachdem sich das Linux-Dateisystem im Profil eines Windows-Benutzers befindet, kann jeder seine eigenen Linux-Konten anlegen.

Hey Dariusz, with Cygwin i used PRTG > -BAT File > bash.exe I would like to keep it that way using WSL, but i only get the above mentioned error. So currently i use PRTG > bash.exe

If i use PRTG > bash.exe i need to call it like that:

If i can use PRTG > BAT File > bash.exe, i can solely focus on the actual scripts bash.bat

some_script.sh param-1 param-n

Tha later also has the advantage that i can have installations that differ from each other (like script files in /usr/local/some_other_folder/same_script_name.sh, which is important if i want to move/copy sensors/devices to other probes (without the need of checking how scripts are executed at that particular remote probe)

I hope this is now clear enough :D

I'm trying to execute commands on WSL2 (Windows Subsystem for Linux) using python subprocess.

From the powershell and cmd the command wsl -l is working.

When I'm using python subprocess like this:

I'm getting the error that the command "wsl" is misspelled or not found. (I'm sorry for the german, but this is the original error message: Der Befehl "wsl" ist entweder falsch geschrieben oder konnte nicht gefunden werden.)

I also applied the fix listed in the troubleshooting section here https://docs.microsoft.com/en-us/windows/wsl/install-win10#troubleshooting-installation but it did not help.

Thanks for any help :)