Schleppender Verkaufsstart von Windows 8

[ggrohmann]

Nun erklär mir doch mal, was an der Frage, ob jemand nicht über Windows hinausgekommen ist, denn polemisch sein soll? Beantwortet mir derjenige die Frage mit ja, dann weiß ich, warum er mir nicht zufriedenstellend antworten kann. Weicht er der Frage aus, muß ich annehmen, daß sein Erfahrungshorizont eben auf Microsoft-Systeme begrenzt ist. Oder derjenige stellt eben doch halbwegs erstaunt fest, daß MS nur eine sehr eingeschränkt brauchbare Kommandozeile mitliefert, die noch nicht einmal Features enthält, die ich schon 1994 unter Solaris benutzt habe.

edit: Huch, warum ist denn der Beitrag schon mal halb da?

Aber ok, gleich die Antwort: Nein, ich stelle Windows-Benutzer nicht pauschal als dumm hin. Ich hab aber sehr wohl was dagegen, wenn mich jemand für dumm verkaufen will.

Guido

 

[schoerg]

Und jetzt zeigt mir doch bitte bitte bitte eine brauchbare Kommandozeile, die im Lieferumfang von Win dabei ist, ja?

Und für schoerg nochmal: brauchbar!

Guido

Brauchbar liegt vielleicht im Können des Anwenders. Bei mir macht übrigens die Autovervollständigung bei cd nur Ordnervorschläge, also vermutlich ein Fehler deinerseits.
Ich finde die bash auch eine bessere Kommandozeile, allerdings bezweifle ich nicht, dass man mit der Powershell auch die gleichen Sachen fabrizieren kann, mangels konkreter Nutzungsfälle musste ich das jedoch noch nie tun.

 

[ggrohmann]

Brauchbar liegt vielleicht im Können des Anwenders. Bei mir macht übrigens die Autovervollständigung bei cd nur Ordnervorschläge, also vermutlich ein Fehler deinerseits.

In welcher Kommandozeile und unter welcher Windows-Version? Falls nicht im Auslieferungszustand, was hast du wo eingestellt?

Guido

 

[schoerg]

In welcher Kommandozeile und unter welcher Windows-Version? Falls nicht im Auslieferungszustand, was hast du wo eingestellt?

Guido

cmd und Powershell bei Win7 und Win8, eingestellt hab ich nichts.

Hier ein kurzes Video: [video]http://pwnhofer.at:8080/screenshots/capture-3.mp4[/video]

 

[Gummiente]

Wie ist aus Windows 8 ein Shell Thread geworden?

Egal, hier mal mein Senf...

Zu DOS Zeiten hat man die Probleme des Command.com, dem Kommandozeileninterpreter AKA Shell erkannt und versucht Auswege zu finden. Zum einen gab es eine "GUI" in Form von Norton Commaner das wie die Einordnung in die Kategorie GUI vermuten lässt nicht zum Skripten taugte. Das andere war 4dos.com ein Drop-In-Replacement für Command.com. Sehr brauchbar dank erweiterter Kontrollstrukturen und eingebauten Befehlen. War auch für nichttriviale Skripte geeignet.

Als DOS aber doch von Windows abgelöst wurde gab es keinen Markt mehr für Kommandozeileninterpreter. Wie skriptet man "den dritten Karteireiter anklicken, aus dem vierten Drop Down Menu den zweiten Punkt wählen, anschließend Häken 2, 5 und 7 setzen, 1, 8 und 9 aber wegklicken und dann ok drücken"? Auch fehlten die Windows Entsprechungen von Shell- und Fileutilities bzw. Coreutilities die ein Shell erst nützlich machen. Wer z.B. Bash, Tcsh, Zsh etc. mit Cygnus auf Windows installiert wird sehr erstaunt sein, dass diese Schweizer Taschenmesser für McGuyver unter Windows so gar nichts ausrichten können.

Mit Powershell ist mal wieder ein typisches Windows Produkt entstanden wo das Rad ständig neu erfunden wird. Ich vermute sie wollten unbedingt vermeiden, Windows Administratoren eine Highway in Richtung *nix zu bauen wo das Skripten so elegant sein kann...

 

[ggrohmann]

cmd und Powershell bei Win7 und Win8, eingestellt hab ich nichts.

Hier ein kurzes Video: [video]http://pwnhofer.at:8080/screenshots/capture-3.mp4[/video]

Ich habe mal getestet: Win XP, 2003, 2003R2, Win7 Home Premium und Professional sowie Win 8. Seit Win 7 (Vista und 2008 habe ich nicht) geht das also. Interessant.

Guido

 

[Jogi-B]

Wie ist aus Windows 8 ein Shell Thread geworden? Egal, hier mal mein Senf... Zu DOS Zeiten hat man die Probleme des Command.com, dem Kommandozeileninterpreter AKA Shell erkannt und versucht Auswege zu finden. Zum einen gab es eine "GUI" in Form von Norton Commaner das wie die Einordnung in die Kategorie GUI vermuten lässt nicht zum Skripten taugte. Das andere war 4dos.com ein Drop-In-Replacement für Command.com. Sehr brauchbar dank erweiterter Kontrollstrukturen und eingebauten Befehlen. War auch für nichttriviale Skripte geeignet.

Oha, einer von der alten Garde Aber recht hat er.

 

[ggrohmann]

Wie ist aus Windows 8 ein Shell Thread geworden?

Als DOS aber doch von Windows abgelöst wurde gab es keinen Markt mehr für Kommandozeileninterpreter. Wie skriptet man "den dritten Karteireiter anklicken, aus dem vierten Drop Down Menu den zweiten Punkt wählen, anschließend Häken 2, 5 und 7 setzen, 1, 8 und 9 aber wegklicken und dann ok drücken"? Auch fehlten die Windows Entsprechungen von Shell- und Fileutilities bzw. Coreutilities die ein Shell erst nützlich machen. Wer z.B. Bash, Tcsh, Zsh etc. mit Cygnus auf Windows installiert wird sehr erstaunt sein, dass diese Schweizer Taschenmesser für McGuyver unter Windows so gar nichts ausrichten können.

Das kann ich jetzt so nicht nachvollziehen, die Gnu-Tools verwende ich recht häufig unter Windows. Allerdings meist im Zusammenhang mit Produkten, die nicht von MS stammen.

Mit Powershell ist mal wieder ein typisches Windows Produkt entstanden wo das Rad ständig neu erfunden wird. Ich vermute sie wollten unbedingt vermeiden, Windows Administratoren eine Highway in Richtung *nix zu bauen wo das Skripten so elegant sein kann...

Den Eindruck habe ich auch, wobei Powershell recht nützliche Funktionen z.B. zum Umgang mit der Regsitry enthält, für die man früher z.B. auf das Resource Tool Kit zurückgreifen mußte. Das Konzept der Skriptsprache Powershell ist objektorientiert und nicht mehr [text|zeichen]basiert, wie man es unter X gewöhnt ist. Bis NT4 gabs auch noch eine Posix-Erweiterung für Windows, die aber irgendwelche Einschränkungen hatte und mit Win2K entfiel.

Guido

 

[ggrohmann]

Oha, einer von der alten Garde Aber recht hat er.

Dann kennt er bestimmt auch noch die DosShell, die mit MSDOS 4 kam.

Guido

 

[schoerg]

Bis NT4 gabs auch noch eine Posix-Erweiterung für Windows, die aber irgendwelche Einschränkungen hatte und mit Win2K entfiel.

Wenn du dich wenigstens mal vorher informieren würdest bevor du postest. :facepalm:

Es gibt natürlich weiterhin das POSIX-Subsystem.

 

[caputo]

Mit Powershell ist mal wieder ein typisches Windows Produkt entstanden wo das Rad ständig neu erfunden wird. Ich vermute sie wollten unbedingt vermeiden, Windows Administratoren eine Highway in Richtung *nix zu bauen wo das Skripten so elegant sein kann...

Microsoft hat einfach auf die Basis gesetzt, die in Windows da war (.Net) und nicht auf das, was nicht da war (die Unix-Kommandozeilentools). Skripten kann man mit der Powershell wunderbar, und im Gegensatz zur Unix-Shell kann Powershell Objekte pipen, was meiner Meinung nach deutlich eleganter ist, als die Unix-Variante, wo alles zu Text gemacht wird und entsprechend auch wieder aus Text geparst werden muss.
Dass ggrohmann ein Problem damit hat, dass man bei Powershell das Kommandozeilenfenster ein paar Features weniger hat als Unix-Shells, man aber für größere Geschichten / allem wo das Kommandozeilenfenster nicht reicht halt die ISE nimmt, liegt meiner Meinung nach eher daran, dass er nicht versucht, ein bestimmtes Skripting-Problem pragmatisch zu lösen, sondern dass er negativen Betriebssystem-Evangelismus betreiben will.

 

[schoerg]

Ich habe mal getestet: Win XP, 2003, 2003R2, Win7 Home Premium und Professional sowie Win 8. Seit Win 7 (Vista und 2008 habe ich nicht) geht das also. Interessant.

Auch bei XP funktioniert das:

http://pwnhofer.at:8080/screenshots/xppro.mp4

 

[ggrohmann]

Wenn du dich wenigstens mal vorher informieren würdest bevor du postest. :facepalm:

Es gibt natürlich weiterhin das POSIX-Subsystem.

Du meinst sicher den Nachfolger "Microsoft Windows Services for UNIX".

Guido

 

[schoerg]

Genau.

 

[Gummiente]

Microsoft hat einfach auf die Basis gesetzt, die in Windows da war (.Net) und nicht auf das, was nicht da war (die Unix-Kommandozeilentools). Skripten kann man mit der Powershell wunderbar, und im Gegensatz zur Unix-Shell kann Powershell Objekte pipen, was meiner Meinung nach deutlich eleganter ist, als die Unix-Variante, wo alles zu Text gemacht wird und entsprechend auch wieder aus Text geparst werden muss.
Dass ggrohmann ein Problem damit hat, dass man bei Powershell das Kommandozeilenfenster ein paar Features weniger hat als Unix-Shells, man aber für größere Geschichten / allem wo das Kommandozeilenfenster nicht reicht halt die ISE nimmt, liegt meiner Meinung nach eher daran, dass er nicht versucht, ein bestimmtes Skripting-Problem pragmatisch zu lösen, sondern dass er negativen Betriebssystem-Evangelismus betreiben will.

Der MS'sche Ansatz den ich nicht mag findet sich in einem so simplen Tool robocopy wieder. In einem Programm welches Dateien kopieren soll finden sich unter anderem ein Scheduler, eine Dateiüberwachung, Behandlung von Codepages und Loggingsystem. Was ist so kaputt an Cron, inotify, Locale und Stderr bzw. -out? Warum müssen diese Funktionen immer wieder implementiert und deren Nutzung immer wieder neu erlernt werden? Dass ich ein robocopy Job schedulen kann heisst nicht, dass ich gelernt hätte alles was ich will in zeitlichen Abständen ablaufen zu lassen. Unter Linux schon.

Ich finde es immer wieder frustrierend, dass Wissen nicht recyclet werden kann wie unter Linux. Etwas über Regex gelernt? Gratulation. Nun hast du eine solide Basis für Emacs, sed, Perl, awk, grep. Etwas über Pipes und Redirects? Wolltest du nicht schon immer mal die Logfiles entrauschen? Eine neue Option in "sort" gefunden? Da war doch etwas was ich immer etwas unübersichtlich fand?

So wächst der Wissenspool mit der Zeit zu einem Kontinent aber unter Windows? Nachdem ein Problem gelöst ist schaut man drei Monate später wieder rein wenn etwas geändert werden muss und versucht sich zu erinnern welche Schrauben man bei diesem Tool damals gedreht hatte. Lerne ich dabei etwas, dass nicht unmittelbar mit der Aufgabe zu tun hat? Nein. So bleiben die Tools Inseln ohne jegliche Verbindung zueinander.

Auch die ISE ist so typisch MS. Funktioniert nur mit Powershell. Dabei hätte sie doch so viel Potenzial. Oder warum nicht CMD.EXE aufbohren? Zeit genug hatte MS ja um die Nutzer behutsam zu erweitern und die Nutzer auf Entdeckungsreise zu schicken.

 

[ggrohmann]

Auch bei XP funktioniert das:

http://pwnhofer.at:8080/screenshots/xppro.mp4

Geht bei mir nicht - ich muß jetzt rausfinden, wieso.

Guido

 

[schoerg]

Geht bei mir nicht - ich muß jetzt rausfinden, wieso.

Guido

Ich hab in der VM XP Pro installiert, falls das hilft.

 

[caputo]

Der MS'sche Ansatz den ich nicht mag findet sich in einem so simplen Tool robocopy wieder. In einem Programm welches Dateien kopieren soll finden sich unter anderem ein Scheduler, eine Dateiüberwachung, Behandlung von Codepages und Loggingsystem. Was ist so kaputt an Cron, inotify, Locale und Stderr bzw. -out? Warum müssen diese Funktionen immer wieder implementiert und deren Nutzung immer wieder neu erlernt werden? Dass ich ein robocopy Job schedulen kann heisst nicht, dass ich gelernt hätte alles was ich will in zeitlichen Abständen ablaufen zu lassen. Unter Linux schon.

Ich finde es immer wieder frustrierend, dass Wissen nicht recyclet werden kann wie unter Linux. Etwas über Regex gelernt? Gratulation. Nun hast du eine solide Basis für Emacs, sed, Perl, awk, grep. Etwas über Pipes und Redirects? Wolltest du nicht schon immer mal die Logfiles entrauschen? Eine neue Option in "sort" gefunden? Da war doch etwas was ich immer etwas unübersichtlich fand?

So wächst der Wissenspool mit der Zeit zu einem Kontinent aber unter Windows? Nachdem ein Problem gelöst ist schaut man drei Monate später wieder rein wenn etwas geändert werden muss und versucht sich zu erinnern welche Schrauben man bei diesem Tool damals gedreht hatte. Lerne ich dabei etwas, dass nicht unmittelbar mit der Aufgabe zu tun hat? Nein. So bleiben die Tools Inseln ohne jegliche Verbindung zueinander.

Das was Du da bemeckerst funktioniert genau so mit Powershell. Du lernst die einzelnen Befehle und CmdLets kennen und kannst diese später in anderen Lösungen in anderer Form verknüpfen und dabei dein Wissen weiterverwenden.

Was das mit Robocopy zu tuna haben soll, verstehe ich ehrlich gesagt nicht ganz. Die erste Version von Robocopy ist von 1997 (NT4), dass da ein Task Scheduler mit dabei ist dürfte damit zu tun haben, dass damals (97) kein Task-Scheduler in den Windows-Standardinstallationen integriert war. Abgesehen davon ist es meiner Meinung nach wenig sinnvoll, im Jahr 2013 eine im Jahr 2006 eingeführte Shell dafür zu kritisieren, dass eine 1997 eingeführtes Tool nicht so geschrieben wurde, dass es zur 2006 veröffentlichten Shell passt. Ja, vor 2006 hatte Windows keine ordentliche Shell. Aber 2006 ist auch schon wieder lange her.

Ansonsten ist es auch relativ sinnlos, Windows dafür zu kritisieren, dass es Windows-Tools und nicht Unix-Tools verwendet. Das läuft darauf hinaus, Windows dafür zu kritisieren, dass es nicht Unix ist. Was genauso sinnlos ist, wie Unix dafür zu kritisieren, dass es nicht Windows ist.

 

[der_ingo]

Warum müssen diese Funktionen immer wieder implementiert und deren Nutzung immer wieder neu erlernt werden? Dass ich ein robocopy Job schedulen kann heisst nicht, dass ich gelernt hätte alles was ich will in zeitlichen Abständen ablaufen zu lassen. Unter Linux schon.

Nachdem man seit diversen Jahren auch unter Windows so etwas über den Taskplaner macht, lernt man auch damit etwas. Man lernt nämlich, dass robocopy noch Funktionen bietet, die heute nicht mehr gebraucht werden. Sie sind aber noch drin, um alte Scripte nicht kaputt zu machen.

Ich finde es immer wieder frustrierend, dass Wissen nicht recyclet werden kann wie unter Linux. Etwas über Regex gelernt? Gratulation. Nun hast du eine solide Basis für Emacs, sed, Perl, awk, grep. Etwas über Pipes und Redirects? Wolltest du nicht schon immer mal die Logfiles entrauschen? Eine neue Option in "sort" gefunden? Da war doch etwas was ich immer etwas unübersichtlich fand?

Ja, und hast du PowerShell gelernt, kannst du quasi jedes aktuelle Microsoft Produkt, was irgendeine Scripting-Fähigkeit bietet, damit ansprechen, steuern, programmieren. Vom Desktop Windows über den Server bis zu Exchange. Alles die gleiche Logik, die gleiche Sprache, die gleichen Werkzeuge. Ob Registry oder Umgebungsvariablen oder Verzeichnisse, alles der selbe Befehlssatz.

Auch die ISE ist so typisch MS. Funktioniert nur mit Powershell. Dabei hätte sie doch so viel Potenzial. Oder warum nicht CMD.EXE aufbohren? Zeit genug hatte MS ja um die Nutzer behutsam zu erweitern und die Nutzer auf Entdeckungsreise zu schicken.

Man hat CMD.EXE über die Jahre aufgebohrt. So gibts z.B. mittlerweile verschachtelte IF-Bedingungen, aber das hat halt alles Grenzen. Ich hab einige Zeit mit "TakeCommand" gescriptet, dem Nachfolger von 4DOS. Das ist genau das, was du da beschreibst, eine wahnsinnig aufgebohrte CMD.EXE. Und das hat ein paar Vorteile, denn man kennt viele Befehle schon. Es hat aber auch riesige Nachteile, weil man durch die alte Batch-Funktionalität einfach immer wieder beschnitten wird. Vieles was in PowerShell einfach gnadenlos einfach und schlicht ist, ist bei CMD unmöglich und bei TakeCommand umständlich.

 

[ggrohmann]

Ich hab in der VM XP Pro installiert, falls das hilft.

Ich auch, hier zuhause geht das jetzt auch. Ich benuzte auf Arbeit recht oft die die cmd und habe dort das Problem seit Jahren. Ich vermute nun als Auslöser für das Problem Richtlinien, die in den Domänen auf Arbeit eingerichtet sind. Ich bin aktuell zuhause, habe noch ein paar Tage Urlaub. Das kann ich aber nur dort überprüfen, indem ich einen Rechner in eine Domäne aufnehmen lasse und prüfe, ob sich nach der Anwendung der Richtlinien das Verhalten ändert.

Guido