Microsoft stellt Vorschau für das neue Windows Terminal im Store bereit

Microsoft hat das zur Entwicklerkonferenz Build vorgestellte neue Windows Terminal jetzt auch direkt als App im Microsoft Store zur Verfügung gestellt. Die App ist noch eine früher Preview und wird als Community-Projekt über Github weiterentwickelt. mehr... Microsoft, Tool, Build 2019, Terminal, Kommandozeile Bildquelle: Microsoft Microsoft, Tool, Build 2019, Terminal, Kommandozeile Microsoft, Tool, Build 2019, Terminal, Kommandozeile Microsoft

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
So, wie es aussieht, soll also das Kommandozeilen-Tool wie auch die Powershell in die Terminals einfließen? Also würden die Powershell und auch der klassische Dos-Prompt eines Tages weg fallen und alles zusammen über die Terminals laufen?

Fände ich nen guten Schritt. So würde man Batch und Powershell-Script in einer Ebene zusammen führen. Aber ob das so ist, weiß ich nicht. Kann die englischen Quellen nicht wirklich lesen, weil ich englisch als Sprache kaum bis gar nicht beherrsche. Naja, und was die zahlreichen Übersetzer aus technischen Texten machen, haben wir alle schon erlebt. Fenster 10 ist da noch das amüsantere Beispiel.

Edit: Rechtverschreiber korrigiert. ;-)
 
@Hanni&Nanni: Nein, das Terminal ist ein Container, dass parallel aber dennoch getrennt die Powershell, Cmd und Bash einbindet. Du musst also nicht getrennt die Shells in eigenen Fenstern öffnen, sondern öffnest einen neuen Tab und wählst dann die gewünschte Shell aus.
 
@Knarzi81: Also doch wieder ein Mischmasch. Hab echt gehofft, die würden mal aufräumen und zusammen führen.
 
@Hanni&Nanni: Das wäre das Falsche. Die Powershell bietet einfach zu viele Möglichkeiten, weshalb die Execution-Policy dort auch standardmäßig deaktiviert ist und Powershell-Skripte auch nicht direkt mit der Powershell gelinkt sind. Ein Doppelklick auf ne .ps1 Datei führt eben nicht das Skript aus. Dagegen gibt es aber dann immer noch die Cmd- und Batchskripte, die weniger können aber für viele Standardsachen wie Umgebungsvariablen setzen völlig ausreichend sind und auch on jedem auch mit wenig Ahnung direkt ausgeführt werden können. Es sind zwei verschiedene Konzepte, die sich nur marginal überschneiden.
 
@Knarzi81: Danke für die gute Erläuterung. Ich hab mich mit der Powershell nie so wirklich beschäftigt. Dahier mein Unwissen. Und benötigt, hab ich sie bisher auch noch nie. Von daher auch kein großes Interesse, mit der Powershell zu arbeiten.

So wie Du mir das jetzt erklärt hast, verstehe ich aber, warum man beides nicht in einem Tool zusammen fassen kann.
 
@Hanni&Nanni: Du kannst von der Powershell alle COM- als auch .Net-Framework DLLs laden und so direkt auf exportierte Programmierschnittstellen zugreifen. Du kannst direkt C#-Code parsen und ausführen. Du kannst WMI-Objekte laden und deren Funktionen ausführen usw.. Und darum sollte damit echt nur wer was machen, der auch weiß was er tut.

Kurz: Man kann alles verbiegen bis hin zu kleinen Anwendungen, selbst mit GUI damit schreiben.

Aber die Powershell ist am Ende nur ein Konsolenprogramm, dass innerhalb der CMD ausgeführt wird. So wie beispielsweise wie netsh.exe.
 
@Knarzi81: Das klingt so, alös seien ps1-Dateien wesentlich gefährlicher, als bat-Dateien, weshalb sie einen stärkeren Schutz benötigen.
Das ist aber Bullshit.
Hier mal ein kleines bat-Programm für Windows 8.1:

------------------

@echo off
echo using System; > halloDu.cs
echo public class Hallo { >> halloDu.cs
echo public static void Main() { >> halloDu.cs
echo Console.WriteLine("Hallo zusammen!"); >> halloDu.cs
echo }} >> halloDu.cs
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\csc.exe" halloDu.cs
.\halloDu.exe

--------------

Also erzähle mir keiner, daß man mit ps1-Dateien ja so viel mehr machen könnte.
 
Ist auch der neue Font dabei?

Es soll ja einen neuen Font für Programmierer dazu geben, der u.a. aus Zeichen wie <= und == und >= jeweils sich zu einem Symbol verschmilzt.

Unter
https://devblogs.microsoft.com/commandline/introducing-windows-terminal/
hieß es dazu

"You will also have the option of using our new font! We wanted to create a fun, new, monospaced font to enhance the modern look and feel of the Terminal. Not only will this font include programming ligatures, but it will also be open sourced and have its own repository. Stay tuned for more information on the new font project!"

Ist der Font in der Windows Terminal Vorschau enthalten?
 
@theuserbl: Bei mir ist als Font Consolas eingestellt. Weißt du wie der Font heißt?
 
@mlodin84: Ah, danke. Ich glaube, wenn der Font dabi wäre, dann wäre er auch standardmäßig eingestellt.
Kann man aber auch überrüfen, indem man in das Terminal "<=" schreibt und dann bei den Einstellungen, die Fonts der Reihe nach durchgeht (seeehr zeitintensiv). Wenn plötzlich statt "<=" dort "&#8804;" steht, ist es der Font. Aber wie ich schon schrieb, glaube ich nicht, daß er dabei ist. Denn dann wäre er defaultmäßig aktiviert.
Und danke für Deine Antwort.
 
@theuserbl: Die WinFuture-Forensoftware hat jetzt aus dem Unicode Kleinergleich-Zeichen ein "&#8804;" gemacht. :-(
Also wenn "<=" zu einem Gleinergleich-Zeichen wird, ist es der Font.
 
@theuserbl: Ich kann die Powerline-Fonts weiter empfehlen... wenn ich mich nicht irre, enthalten die auch die Ligatures.
 
Konfiguration in einem JSON File und nicht in der Registry, weia. Da hat man über Jahre eine flexible Lösung, die den einfachen Zugriff über definierte Schnittstellen erlaubt und dann kommt man mit so einem altmodischen Textdatei-Quatsch.

Im Moment schaut sich Microsoft irgendwie zu viele nervige Dinge aus der Opensource-Welt ab, die in Windows einfach nicht reinpassen.
 
@der_ingo: Schaut eher nach einer Übergangslösung aus
 
@Kendrick: die Änderungen direkt in der Datei zu machen ist sicherlich eine Übergangslösung. Aber man baut sowas nicht erst in eine JSON Datei, wenn man es hinterher in der Registry speichern will. Das dürfte also auch später so bleiben.
 
@der_ingo: Was stört dich daran? Finde JSON Files für Config und co super. Habe da all meine Einstellungen für VSCode drin. Es ist menschenlesbar und platformunabhängig.
Einfach die Datei in Dropbox oder co plazieren und dan mit mklink oder ln einen Hardlink zur erwarteten speiccherstelle machen. SO sind alle einstellungen auf allen Systemen syncron.

Fast alles in der Linux-Welt ist textbasiert was einstellungen angeht und so auch einfach anpassbar. Ich hasse es jedes mal wenn in in WIN in die Registry muss.
 
@henne_boy: es geht hier aber nicht um irgendein Projekt, welches jetzt besonders plattformunabhängig sein müsste, sondern an sich um eine reine Windows-Anwendung.

Dass die Linux-Welt das so macht, ist eine Sache. Das muss aber kein Vorteil sein. Unter Windows steuere ich alle möglichen Dinge zentral über GPOs sehr bequem. Dazu müssen die entsprechenden Einstellungen aber natürlich in der Registry sein. Ich setze damit für tausende PCs einzelne Einstellungen und sorge dafür, dass das innerhalb kürzester Zeit im laufenden Betrieb überall ankommt. Mach das mal mit irgendwelchen JSON Dateien.

Genauso einfach gehts per Powershell, selbst per Batch. Ich muss nicht erst irgendwelche Dateien parsen, sondern setze einfach die entsprechenden Werte in der Registry.

Ich kann auch nicht durch irgendwelche Syntaxfehler, fehlende Klammern oder gar fehlende Einrückungen die ganze Konfiguration zerlegen. Denn beim Ändern von Werten muss ich mir um das Format keine Gedanken machen. Um die Verwaltung kümmert sich das System. Die ganze Syntax und den Aufbau der JSON Dateien muss ich nicht lernen, nur um Konfigurationen zu schreiben.

Ich hab grad die Tage an einem aktuellen Ubuntu Server die Netzwerkeinstellungen ändern müssen. Die nutzen jetzt YAML Konfigdateien. Da muss man drauf achten, dass passend eingerückt wird. Und wenn man fürs Einrücken Tabs statt Leerzeichen verwendet, meckert das System. Behämmerter geht es nicht mehr.

Am Ende ist das auch noch weit langsamer, erst eine Textdatei zu parsen, dann auszuwerten und all das nur, um darin irgendeine Einstellung zu finden, anstatt eine binäre Datenbank abzufragen.
Microsoft hat sowas ja früher auch schon mal gemacht mit den Textdateien. Zu Windows 3.x Zeiten. Nannte sich .ini Dateien. Im Prinzip war das nicht anders. Zum Glück ist man davon weg.

Mit solchen Aktionen wie beim Terminal wirkt es, als wollte man wieder zu diesen dunklen Zeiten zurück.
 
@der_ingo: Da hst du recht, das sind gute Punkte, aber ich glaube hier haben wir eine klassische Unterscheidung zwischen Entwickler und Admin Präferenzen. Ich bin auch mal auf fremden PCs unterwegs und kann so einfach meine Einstellunken mitnhemen und habe nicht überall Root Zugänge.

Ich mache auch wenig mit PS. Dennnoch halte ich einen neuen Terminalemulator der alles bündelt für gut.

Sind halt unterschidliche Anforderungen die wir haben. So gut wie jeder Entwickler kann JSON und dies lässt sich einfach bearbeiten. Als Admin stelle ich mir das schwerer vor. Dein Beispiel mit YAML kann ich verstehen, das nervt auch. Als Tipp verwende einen Editor der Taos automatisch in Spaces umwandelt.

Man kann MS hier nicht wirklich was vorwerfen, da PS und CMD ja erhalten bleiben.

Dein Beispiel mit Skype kann ich auch verstehen, dass ist aber die ganze Industrie die sich dahin entwickelt und MS macht leider teilweise mit.

Geht halt viel auf JavaScript zu, da es überall wo ein browser ist läuft. Kein Anpassen kein neu Kopilieren für andere Geräte
 
@henne_boy: ich muss es ja deshalb aber noch nicht gut finden. ;-)
 
@der_ingo: vermutlich weil dann irgendwann mal das Windows (sic!) Terminal auch auf anderen Platformen verfügbar sein soll (auf denen es keine Registry gibt).
 
@scar1: Die haben normalerweise bereits ein Terminal, was vieles von dem sowieso schon kann, was Microsoft da grad für Windows neu baut. Um darin dann Powershell o.ä. auszuführen braucht es an sich auf anderen Systemen kein Microsoft Terminal.

Ich vermute, die junge Generation von Entwicklern ist von anderen Plattformen so "versaut", dass man auch dann so programmiert, wenn es um Windows alleine geht. ;-)

Ich meine hey, Microsoft nutzt auch Electron, beispielsweise für Teams und Skype. Kein normal denkender Mensch würde auf einem System für jedes Programm noch mal einen eigenen kompletten Browser im Hintergrund installieren und ausführen. Aber ist total hip und plattformunabhängig. Dass ein kleiner Messenger wie Skype jetzt 400 MB Ram und hunderte MB Plattenplatz braucht, ist dann völlig egal.

Das ist so kaputt. Es ist mir egal, in was für hippen und stylischen Sprachen oder Entwicklungsumgebungen die programmieren. Aber wenn das Software für Windows ist, dann muss da ein sauberes,natives Win32 Executable rauspurzeln, welches die Funktionen von Windows nutzt.

Vor 20 Jahren hat man uns sowas mit Java versprochen. Einmal schreiben, läuft überall. War erstens glatt gelogen und wenn, dann lief es überall mies. Mittlerweile haben wir das mit moderner Hardware erschlagen. Das ist dann leider oft die "Lösung": "wir programmieren so bescheiden, dass deine Kiste voll und langsam ist? Hey, kauf eine größere, schnellere Kiste!". So kann man die Wirtschaft auch ankurbeln.
Kommentar abgeben Netiquette beachten!
Einloggen

Jetzt als Amazon Blitzangebot

Ab 23:59 Uhr TP-Link Archer T2U NanoTP-Link Archer T2U Nano
Original Amazon-Preis
14,90
Im Preisvergleich ab
13,38
Blitzangebot-Preis
11,90
Ersparnis zu Amazon 20% oder 3