Hallo, ich bin gerade gezwungen mal wieder unter Windows zu arbeiten. cmd.exe ist ja ganz nett, aber ich vermisse da so folgende Möglichkeiten: - Terminal-Fenster auf die gewünscht Größe ziehen. - Anzeige aller möglichen Dateinamen mit TAB-TAB - Mehrere Konsolen als Tabs. - Suche nach abgesetzten Kommandos. - Einfaches copy/past! Ganz wichtig! Gibt es so etwas für Windows? Cygwin? mfg Torsten Edit: das wichtigste feature vergessen: Einfaches copy/past!
:
Bearbeitet durch User
Diek schrieb: > Torsten R. schrieb: >> - Anzeige aller möglichen Dateinamen mit TAB-TAB > > Bei mir geht das unter Win7. Bei mir nicht :( Okay, mit "Tab" kann ich durch die Liste der möglichen Dateinamen durchiterieren, aber ich bekommen keine Liste wie in der #bash. Einstellen von Höhe und Breite geht über "Eigenschaften - Layout - Fenstergröße", die Zahlen sind aber zeichenbasiert.
Diek schrieb: > Torsten R. schrieb: > Bei mir geht das unter Win7. Bei mir (auch Win7) geht es nicht/anders. Mit jedem tab bekomme ich eine andere Datei, mit TAB-TAB aber nicht eine Auflistung der Dateien, die möglich sind (stell' Dir mal ein TAB-TAB nach dem "ls kom" vor:
1 | $ ls kom |
2 | kom.bin kom2.bin kom3.bin kom4.bin kom_jlink.bin |
3 | kom.dump kom2.hex kom3.hex kom4.hex kom_jlink.hex |
Das feature wäre jetzt allerdings auch eins, das man sicher auch wie cmd lösen kann.
Achim H. schrieb: > Einstellen von Höhe und Breite geht über "Eigenschaften - Layout - > Fenstergröße", die Zahlen sind aber zeichenbasiert. Ja, das ist mir schon klar, aber das ist doch keine Lösung! ;-)
Achim H. schrieb: > Bei mir nicht :( Okay, mit "Tab" kann ich durch die Liste der möglichen > Dateinamen durchiterieren, aber ich bekommen keine Liste wie in der > #bash. "dir" zeigt dir die gewünschte liste an
Erfahrener schrieb: > "dir" zeigt dir die gewünschte liste an Ja, aber darum geht es nicht. Wenn ich ein Kommando absetzen möchte und dabei 3 Dateien angeben will, dann kann ich mir die natürlich vorher alle mit "dir" raus suchen. Ein komfortabele shell bietet mir aber die Möglichkeit, das während ich das Kommando tippe, zu erledigen.
Torsten R. schrieb: > Erfahrener schrieb: > >> "dir" zeigt dir die gewünschte liste an > > Ja, aber darum geht es nicht. Wenn ich ein Kommando absetzen möchte und > dabei 3 Dateien angeben will, dann kann ich mir die natürlich vorher > alle mit "dir" raus suchen. Ein komfortabele shell bietet mir aber die > Möglichkeit, das während ich das Kommando tippe, zu erledigen. Wie soll das gehen?
PowerShell bzw. PowerShell ISE. Letztere ist die Programm-Variante mit mehreren Tabs (auch Remote), Themes, Debugging, Code Completion in Skripten usw.
Torsten R. schrieb: > Ein komfortabele shell Eine. Aber nicht alle. Die von Windows z.B. nicht. Wenn Du unbedingt exakt das gleiche Verhalten wie bei Deiner geliebten Bash haben willst, nimm halt Cygwin oder WinKDE.
Juven schrieb: > > Wie soll das gehen? Nimm einfach mal das Beispiel von oben, mit dem "ls kom". Jetzt machen wir aus dem "ls" z.B: ein "edit". Ich möchte eine Datei editieren, die hier irgendwo rum liegt und bei der ich mich noch daran erinnern kann, dass die mit "kom" anfängt. Wenn ich jetzt "edit kom<TAB><TAB>" tippe, dann sehe ich die Liste der Dateien, die mit "kom" beginnen.
Arc N. schrieb: > PowerShell ist das gleiche wie mit Paint/Paint.NET. Es gibt zwar besseres und Windows zieht jeden Monat mehrere MBs an Updates, aber das was man braucht wird nicht upgedatet.
Walter T. schrieb: > Torsten R. schrieb: >> Ein komfortabele shell > > Eine. Aber nicht alle. Die von Windows z.B. nicht. Ja, dass die von Windows das nicht bietet, ist mir klar, daher suche ich ja nach Alternativen.
Walter T. schrieb: > Torsten R. schrieb: >> Ein komfortabele shell > > Eine. Aber nicht alle. Die von Windows z.B. nicht. > > Wenn Du unbedingt exakt das gleiche Verhalten wie bei Deiner geliebten > Bash haben willst, nimm halt Cygwin oder WinKDE. Für die PowerShell gibt es entsprechende Plugins, die das Verhalten nachbauen https://github.com/lzybkr/PSReadLine oder http://powertab.codeplex.com/ die selber erweiterbar sind http://powertab.codeplex.com/wikipage?title=Tab%20Item%20Selectors&referringTitle=Home
Torsten R. schrieb: > Wenn ich jetzt "edit kom<TAB><TAB>" tippe, dann sehe ich die Liste der > Dateien, die mit "kom" beginnen. Und wenn Du unter Cmd.exe kom<tab> drückst, siehst* Du die erste Datei, die mit kom anfängt. Drückst Du nochmal <tab>, siehst Du die zweite, nochmal <tab> die dritte ... Und man "sieht" nicht nur den Dateinamen, sondern er steht da, wo er hingehört. Und Du musst nicht zur Steinzeitmethode greifen, einen auf dem Bildschirm angezeigten Dateinamen direkt darunter abtippen zu müssen. Ja, cmd.exe ist anders als die bash nicht dafür ausgelegt, mit 'ner Teletype bedient zu werden, aber wer arbeitet noch mit so einem Fossil? *) Wenn nicht: "Quick-Edit-Modus" aktivieren
Rufus Τ. F. schrieb: > *) Wenn nicht: "Quick-Edit-Modus" aktivieren Stimmt, den habe ich gesucht :-)
Hallo, Torsten R. schrieb: > - Suche nach abgesetzten Kommandos. Vielleicht hilft Dir die Funktionstaste "F7" weiter. Mit freundlichen Grüßen Guido
Juven schrieb: > Wie soll das gehen? Das kann jede Shell auf unixoiden Betriebssystemen, scheint also keine Hexerei zu sein. Warum Windows keine wirklich gute Shell zur Verfügung stellt, ist mir seit jeher ein Rätsel.
P. M. schrieb: > Juven schrieb: >> Wie soll das gehen? > > Das kann jede Shell auf unixoiden Betriebssystemen, scheint also keine > Hexerei zu sein. Warum Windows keine wirklich gute Shell zur Verfügung > stellt, ist mir seit jeher ein Rätsel. Das ist keine Antwort auf meine Frage. Das ist eine Antwort auf meine Frage: Beitrag "Re: ein Königreich für eine shell/terminal"
P. M. schrieb: > Warum Windows keine wirklich gute Shell zur Verfügung stellt, ist mir > seit jeher ein Rätsel. Windows stellt ebenfalls eine gute Shell zur Verfügung, sie ist nur anders, und es erfordert persönliche Bereitschaft, sich damit auseinanderzusetzen. Nur weil etwas nicht so funktioniert wie unter irgendeinem unixoiden Betriebssystem, muss es nicht gleich schlecht sein.
Meinst Du die Powershell? Die vergurkte Altlastensammlung, bei der es nichtmal möglich zu sein scheint, krasse Hochtechnologie wie Copy&Paste und Ändern der Fenstergröße ohne Workarounds einzuführen, kann ja nicht gemeint sein.
Heini schrieb: > http://www.nextofwindows.com/4-better-windows-console-tools-alternatives-to-windows-built-in-command-prompt Danke, "Console" sah ganz gut aus. Allerdings gelingt es mir damit nicht, einen Text zu markieren (und damit auch nicht ihn zu kopieren) :-(
Tom schrieb: > Copy&Paste ... beherrscht auch cmd.exe. Nur --wie so oft-- anders als es der Träger unixoider Scheuklappen gewöhnt ist.
Rufus Τ. F. schrieb: >> Copy&Paste > > ... beherrscht auch cmd.exe. Er hatte nach einfachem copy&paste gefragt, und das ist nun wirklich nicht das, was cmd.exe bietet.
cygwin ist gut. Ich bin mit der git bash ganz zufrieden wenn ich mal Windows benutze.
Jörg W. schrieb: > Rufus Τ. F. schrieb: >>> Copy&Paste >> >> ... beherrscht auch cmd.exe. > > Er hatte nach einfachem copy&paste gefragt, und das ist nun > wirklich nicht das, was cmd.exe bietet. Was ist denn daran nicht einfach? Mark. Auswählen. Enter. Einfügen.
Doppelklick auf Wort markiert es, Klick mit mittlere Maustaste fügt es an Cursorposition ein. Kein Rumgefummel in Menüs. Vermiss ich immer wieder unter Windows. Gerhard
Lad dir mobaxterm runter: Eine win exe, die eine vollständige cygwin Umgebung bietet. Sehr hilfreich!
Rufus Τ. F. schrieb: > Tom schrieb: >> Copy&Paste > > ... beherrscht auch cmd.exe. Nur --wie so oft-- anders als es der > Träger unixoider Scheuklappen gewöhnt ist. Und noch viel anderster als es der Träger windowsoider Scheuklappen gewöhnt ist ;-) SCNR Jörg W. schrieb: > Er hatte nach einfachem copy&paste gefragt, und das ist nun > wirklich nicht das, was cmd.exe bietet. Wenn man den QuickEdit-Modus aktiviert hat, geht Copy/Paste auch in der Windows-Konsole recht fix. Allerdings kollidiert dieser Modus mit mausgesteuerten Konsolenprogrammen, weswegen er defaultmäßig deaktiviert ist und dann nur dieser grauenolle Modus verfügbar ist: Juven schrieb: > Mark. Auswählen. Enter. Einfügen. So wie du das schreibst, hören sich "Mark" und "Einfügen" wirklich einfach an ;-) Immerhin gibt es wenigstens für "Kopieren" einen Hotkey (Enter).
:
Bearbeitet durch Moderator
Rufus Τ. F. schrieb: > sie ist nur > anders, und es erfordert persönliche Bereitschaft, sich damit > auseinanderzusetzen. Sie erfordert auch daß man in jedem popeligen Script oder Makefile Extrawürste (das fängt beim echo an und hört beim mkdir und rm noch lange nicht auf) einbauen muss für das einzige OS auf dieser Welt dessen Macher gedacht haben sie müssen längst erfundene Räder ein zweites Mal erfinden und zwar in dreieckig statt rund. Vor einigen Wochen ist mir persönlich endgültig der Kragen geplatzt und ich habe festgelegt daß auf allen Kisten die für arm-gcc Entwicklung verwendet werden sollen und dennoch Windows verwenden wollen/müssen Cygwin als notwendige Abhängigkeit zu installieren ist. Das kann ich jetzt einfach voraussetzen. Sodann habe ich alle Extrawürste aus allen build-scripts ersatzlos entfernt. Das würd ich dem OP ebenfalls raten. Das erfordert 2 Minuten, es ist vollkommen nichtinvasiv und danach löst sich ein ganzer Berg voll Probleme in nichts auf. Und Copy&Paste in der Konsole geht dann auch endlich. Sogar PRIMARY mit Mittelklick wird emuliert.
:
Bearbeitet durch User
> ... Extrawürste ... Da verwechselst du etwas. Windows mit der CMD.EXE als das wichtigste Betriebssystem, ist eben der Standard und Normalzustand. > Immerhin gibt es wenigstens für "Kopieren" einen Hotkey (Enter). Schreibe ich doch: Eine vollkommen natürliche Art & Weise Texte zu kopieren. Schön, dass du es erkannt hast. Willkommen an Board :)
Torsten R. schrieb: > ich bin gerade gezwungen Ich mach es jetzt wie die Linuxer: RTFM! Lese im Internet erst einmal was du mit Windows machen kannst! Dann erst darfst du Fragen stellen! Jemand der sich mit Windows nicht auskennt, den wollen wir hier nicht! Erst wenn du selber die Sourcecodes für ein Terminal/Console schreiben kannst, darfst du nach Alternativen fragen! Ansonsten gehe zurück zu deinem KlickiBuntiLinux und lass uns in Ruhe...
:
Bearbeitet durch User
Juven schrieb: >> ... Extrawürste ... > > Da verwechselst du etwas. Windows mit der CMD.EXE als das wichtigste > Betriebssystem, ist eben der Standard und Normalzustand. Mein Beileid. Zum Glück ist es jedoch so daß man etwas erst erst dann vermisst wenn man es mal kennengelernt hat, also wirst Du vermutlich nichts davon merken und den Mangel als Normalzustand empfinden.
Yalu X. schrieb: > Wenn man den QuickEdit-Modus aktiviert hat, geht Copy/Paste auch in der > Windows-Konsole recht fix. Ja, OK, das kann ich erstmal akzeptieren. Den kannte ich noch nicht, aber ich bin zum Glück eher selten damit geplagt, sowas zu brauchen. ;) Was daran am meisten stört (egal ob QuickEdit oder nicht) ist, dass man nur ein Rechteck auswählen kann. Text, der so lang ist, dass er über mehrere Zeilen umgebrochen wird, lässt sich damit nur grauenvoll bearbeiten. Das könnte man bspw. ganz schnell mal gebrauchen, wenn man aus dem $PATH, Verzeihung %PATH% :) live eine Teilkomponente entfernen möchte … Das geht dann nur sauumständlich, indem man sich das erstmal in ein Editorfenster kopiert, dort zurechtstutzt und danach zurück kopiert. Also wirklich einfach isses nicht.
Marc H. schrieb: > Torsten R. schrieb: > Lese im Internet erst einmal was du mit Windows machen kannst! Dann erst > darfst du Fragen stellen! Na, gerade schlechte Laune, oder ist das übliche Umgangston bei Dir Zuhause? > Erst wenn du selber die Sourcecodes für ein Terminal/Console schreiben > kannst, darfst du nach Alternativen fragen! Es ist mein Beruf Software zu schreiben. Also würde ich so etwas sicher auch hin bekommen. Aber wenn ich alle meine Werkzeuge selbst schreiben müsste, wäre ich wahrscheinlich gerade erst beim Compiler ;-) > Ansonsten gehe zurück zu deinem KlickiBuntiLinux und lass uns in Ruhe... Ja, schuldig, dass ich Dich geweckt habe...
Gerhard schrieb: > Doppelklick auf Wort markiert es, Klick mit mittlere Maustaste fügt es > an Cursorposition ein. Kein Rumgefummel in Menüs. Vermiss ich immer > wieder unter Windows. Tatsache? Gerade mal wieder benutzt, cmd.exe unter Windows 8.1, Doppelklick auf ein Wort markiert es, rechte Maustaste bringt das Markierte ins Clipboard, noch mal rechte Maustaste fügt es an der Einfügeposition ein. Funktioniert auch anwendungsübergreifend, denn das Clipboard ist seit Windows 2 - anno 1987 - Standard-Feature. Die Clipboard-Unterstützung von cmd.exe kam natürlich erst mit Windows NT. Es gab und gibt allerdings üppig ausgestattete Alternativen zu command.com resp. cmd.exe. Ich habe in den Anfangszeiten umfänglich 4DOS von jpsoftware benutzt <https://en.wikipedia.org/wiki/4DOS>;, das u.a. mit eben mit der Clipboard-Unterstützung aufwartete. Wenn man wirklich ein so dringendes Bedürfnis nach einer leistungsfähigeren Shell hat, wäre Take Command in Erwägung zu ziehen (das ist praktisch der 4DOS-Nachfolger, auch von jpsoftware). Ich hab's nie benutzt, weil mir die simplen Möglichkeiten von cmd.exe reichen, und wenn nicht, ich eher zu IPython o.ä. greife: <http://ipython.org/>; Cygwin halte ich persönlich für einen Graus. Das ist nichts Halbes und nichts Ganzes.
Bernd K. schrieb: > ich habe festgelegt daß auf allen Kisten die für arm-gcc Entwicklung > verwendet werden sollen und dennoch Windows verwenden wollen/müssen > Cygwin als notwendige Abhängigkeit zu installieren ist. CCS (die Eclipse Kopie von TI) bringt auch ihre eigenes cygwin für die Windows version mit :-)
Marc H. schrieb: > Lese im Internet erst einmal was du mit Windows machen kannst! Als da wären: * Sicherheitsupdates installieren * Viren und Trojaner löschen * das System neu installieren Marc H. schrieb: > Jemand der sich mit Windows nicht auskennt, den wollen wir hier nicht! Aber was willst du dann hier? Offensichtlich kennst du dich mit beiden Systemen nicht aus, aber trollst hier rum.
Rufus Τ. F. schrieb: > Und wenn Du unter Cmd.exe kom<tab> drückst, siehst* Du die erste Datei, > die mit kom anfängt. Drückst Du nochmal <tab>, siehst Du die zweite, > nochmal <tab> die dritte ... Und man "sieht" nicht nur den Dateinamen, > sondern er steht da, wo er hingehört. Na super, und wenn ich in dem Verzeichnis 100 Dateien habe, die mit "kom" anfangen und die 87. davon will, muss ich 87 mal Tab drücken, oder eben erst dir und dann: > zur Steinzeitmethode greifen, einen auf dem > Bildschirm angezeigten Dateinamen direkt darunter abtippen zu müssen. In der Bash sehe ich alle 100 Dateien, tippe dann halt das nächste Zeichen des Namens der Datei ein, die ich mir aus der Liste rausgesucht habe und drücke nochmal <Tab>.
Juven schrieb: > Da verwechselst du etwas. Windows mit der CMD.EXE als das wichtigste > Betriebssystem, ist eben der Standard und Normalzustand. Definiere "wichtigste". Ob Supercomputer, Eingebettete Systeme, mobile Systeme oder Server, unixoide Betriebssysteme dominieren den Markt.
Jörg W. schrieb: > Was daran am meisten stört (egal ob QuickEdit oder nicht) ist, dass man > nur ein Rechteck auswählen kann. Text, der so lang ist, dass er über > mehrere Zeilen umgebrochen wird, lässt sich damit nur grauenvoll > bearbeiten. Genau das ist m.E. das Hauptproblem bei dem hochmodernen GUI, das Windows für Konsolenanwendungen anzubieten hat - egal ob da jetzt cmd.exe drin läuft oder etwas anderes. Diese blockweise Markierung im Zusammenspiel damit, dass sich die Zeilenlänge nicht durch Größer-/Kleinerziehen des Fensters ändern lässt, ist an Lächerlichkeit kaum zu überbieten. Von der konvoluten und verbuggten Syntax und Semantik der cmd.exe mal ganz zu schweigen. Dann kam die PowerShell. In einigen Punkten sehr brauchbar. Aber: hat jemals jemand bei MS die PS wirklich gestartet? Eine Shell, die auch auf aktueller Hardware teils mehrere Sekunden zum Starten braucht? m( m( m( das ist schon bei interaktivem Gebrauch extrem lästig, aber spätestens für Skripte absolut unbrauchbar.
Malte S. schrieb: > Jörg W. schrieb: >> Was daran am meisten stört (egal ob QuickEdit oder nicht) ist, dass man >> nur ein Rechteck auswählen kann. Text, der so lang ist, dass er über >> mehrere Zeilen umgebrochen wird, lässt sich damit nur grauenvoll >> bearbeiten. > > Genau das ist m.E. das Hauptproblem bei dem hochmodernen GUI, das > Windows für Konsolenanwendungen anzubieten hat - egal ob da jetzt > cmd.exe drin läuft oder etwas anderes. Ist das so? Erstaunlich. Vermutlich machst Du irgend etwas falsch. Bei mir sieht die Konsole gelegentlich etwa so aus wie in den zwei Bildern gezeigt. Die kann man nach Belieben klein- und großziehen, man kann in der gewünschten Weise markieren und kopieren, die Dateiauswahl funktioniert auch wie gewünscht, usw. > Diese blockweise Markierung im > Zusammenspiel damit, dass sich die Zeilenlänge nicht durch > Größer-/Kleinerziehen des Fensters ändern lässt, ist an Lächerlichkeit > kaum zu überbieten. An Lächerlichkeit kaum zu überbieten ist die Haltung, an der Primitiv-Shell, die cmd.exe offensichtlich ist, demonstrativ festzuhalten und dann mit großem Getöse darauf einzuschlagen. Vernünftigerweise benutzt man sie nach einer 80:20-Regel für simple Aufgaben (80 % sind einfach) und ansonsten was leistungsfähigeres, wenn man's braucht.
Wolfgang S. schrieb: > Vermutlich machst Du irgend etwas falsch. Vermutlich durch die Annahme, das System sei „aus der Dose 'raus“ benutzbar. ;-)
Wolfgang S. schrieb: > Ist das so? Erstaunlich. Vermutlich machst Du irgend etwas falsch. Bei > mir sieht die Konsole gelegentlich etwa so aus wie in den zwei Bildern > gezeigt. Die kann man nach Belieben klein- und großziehen, man kann in > der gewünschten Weise markieren und kopieren, die Dateiauswahl > funktioniert auch wie gewünscht, usw. Das ist aber keine Konsole im Sinne von "Windows Konsolenanwendung". Wolfgang S. schrieb: > An Lächerlichkeit kaum zu überbieten ist die Haltung, an der > Primitiv-Shell, die cmd.exe offensichtlich ist, demonstrativ > festzuhalten und dann mit großem Getöse darauf einzuschlagen. Ich halte ja gar nicht dran fest. Es bleibt, dass jede Konsolenanwendung (im genannten Sinne, also Programme, die nicht für das GUI-Subsystem compiliert wurden), mit cmd.exe das Schicksal teilt, in einem vom OS bereitgestellten Rahmen ausgeführt zu werden, der eben nicht kann, was andere "Konsolen" (eigentlich GUI-Anwendungen, die eine Konsolenfunktionalität bereitstellen) so können. Und es ist unter Windows nicht ohne massive Verrenkungen möglich, ein anderes Terminal statt dieses Standardkonsolenfensters zu verwenden. Also nicht eine andere Konsole, die Shell soundso mitbringt, sondern ein anderes Terminal, das beliebige Konsolenanwendungen darstellen kann.
Jörg W. schrieb: > Wolfgang S. schrieb: >> Vermutlich machst Du irgend etwas falsch. > > Vermutlich durch die Annahme, das System sei „aus der Dose 'raus“ > benutzbar. ;-) Jetzt müsstest Du noch erklären, was an "pip install qtconsole" so viel komplizierter ist als an "sudo apt-get install ipython-qtconsole", "zypper install IPython" oder "yum install ksh". Und noch etwas zum Stichwort "aus der Dose", auch wenn das vielleicht etwas unfair ist - die Chance, daß irgend ein fertig gekaufter Laptop eine funktionsfähige Installation von Windows aufweist, ist erheblich größer, als daß dort eine brauchbare Installation irgend einer von gefühlt zweiundvierzig unterschiedlichen Linuxdistributionen zu finden ist. Mit solchen Argumenten sollte man vorsichtig sein. Ich finde den ganzen Ansatz ziemlich daneben. Entweder man benutzt ein System mit den jeweils geeigneten nativen Werkzeugen oder man verwendet problembezogen plattformunabhängige. Diese Masche aber, eine Plattform mit aller Gewalt in eine konkurrierende umfrisieren zu wollen, die hat aber bisweilen schon pathologische Züge.
Wolfgang S. schrieb: > Jetzt müsstest Du noch erklären, was an "pip install qtconsole" so viel > komplizierter ist als an "sudo apt-get install ipython-qtconsole", > "zypper install IPython" oder "yum install ksh". Dass es auf einem gewöhnlich installierten Windows eben auch kein "pip" gibt. (Wenn es das gäbe, wäre es wohl das "peripheral interchange program" von VMS. :)
Malte S. schrieb: > Wolfgang S. schrieb: >> Ist das so? Erstaunlich. Vermutlich machst Du irgend etwas falsch. Bei >> mir sieht die Konsole gelegentlich etwa so aus wie in den zwei Bildern >> gezeigt. Die kann man nach Belieben klein- und großziehen, man kann in >> der gewünschten Weise markieren und kopieren, die Dateiauswahl >> funktioniert auch wie gewünscht, usw. > > Das ist aber keine Konsole im Sinne von "Windows Konsolenanwendung". Das stimmt. Windows unterscheidet zwischen "Consoles" und GUI. https://msdn.microsoft.com/en-us/library/windows/desktop/ms682010%28v=vs.85%29.aspx "Consoles manage input and output (I/O) for character-mode applications (applications that do not provide their own graphical user interface)." Schön, wenn man so anfängt, dann sind die typischerweise unter Linux verwendeten "Konsolen" allesamt keine, weil kein Mensch - außer vielleicht auf GUI-freien Servern oder Kleingeräten Anwendungen tatsächlich auf der nackten Konsole laufen läßt. > > Wolfgang S. schrieb: >> An Lächerlichkeit kaum zu überbieten ist die Haltung, an der >> Primitiv-Shell, die cmd.exe offensichtlich ist, demonstrativ >> festzuhalten und dann mit großem Getöse darauf einzuschlagen. > > Ich halte ja gar nicht dran fest. Aber ja doch, wenn auch nur zu dem Zweck, darauf einprügeln zu können. >Es bleibt, dass jede Konsolenanwendung > (im genannten Sinne, also Programme, die nicht für das GUI-Subsystem > compiliert wurden), mit cmd.exe das Schicksal teilt, in einem vom OS > bereitgestellten Rahmen ausgeführt zu werden, der eben nicht kann, was > andere "Konsolen" (eigentlich GUI-Anwendungen, die eine > Konsolenfunktionalität bereitstellen) so können. Das ist richtig, mehr oder weniger, aber jetzt geht so einiges durcheinander. Man muß sich schon entscheiden, ob man sein VT100, die genaue Semantik von Unix-Filedeskriptoren und alle bash-Feinheiten haben möchte, oder ob es darum geht, eine Reihe von Convenience-Features wie die im Eingangsposting und einigen weiteren genannten zu bekommen. Im ersteren Fall ist die Antwort einfach: wer Unix/Linux haben möchte, wird wissen, wo es zu finden ist. Im anderen Fall ist die Antwort "das gibt es/das geht unter Windows nicht" nahezu immer falsch. Meist ist die richtige Antwort, das geht, aber nicht so, sondern anders. Ob das gefällt, ist IMO weitgehend eine Frage der Gewöhnung. > Und es ist unter > Windows nicht ohne massive Verrenkungen möglich, ein anderes Terminal > statt dieses Standardkonsolenfensters zu verwenden. Nun, ConEmu bekommt das recht gut hin. Ja, ich weiß, mit einem Trick. > > Also nicht eine andere Konsole, die Shell soundso mitbringt, sondern ein > anderes Terminal, das beliebige Konsolenanwendungen darstellen kann. Klar. Wie gesagt, ConEmu. Allerdings zeigt die geringe Verbreitung solcher Konsolen m.E., daß der Bedarf nicht sonderlich hoch ist. Die meisten Konsolenanwendungen, incl. cmd.exe lassen sich durch Redirection von stdin und -out genügend gut in Gui-Verpackungen verwenden, als daß da viel Bedarf nach mehr entstünde. Was dann noch übrig bleibt, ist in der Original-Konsole gut aufgehoben. YMMV.
Jörg W. schrieb: > Wolfgang S. schrieb: >> Jetzt müsstest Du noch erklären, was an "pip install qtconsole" so viel >> komplizierter ist als an "sudo apt-get install ipython-qtconsole", >> "zypper install IPython" oder "yum install ksh". > > Dass es auf einem gewöhnlich installierten Windows eben auch kein > "pip" gibt. (Wenn es das gäbe, wäre es wohl das "peripheral > interchange program" von VMS. :) Auf einem gewöhnlich installierten Windows gibt es auch kein Python, keinen C-Compiler und keine bash. Wenn nichts nachinstalliert werden darf, ist die ganze Diskussion sinnlos. Was ist schwierig daran, https://www.python.org/ftp/python/2.7.10/python-2.7.10.amd64.msi herunterzuladen und auszuführen? Danach hat man pip.
Marc H. schrieb: > Ich mach es jetzt wie die Linuxer: > > RTFM! Das geht leider fehl, denn für Windows gibt es leider kein Manual. Wenn man die Windows-"Hilfe" aufmacht, bekommt man nur ein paar Fragen gestellt, und dann kommt: "Bitte fragen Sie Ihren Systemadministrator". Unter Linux hat hingegen fast jedes Programm eine Man- und/oder Infopage, für Weitergehendes gibt es Tutorials und HOWTOs, jedes installierte Paket hat zusätzliche Dokumentation meist unter /usr/share/doc/<paketname> und sogar im Sourcetree des Kernels gibt es das Verzeichnis "Documentation".
Wolfgang S. schrieb: > Schön, wenn man so anfängt, dann sind die typischerweise unter Linux > verwendeten "Konsolen" allesamt keine, weil kein Mensch - außer > vielleicht auf GUI-freien Servern oder Kleingeräten Anwendungen > tatsächlich auf der nackten Konsole laufen läßt. Es ist kein schöner Zug von Dir, daß Du mir das Menschsein absprichst.
Wolfgang S. schrieb: > Auf einem gewöhnlich installierten Windows gibt es auch kein Python, > keinen C-Compiler und keine bash. Wenn nichts nachinstalliert werden > darf, ist die ganze Diskussion sinnlos. Nein, eigentlich nicht. Schließlich dreht sich die Diskussion um die Frage, warum Microsoft es im Jahre 2015 immer noch nicht geschafft hat, mit seinen Betriebssystemen eine komfortable Shell mitzuliefern. Denn immerhin gibt es die cmd.exe ja schon, seit es Windows gibt. Da wäre also genug Zeit gewesen einen vernünftigen interaktiven Modus dranzuflanschen, und wie die vielen modernen, leistungsfähigen und komfortablen UNIX-Shells beweisen, ist das auch nun wirklich keine abgehobene Raketenwissenschaft.
Sheeva P. schrieb: > Wolfgang S. schrieb: >> Schön, wenn man so anfängt, dann sind die typischerweise unter Linux >> verwendeten "Konsolen" allesamt keine, weil kein Mensch - außer >> vielleicht auf GUI-freien Servern oder Kleingeräten Anwendungen >> tatsächlich auf der nackten Konsole laufen läßt. > > Es ist kein schöner Zug von Dir, daß Du mir das Menschsein absprichst. Das ist zwar eine pfiffige Bemerkung, jedoch nicht sonderlich hilfreich. War aber auch nicht beabsichtigt, oder?
Sheeva P. schrieb: > Wolfgang S. schrieb: >> Auf einem gewöhnlich installierten Windows gibt es auch kein Python, >> keinen C-Compiler und keine bash. Wenn nichts nachinstalliert werden >> darf, ist die ganze Diskussion sinnlos. > > Nein, eigentlich nicht. Schließlich dreht sich die Diskussion um die > Frage, warum Microsoft es im Jahre 2015 immer noch nicht geschafft hat, > mit seinen Betriebssystemen eine komfortable Shell mitzuliefern. Das ist eigentlich nicht richtig. Genauer gesagt ist es seit 2009 schlicht und einfach falsch. Seitdem wird die PowerShell mitgeliefert. > Denn > immerhin gibt es die cmd.exe ja schon, seit es Windows gibt. Nein. Windows gibt es seit 1985 und in die erste Version hatte das gar keine eigene Shell. cmd.exe ist eine mäßig aufgebohrte Reimplementation der eher schlichten Befehlssprache des command.com von MSDOS, die als Teil von Windows NT entstanden ist. > Da wäre > also genug Zeit gewesen einen vernünftigen interaktiven Modus > dranzuflanschen, und wie die vielen modernen, leistungsfähigen und > komfortablen UNIX-Shells beweisen, ist das auch nun wirklich keine > abgehobene Raketenwissenschaft. Windows ist ein kommerzielles Betriebssystem, mit dem Geld verdient wird. Wie ich schon mal erwähnte, gab und gibt es bessere Shells mit allen möglichen, auch interaktiven Goodies, die sich in einschlägigen Kreisen durchaus einiger Beliebtheit erfreut haben. Daß damit nicht wirklich viel Geld verdient wurde, ist m.E. durhaus ein Indiz dafür, wie sehr oder wie wenig solche Verbesserungen vermisst wurden. Und wie ich ebenfalls bereits schrieb, ich habe einen "vernünftigen interaktiven Modus" von cmd.exe) in den vergangenen Jahren eher nicht vermisst. Es gibt für spezieller Zwecke bessere Werkzeuge und für simple Aufgaben ist eine langfristig unverändert vorhandene simple Shell mehr als genug.
Wolfgang S. schrieb: > Sheeva P. schrieb: >> Wolfgang S. schrieb: >>> Schön, wenn man so anfängt, dann sind die typischerweise unter Linux >>> verwendeten "Konsolen" allesamt keine, weil kein Mensch - außer >>> vielleicht auf GUI-freien Servern oder Kleingeräten Anwendungen >>> tatsächlich auf der nackten Konsole laufen läßt. >> >> Es ist kein schöner Zug von Dir, daß Du mir das Menschsein absprichst. > > Das ist zwar eine pfiffige Bemerkung, jedoch nicht sonderlich hilfreich. > War aber auch nicht beabsichtigt, oder? Tatsächlich sollte es Dich indirekt darauf hinweisen, daß manche Menschen -- hin und wieder etwas tun, von dem Du behauptest, daß es "kein Mensch" tun würde. In manchen Situationen spare ich mir die GUI, und gewinne dadurch mehr RAM (zum Beispiel bei der Analyse großer Datenmengen) oder weniger Kontextwechsel (zum Beispiel bei einfachen Performancetests).
Wolfgang S. schrieb: > Das ist eigentlich nicht richtig. Genauer gesagt ist es seit 2009 > schlicht und einfach falsch. Seitdem wird die PowerShell mitgeliefert. Du hast die Kritik an diesem Werkzeug oben gelesen? Und das scheint nicht die einzige zu sein...: [1][2][3][4]. Das sind nur vier aus den über 50k Google-Suchergebnissen für "powershell criticism", zufällig ausgewählt. >> Denn immerhin gibt es die cmd.exe ja schon, seit es Windows gibt. > > Nein. Windows gibt es seit 1985 und in die erste Version hatte das gar > keine eigene Shell. Damals lief Windows noch unter DOS, und das hatte, wie Du sehr richtig anmerkst, auch schon einen Kommandozeileninterpreter. In all den Jahren hätte man bei MS also wohl genug Zeit gehabt, die normale Shell besser hinzubekommen als diesen cmd.exe-Mist. Zumal man doch angeblich Wert auf Abwärtskompatibilität legt und es zu der Zeit, als MS mit der Powershell aufgepoppt ist, schon Generationen von DOS- und Windows-Usern mit Erfahrungen unter command.com und cmd.exe gab. Warum mußte man die alle vor den Kopf stoßen und etwas ganz Neues machen? Warum konnte man die guten Eigenschaften der UNIX-Shells nicht abkupfern, darin ist Microsoft doch sonst ganz groß? Warum konnte man den vorhandenen Kommandozeileninterpreter cmd.exe nicht trotzdem verbessern? > cmd.exe ist eine mäßig aufgebohrte Reimplementation > der eher schlichten Befehlssprache des command.com von MSDOS, die als > Teil von Windows NT entstanden ist. Ach Gottchen, ein Penibler. Aber inwieweit bringt die Frage, ob es cmd.exe nun seit 1985 oder seit 1993 gibt, die Diskussion voran? Aber ok, command.com war ja auch nicht so prall. Warum konnte man die bei der guten Gelegenheit einer Reimplementierung nicht verbessern? >> Da wäre also genug Zeit gewesen einen vernünftigen interaktiven Modus >> dranzuflanschen, und wie die vielen modernen, leistungsfähigen und >> komfortablen UNIX-Shells beweisen, ist das auch nun wirklich keine >> abgehobene Raketenwissenschaft. > > Windows ist ein kommerzielles Betriebssystem, mit dem Geld verdient > wird. Echt jetzt? Was Du nicht sagst. Verrückt. > Wie ich schon mal erwähnte, gab und gibt es bessere Shells mit > allen möglichen, auch interaktiven Goodies, die sich in einschlägigen > Kreisen durchaus einiger Beliebtheit erfreut haben. Und das entschuldigt, daß Microsoft immer noch diesen unausgegorenen, unkomfortablen Mist ausliefert? Darf man Microsoft und diesen Mist deswegen nicht kritisieren, ja? Bist Du hier der offizielle "Microsoft über alles"-Verteidigungsbeauftragte? Was sollen uns diese zwanghaften Ablenkungsmanöver und Nebelkerzen sagen? > Daß damit nicht wirklich viel Geld verdient wurde, ist m.E. durhaus ein > Indiz dafür, wie sehr oder wie wenig solche Verbesserungen vermisst > wurden. ...oder ein Indiz dafür, daß es ebenbürtige oder sogar bessere Shells gab, die kostenlos zur Verfügung standen... > Und wie ich ebenfalls bereits schrieb, ich habe einen "vernünftigen > interaktiven Modus" von cmd.exe) in den vergangenen Jahren eher nicht > vermisst. Du bist nicht der einzige Mensch auf der Welt, weißt Du. Andere vermissen eine brauchbare interaktive Shell unter Windows und ärgern sich darüber, daß Microsoft so etwas seit zwanzig Jahren nicht hinbekommt. Das war der Ausgangspunkt dieses Threads, erinnerst Du Dich noch? [1] http://windowsitpro.com/powershell/top-ten-powershell-annoyances [2] http://jamesreubenknowles.com/venting-on-powershell-779 [3] http://www.theregister.co.uk/2014/05/10/readers_corner_powershell_terminal/ [4] http://overscope.cynistar.net/archives/298-Windows-PowerShell,-Radioactive-Sludge,-and-Documentation-Failure.html
:
Bearbeitet durch User
Sheeva P. schrieb: > Denn immerhin gibt es die cmd.exe ja schon, seit es Windows gibt. Nö, cmd.exe hat command.com mit dem Übergang auf Windows NT abgelöst. Da haben sie zwar paar sinnvolle Features nachgerüstet, aber eben bislang wieder 20 Jahre lang nichts gemacht.
Wolfgang S. schrieb: > Nun, ConEmu bekommt das recht gut hin. Ja, ich weiß, mit einem Trick. Danke. Kannte ich noch nicht. Und das nicht, weil ich soetwas nicht vermissen würde, sondern weil ich Windows in aller Regel eh nur via VNC/RDP/SPICE benutze. Daher stelle ich hier auch nicht so auf die Shell ab (ob nun cmd, PS, bash, Python), sondern auf das Terminal. Denn das benutzen sie alle. Auch PS, wenn man nicht gerade ISE verwendet. Und dieses Terminal, das Microsoft mitliefert, ist halt Müll. Schön, dass es ConEmu gibt, werde ich mir ansehen. Aber es ist - im Gegensatz zu Linux eben bei Windows von Haus aus nichts wirklich verwendbares dabei. Selbst OSX hat eine halbwegs brauchbare Terminal.app, obwohl ein Großteil der Macuser nichtmal wissen, was ein CLI ist.
Schon mal ConEmu oder Console2 ausprobiert? Das sind mehr oder weniger Clones, bringen jedoch verschiedene Annehmlichkeiten für cmd mit.
Sheeva P. schrieb: > Wolfgang S. schrieb: >> Das ist eigentlich nicht richtig. Genauer gesagt ist es seit 2009 >> schlicht und einfach falsch. Seitdem wird die PowerShell mitgeliefert. > > Du hast die Kritik an diesem Werkzeug oben gelesen? Ach so, Du stellst auf ausschließlich auf "komfortabel" ab. Das liegt aber im Auge des Betrachters. Von der Architektur her schlägt die PowerShell das schlichte, uralte Zeichenstrommodell von Unix um Längen. Ob man das für komfortabel hält oder ob man sich ausschließlich auf UI-Aspekte versteift, ist ziemlich subjektiv. > Und das scheint > nicht die einzige zu sein...: [1][2][3][4]. Das sind nur vier aus den > über 50k Google-Suchergebnissen für "powershell criticism", zufällig > ausgewählt. Geschenkt. Ich vermute, mit Googeln nach "bash bash" wird man weniger Erfolg haben. :-}. "bash annoyances" liefert aber immerhin fast 90k Treffer. Ja, [1] zeigt einige der Probleme der PowerShell auf. Und die Vielfalt der Unix-Shells, bourne, bash, csh, zsh, ksh, mksh etc pp., die jeweils ihre eigenen Fanclubs haben, zeigt m.E. deutlich, daß auch hier einiges im Argen liegt. http://mywiki.wooledge.org/BashPitfalls könnte einige Anhaltspunkte geben, welche das sind. > >>> Denn immerhin gibt es die cmd.exe ja schon, seit es Windows gibt. >> >> Nein. Windows gibt es seit 1985 und in die erste Version hatte das gar >> keine eigene Shell. > > Damals lief Windows noch unter DOS, und das hatte, wie Du sehr richtig > anmerkst, auch schon einen Kommandozeileninterpreter. Genau. Über den Ansatz, es bezüglich der implementierten Funktionalität (i.e. Sprache) und des UI damit zu belassen, statt die Kommandozeile bzw. ihre Shell zu einer Art Universalwerkzeug auszubauen, kann man sicherlich streiten. M.E. haben sauberer strukturierte "Script"-Sprachen wie Python, Ruby, Lua und meinetwegen auch Perl oder das weitgehend überflüssig gemacht. Oder unter Windows, VBScript und JScript. > In all den Jahren > hätte man bei MS also wohl genug Zeit gehabt, die normale Shell besser > hinzubekommen als diesen cmd.exe-Mist. Nicht weniger und nicht mehr Zeit, als all dieser *sh*-Mist, der sich im Unix-Lager breitgemacht hat, gekostet hat. > > Zumal man doch angeblich Wert auf Abwärtskompatibilität legt und es zu > der Zeit, als MS mit der Powershell aufgepoppt ist, schon Generationen > von DOS- und Windows-Usern mit Erfahrungen unter command.com und cmd.exe > gab. Warum mußte man die alle vor den Kopf stoßen und etwas ganz Neues > machen? Weil es etwas ganz Neues ist. > Warum konnte man die guten Eigenschaften der UNIX-Shells nicht > abkupfern, darin ist Microsoft doch sonst ganz groß? Warum konnte man > den vorhandenen Kommandozeileninterpreter cmd.exe nicht trotzdem > verbessern? Weiß ich nicht. Frag' Microsoft. PowerShell ist praktisch die Shell von .net. Warum Microsoft, nachdem man mit .net praktisch eine neue solide Basis gebaut hatte, es nicht geschafft oder überhaupt ernsthaft versucht hat, den ganzen Zwischenbau und Anwendungs-Stack auf dieser Basis neu hochzuziehen? Keine Ahnung, mich hat das schon gewundert. Jedenfalls hätte ich mir das als Windows-Nutzer gewünscht, aber nicht eine aufgemotzte cmd.exe. > >> cmd.exe ist eine mäßig aufgebohrte Reimplementation >> der eher schlichten Befehlssprache des command.com von MSDOS, die als >> Teil von Windows NT entstanden ist. > > Ach Gottchen, ein Penibler. Aber inwieweit bringt die Frage, ob es > cmd.exe nun seit 1985 oder seit 1993 gibt, die Diskussion voran? Es bringt die Diskussion insofern voran, als es eines der Motive benennt. Das wortgewaltige Geläster über die alten Zöpfe, die sich Microsoft nicht abzuschneiden traut, macht vergessen, daß diese unveränderten alten Zöpfe für viele Nutzer durchaus einen Wert darstellen und dass Unix/Linux ähnliche Leichen im Keller hat. Der ganze bash/zsh/csh-Flohzirkus ist doch ein gutes Bespiel dafür und der Streit bzgl. systemd oder nicht systemd zeigt analoge Probleme doch auch dort. Es in der Rückschau besser zu wissen ist keine Kunst. > > Aber ok, command.com war ja auch nicht so prall. Warum konnte man die > bei der guten Gelegenheit einer Reimplementierung nicht verbessern? Warum hätte man sollen? > >>> Da wäre also genug Zeit gewesen einen vernünftigen interaktiven Modus >>> dranzuflanschen, und wie die vielen modernen, leistungsfähigen und >>> komfortablen UNIX-Shells beweisen, ist das auch nun wirklich keine >>> abgehobene Raketenwissenschaft. >> >> Windows ist ein kommerzielles Betriebssystem, mit dem Geld verdient >> wird. > > Echt jetzt? Was Du nicht sagst. Verrückt. Vielleicht hättest Du, statt gleich verhalten beleidigend zu werden, die nächsten Absätze lesen sollen. Man muß es nicht gutfinden, jedoch ist die Konzentration von Microsoft auf den Desktop statt auf die Kommandozeile Grund genug. Es ist ja auch nicht so, daß dies nicht erfolgreich gewesen wäre. Linux auf dem Desktop ist immer noch ein ziemlich wenig bevölkerte Nische und die Vielfalt der verfügbaren Hochleistungsshells, grafischer wie zeichenorientierter scheint der Verbreitung eher nicht förderlich gewesen zu sein. > >> Wie ich schon mal erwähnte, gab und gibt es bessere Shells mit >> allen möglichen, auch interaktiven Goodies, die sich in einschlägigen >> Kreisen durchaus einiger Beliebtheit erfreut haben. > > Und das entschuldigt, daß Microsoft immer noch diesen unausgegorenen, > unkomfortablen Mist ausliefert? Komm' mal wieder den Boden runter. Dieser missionarische Eifer, mit dem jedem (auch-)Windows-Benutzer gleich die Rolle als Microsoft-Pressesprecher angedichtet wird, bloß weil er nicht in jedes stereotype Bashing mit einstimmt, der nervt, und zwar gewaltig. Ich jedenfalls vermisse bash/zsh/csh ... unter Windows nicht. > Darf man Microsoft und diesen Mist > deswegen nicht kritisieren, ja? Bist Du hier der offizielle "Microsoft > über alles"-Verteidigungsbeauftragte? Siehe oben. Mir reicht's. Aber schön, daß wir darüber gesprochen haben.
Wolfgang S. schrieb: > Ich jedenfalls vermisse bash/zsh/csh ... unter Windows nicht. Dann bist du aber unter denjenigen, die beides kennen, eher die Ausnahme.
Jörg W. schrieb: > Wolfgang S. schrieb: >> Ich jedenfalls vermisse bash/zsh/csh ... unter Windows nicht. > > Dann bist du aber unter denjenigen, die beides kennen, eher die > Ausnahme. Das klingt mir nun eher wie eine Glaubensformel und weniger wie eine Erkenntnis. Wer nicht nur zwei, drei Systeme kennt, wird sich an ähnlich verbissene Auseinandersetzungen erinnern, wenn ein Amigafan sich voller Eifer für REXX missionierend ins Zeug warf, egal ob das Opfer nun Windows-, Unix- oder IBM-MVS-Nutzer war. In gewisser Weise ist es ja auch verständlich. Mit dem bereits 1979 von Mike Cowlishaw entwickelten REXX existierte schon früh eine ausgereifte Shell-Sprache, die sich durchaus plattformübergreifend als Vorlage für andere Systeme angeboten hätte und so beispielsweise als ARexx auf dem Amiga auch tastächlich eingesetzt wurde. Ich selber halte immer noch Snobol 4 und Simula-67 in mancherlei Hinsicht für besser als ihre Nachfolger. Das Problem ist, so funktioniert das leider nicht. Gute Vorlagen werden nicht übernommen und verbessert, sondern es wird turnusmäßig das Rad neu erfunden und dabei die alten Konzepte halbherzig abgekupfert und dann nachgebessert. Mein Ansatz ist an dieser Stelle rein pragmatisch, man benutzt das, was von den jeweiligen Systemen angeboten und gut unterstützt wird. When in Rome ... https://en.wiktionary.org/wiki/when_in_Rome,_do_as_the_Romans_do Es soll aber Leute geben, die mit dem Wohnmobil nach Südfrankreich fahren, um sich dort dann von aus der Heimat mitgebrachten Konserven zu ernähren und dabei über die Satellitenschüssel Fußball zu gucken ... :-)
Wolfgang S. schrieb: > Ach so, Du stellst auf ausschließlich auf "komfortabel" ab. Natürlich, darum ging es dem TO doch. > Von der Architektur her schlägt die PowerShell das schlichte, uralte > Zeichenstrommodell von Unix um Längen. Eigentlich implementiert sie ein sehr ähnliches Zeichenstrommodell, mit Pipes, Ein- und Ausgabeumleitung, ... > Ich vermute, mit Googeln nach "bash bash" wird man weniger Erfolg > haben. :-}. "bash annoyances" liefert aber immerhin fast 90k > Treffer. Das ist zwar ein lustiger Versuch, denn Ball zurück zu spielen, aber leider schlägt er fehl. Einerseits, weil ich ihn durchschaut habe, und andererseits, weil nicht ich es bin, der Diskussionen über die Schwächen der Bash unterbinden will, sondern Du derjenige bist, der die Diskussion des TO über die Schwächen der cmd.exe abzubügeln versucht. > M.E. haben sauberer strukturierte "Script"-Sprachen wie Python, Ruby, > Lua und meinetwegen auch Perl oder das weitgehend überflüssig gemacht. > Oder unter Windows, VBScript und JScript. Das ist aber nur Dein eigenes, ganz privates und exklusives Erachten. Und nein, Python, Lua und Perl (und auch IPython) sind ganz sicher kein Ersatz für eine ordentliche Shell. Ich beherrsche zwar alle drei, aber trotzdem ist die Shell für mich ein unverzichtbares Werkzeug und ich würde niemals auf die Idee kommen, meine Shell durch einen dieser Kandidaten zu ersetzen -- und ausweislich der Frage des TO gilt das wohl auch für andere. >> In all den Jahren hätte man bei MS also wohl genug Zeit gehabt, die >> normale Shell besser hinzubekommen als diesen cmd.exe-Mist. > > Nicht weniger und nicht mehr Zeit, als all dieser *sh*-Mist, der sich im > Unix-Lager breitgemacht hat, gekostet hat. Welcher *sh*-Mist denn? Jede der von Dir aufgezählten UNIX-Shells ist der cmd.exe an Komfort haushoch überlegen und wird, im Gegensatz zur cmd.exe, fortwährend weiterentwickelt. > Es bringt die Diskussion insofern voran, als es eines der Motive > benennt. Das wortgewaltige Geläster über die alten Zöpfe, die sich > Microsoft nicht abzuschneiden traut, macht vergessen, daß diese > unveränderten alten Zöpfe für viele Nutzer durchaus einen Wert > darstellen Und deswegen kann man die alten Zöpfe nicht verbessern, wenn man sie denn schon nicht abschneidet, sondern weiterhin ausliefert? Ich habe auch gar nicht über alte Zöpfe gelästert, wie kommst Du darauf? Ich habe lediglich kritisiert, daß Microsoft die cmd.exe zwar immer noch ausliefert, aber seit Jahrzehnten nicht verbessert hat, obwohl es offensichtliche Mängel bei deren Bedienkomfort gibt und Bedarf bei manchen Anwendern, diese Mängel zu beheben. > und dass Unix/Linux ähnliche Leichen im Keller hat. Der ganze bash/zsh > /csh-Flohzirkus ist doch ein gutes Bespiel dafür und der Streit bzgl. > systemd oder nicht systemd zeigt analoge Probleme doch auch dort. Äh, nein, eben nicht. Die Diskussion über systemd dreht sich ja gerade darum, den Bootvorgang moderner Systeme zu verbessern. Da geht es also genau um das, was Microsoft im Falle der cmd.exe nicht macht, nämlich um eine Verbesserung und Weiterentwicklung. Genau dasselbe gilt für die verschiedenen Shells; die Bash hat sich weitestgehend durchgesetzt, aber trotzdem versuchen einige Projekte eine (aus ihrer Sicht) bessere Shell herzustellen. Da geht es ebenfalls um das, was Microsoft bei der cmd.exe versäumt hat, nämlich um eine Verbesserung und Weiterentwicklung. >> Aber ok, command.com war ja auch nicht so prall. Warum konnte man die >> bei der guten Gelegenheit einer Reimplementierung nicht verbessern? > > Warum hätte man sollen? Ja, warum sollte man eine Software besser machen wollen? Ist Microsoft nicht jenes Unternehmen, das sich sonst bei jeder möglichen Gelegenheit mit seiner abgeblichen Kunden- und Benutzerfreundlichkeit brüstet? Aus welchem Grund könnte so ein Unternehmen wohl auf die Idee kommen, seine Software zu verbessern? Zumal, wenn man sie eh gerade reimplementiert? >>> Windows ist ein kommerzielles Betriebssystem, mit dem Geld verdient >>> wird. >> >> Echt jetzt? Was Du nicht sagst. Verrückt. > > Vielleicht hättest Du, statt gleich verhalten beleidigend zu werden Du findest meinen leichten Sarkasmus schon beleidigend? Dann solltest Du vielleicht erst einmal Deine eigene Wortwahl betrachten. Denn diesen Umgangston habe ich mir nur von Dir abgeschaut ("Ist das so? Erstaunlich" und "An Lächerlichkeit kaum zu überbieten", um nur zwei Beispiele zu benennen). Dabei ist es an Lächerlichkeit kaum zu überbieten, wenn einer erst mit der groben Kelle austeilt und dann das Mimöschen macht, wenn er das genau so wieder zurück bekommt. Ich selbst bin da komplett flexibel. Man kann mit mir vollkommen ruhig und sachlich diskutieren, kein Problem. Aber wenn jemand so auf die Kacke haut wie Du, bekommt er das eben genau so wieder zurück. Ich passe mich dabei lediglich meinem Gegenüber an, in diesem Falle: Dir. Schon unsere Mütter wußten: wie man in den Wald hineinruft, so schallt es heraus. >> Und das entschuldigt, daß Microsoft immer noch diesen unausgegorenen, >> unkomfortablen Mist ausliefert? > > Komm' mal wieder den Boden runter. Dieser missionarische Eifer, mit dem > jedem (auch-)Windows-Benutzer gleich die Rolle als > Microsoft-Pressesprecher angedichtet wird, bloß weil er nicht in jedes > stereotype Bashing mit einstimmt, der nervt, und zwar gewaltig. Tja, so unterschiedlich kann man die Welt sehen. Mich nervt es, daß bei jeder noch so berechtigten Kritik an einem beliebigen Microsoft-Produkt automatisch irgendwelche Besserwisser aufpoppen und mit unnachahmlicher Penetranz und großer Aggressivität versuchen, jede Kritik zu unterbinden und jede Diskussion darüber zu torpedieren. Da liegt die Vermutung nahe, daß das an Programmen wie den "Most Valuable Professional" liegt, bei dem Microsoft ausgewählten Partnern Vergünstigungen dafür gewährt, daß diese sich in öffentlichen Foren, Mailinglisten, und Sozialen Netzwerken für Microsoft und seine Produkte einsetzen. Aber wo Du gerade schon da bist, fragen wir doch einfach mal: was bringt Dich denn dazu, Dich in dieser Dissussion so stark zu engagieren? Warum mußt Du der Klage über mangelnden Komfort der cmd.exe denn widersprechen und behaupten, daß man das diesen Mangel nicht kritisieren dürfe? Bisher habe ich als Begründung von Dir nicht mehr gehört als "ich vermisse das nicht". Muß ich Deinen wortreichen Widerspruch so verstehen, daß Du das Exklusivrecht darüber gepachtet hast, zu verfügen, wer was vermissen und kritisieren darf? Bist Du derjenige, der die Norm festlegt, und was in Deinem Horizont nicht existiert, darf es auch nirgendwo anders geben?
:
Bearbeitet durch User
Jörg W. schrieb: > Wolfgang S. schrieb: >> Ich jedenfalls vermisse bash/zsh/csh ... unter Windows nicht. > > Dann bist du aber unter denjenigen, die beides kennen, eher die > Ausnahme. geht mir genauso. soe viele unterschiede in den standard use cases gibts ja nicht, aber ich mag die autovervollständigung unter der bash überhaupt nicht - und die benutze ich quasi ständig. zumal wenn ich textdateien processiere, heißt die ausgabedatei genauso wie der input mit einem suffix. blabla.txt blabla_filtered.txt blabla_filtered_mappedGTD.txt ... man tippt auf tab und sie vervollständigt nur so weit, bis sich die möglichen matches untersdheiden, dann muss ich von hand weitertippen. unter der cmd, das mit tab durch die möglichkeiten durchzutippen find ich viel angenehmer. gerade bei obigen namensschema nervt bash gewaltig Unter der Cmd nervt mich die erwähnte Rechteckauswahl. und die Art und weise, wie die "-Zeichen interpretiert werden (oder auch nicht) ist jedes mal furchtbar, wenn man komplexere strings als Argumente übergeben möchte. Ansonsten sind noch die Gnuwin32 utils unverzichtbar. Und pclip.exe als ergänzung zum dem vorhandenen 'clip'
:
Bearbeitet durch User
Sheeva P. schrieb: > Aber wo Du gerade schon da bist, fragen wir doch einfach mal: Pluralis majestatis? Na gut, wenn es die Befindlichkeit verbessert ... > was bringt > Dich denn dazu, Dich in dieser Dissussion so stark zu engagieren? Der Wunsch zu helfen, durch Erklärung und Bespiele, wie ich mit den beschriebenen Einschränkungen umgehe. > Warum > mußt Du der Klage über mangelnden Komfort der cmd.exe denn widersprechen > und behaupten, daß man das diesen Mangel nicht kritisieren dürfe? Gegenfrage: was verspricht sich Euer Gnaden davon, cmd.exe schärfstens zu kritisieren? Hat Er wohl die Hoffnung, Microsoft möge flugs ein Erbarmen haben und gleich übermorgen Windows 11 (Codename Zealous Zebulon) abgeben, kostenlos, mit mksh als Shell, Unity als Desktop und APT als Paktetmanager? Ernsthaft, ein ehemaliger Kollege, Systemprogrammierer und Leiter der Systemgruppe eines grossen IBM-Rechenzentrums hat vor zig Jahren mal nach einem lang andauernden Gemecker eines Benutzers, dem irgend eine Architekturentscheidung von IBM nicht schmeckte (irgendwas Grundlegendes, Zahl der Register der 370 oder vergleichbar), diesem im internen Ticketsystem abschließende den Vorschlag gemacht, doch IBM zu kaufen und dann eine entsprechende Anweisung zu geben, mit den notwendigen Kontaktdaten könne er dienen. Er selber sei einfach die falsche Adresse, nachdem jegliche Vorschläge bezüglich alternativer Vorgehensweisen und sonstige Hilfen einfach so in den Wind geschlagen würden. Ich fand das, damals noch Anfänger, ziemlich frech. Inzwischen verstehe ich es besser. :-}
Wolfgang S. schrieb: > Gemecker eines Benutzers Wolfgang S. schrieb: > Ich fand das,[...] ziemlich frech gibts da Identität zwischen den Personen ;-) *SCNR*
Vlad T. schrieb: > Wolfgang S. schrieb: >> Gemecker eines Benutzers > > Wolfgang S. schrieb: >> Ich fand das,[...] ziemlich frech > > gibts da Identität zwischen den Personen ;-) Nein. Ich war damals nicht der meckernde Benutzer, sondern als Mitglied der Anwendungsgruppe - zuständig für Compiler und Tools - des RZ irgendwie zwischen allen Stühlen.
:
Bearbeitet durch User
Vlad T. schrieb: > soe viele unterschiede in den standard use cases gibts ja nicht, aber > ich mag die autovervollständigung unter der bash überhaupt nicht - und > die benutze ich quasi ständig. > zumal wenn ich textdateien processiere, heißt die ausgabedatei genauso > wie der input mit einem suffix. > > blabla.txt > blabla_filtered.txt > blabla_filtered_mappedGTD.txt > ... > > man tippt auf tab und sie vervollständigt nur so weit, bis sich die > möglichen matches untersdheiden, dann muss ich von hand weitertippen. > unter der cmd, das mit tab durch die möglichkeiten durchzutippen find > ich viel angenehmer. gerade bei obigen namensschema nervt bash gewaltig
1 | $ bind '"\e[Z":menu-complete' |
legt die von Dir gewünschte Funktion "menu-complete" auf Shift+Tab. Mit
1 | $ bind 'TAB:menu-complete' |
kannst Du sie aber auch direkt auf die Tab-Taste legen. Selbstverständlich kannst Du jenen Teil hinter "bind " auch in Deine ~/.inputrc oder Deine systemweite /etc/inputrc schreiben (natürlich ohne die ''), um das Ganze zu persistieren. Die Readline-Bibliothek ist sehr konfigurierbar. Weitere Informationen dazu findest Du im Readline-Manual und in der Bash-Manpage.
Sheeva P. schrieb: > Selbstverständlich kannst Du jenen Teil hinter "bind " auch in Deine > ~/.inputrc oder Deine systemweite /etc/inputrc schreiben (natürlich ohne > die ''), um das Ganze zu persistieren. So sieht meine .inputrc aus, die history-search auf den Cursortasten möchte ich auch nicht mehr missen.
1 | $ cat .inputrc |
2 | "\e[A": history-search-backward |
3 | "\e[B": history-search-forward |
4 | "\t": menu-complete |
:
Bearbeitet durch User
Wolfgang S. schrieb: > Sheeva P. schrieb: >> was bringt Dich denn dazu, Dich in dieser Dissussion so stark zu >> engagieren? > > Der Wunsch zu helfen, durch Erklärung und Bespiele, wie ich mit den > beschriebenen Einschränkungen umgehe. Du möchtest einem Fragesteller also helfen, indem Du sein Problem als nicht existent abtust und das damit begründest, daß Du dieses Problem nicht hast? Ok, dieser Ansatz ist zwar nicht hilfreich, aber dafür sehr kreativ. >> Warum mußt Du der Klage über mangelnden Komfort der cmd.exe denn >> widersprechen und behaupten, daß man das diesen Mangel nicht >> kritisieren dürfe? > > Gegenfrage: Es gilt als grob unhöflich, Fragen mit einer Gegenfrage zu beantworten. Aber es ist konsistent zu Deinen anderen Einlassungen.
Bernd K. schrieb: > Sheeva P. schrieb: > >> Selbstverständlich kannst Du jenen Teil hinter "bind " auch in Deine >> ~/.inputrc oder Deine systemweite /etc/inputrc schreiben (natürlich ohne >> die ''), um das Ganze zu persistieren. > > So sieht meine .inputrc aus, die history-search auf den Cursortasten > möchte ich auch nicht mehr missen. > >
1 | > $ cat .inputrc |
2 | > "\e[A": history-search-backward |
3 | > "\e[B": history-search-forward |
4 | > "\t": menu-complete |
5 | > |
Prima Sache, das. Vielleicht möchtest Du Dir ja auch mal das Bash-Builtin "fc" anschauen, das finde ich bei der Wiederholung ganzer Sequenzen von Shellbefehlen ausgesprochen komfortabel.
Tom schrieb: > Copy&Paste Ein aktuelles OS würde helfen... Sowohl Windows 8.1 als auch Windows 10 (oh wunder, das Upgrade von 7 ist sogar kostenlos...) kann natürlich in der cmd per Strg+V/Strg+C, also DEN Standardtasten, Copy/Paste betreiben.
Sheeva P. schrieb: > Wolfgang S. schrieb: >> Sheeva P. schrieb: >>> was bringt Dich denn dazu, Dich in dieser Dissussion so stark zu >>> engagieren? >> >> Der Wunsch zu helfen, durch Erklärung und Bespiele, wie ich mit den >> beschriebenen Einschränkungen umgehe. > > Du möchtest einem Fragesteller also helfen, indem Du sein Problem als > nicht existent abtust und das damit begründest, daß Du dieses Problem > nicht hast? Ok, dieser Ansatz ist zwar nicht hilfreich, aber dafür sehr > kreativ. Das wird ja immer ulkiger. Hinweise auf mindestens zwei Alternativen zu cmd.exe, die eine kommerziell, die andere frei verfügbar, zählen also nicht als hilfreich, weil das im jeweiligen Biotop bleibende Erweiterungen sind, statt 1:1-Ports von Linux-Shells? Auch nicht Hinweise auf Clipboard-Features von cmd.exe, die offenbar übersehen wurden? Bravo, das nenne ich echten missionarischen Eifer. Zum Glück ist diese Art von Eifer selbst unter eisernen Fans unixoider OS inzwischen eher eine Seltenheit geworden. > >>> Warum mußt Du der Klage über mangelnden Komfort der cmd.exe denn >>> widersprechen und behaupten, daß man das diesen Mangel nicht >>> kritisieren dürfe? >> >> Gegenfrage: > > Es gilt als grob unhöflich, Fragen mit einer Gegenfrage zu beantworten. Es gilt erst recht als grob unhöflich, freche Unterstellungen als Frage zu verpacken.
Tom schrieb:
> Copy&Paste
Ein aktuelles OS würde helfen... Sowohl Windows 8.1 als auch Windows 10
(oh wunder, das Upgrade von 7 ist sogar kostenlos...) kann natürlich in
der cmd per Strg+V/Strg+C, also DEN Standardtasten, Copy/Paste
betreiben.
Funktioniert bei mir nicht (Windows 8.1).
Rechte Maustaste. OK.
Mark. OK.
STRG-C.
STRG-V. Im Fenster kommt ^V.
Ctrl+C ist eigentlich nicht gerade die Standardtaste für Copy in einer Shell, das ist seit 30 Jahren "Befehl abbrechen" ...
Wolfgang S. schrieb: > Bravo, das nenne ich echten missionarischen Eifer. Diesbezüglich muß ich mich auf Dein kompetentes Urteil verlassen, ich kenne mich mit missionarischem Eifer nämlich nicht so gut aus. Vielleicht möchtest Du Dir Deine Beiträge einfach nochmal durchlesen -- vor allem Deine Reaktionen darauf, wenn Dir widersprochen wurde. Dann kommst Du eventuell selbst drauf, warum ich und Andere hier etwas angepickt auf Deine "Beiträge" reagiert haben. Wenn Du nicht selbst darauf kommst, kann ich Dir leider auch nicht helfen. Muß ich aber zum Glück auch nicht. Guten Tag.
Sheeva P. schrieb: >> Von der Architektur her schlägt die PowerShell das schlichte, uralte >> Zeichenstrommodell von Unix um Längen. > > Eigentlich implementiert sie ein sehr ähnliches Zeichenstrommodell, mit > Pipes, Ein- und Ausgabeumleitung, ... Genau das tut sie nicht. Das ist so ziemlich das allererste, was man wissen muß, wenn man mit der Powershell zu tun hat. Wie wäre es, wenn du dein Unwissen still auslebst? > Tja, so unterschiedlich kann man die Welt sehen. Mich nervt es, daß bei > jeder noch so berechtigten Kritik an einem beliebigen Microsoft-Produkt > automatisch irgendwelche Besserwisser aufpoppen und mit unnachahmlicher > Penetranz und großer Aggressivität versuchen, jede Kritik zu unterbinden Quatsch. Berechtigte Kritik, selbst unberechtigte (so sie gutgläubig geäußert wird), ist völlig in Ordnung. Nur dein simples "MS ist Scheiße" lockt halt seit Jahren niemanden mehr hinterm Ofen vor. Und ist off-topic. Und verstößt gegen jegliche Netiquette. > und jede Diskussion darüber zu torpedieren. Da liegt die Vermutung nahe, > daß das an Programmen wie den "Most Valuable Professional" liegt, bei > dem Microsoft ausgewählten Partnern Vergünstigungen dafür gewährt, daß > diese sich in öffentlichen Foren, Mailinglisten, und Sozialen Netzwerken > für Microsoft und seine Produkte einsetzen. Mit solchen Behauptungen torpedierst du jegliches halbwegs umgängliche Miteinander. Entweder du hast harte Beweise (aber du glaubst das wohl selbst nicht wirklich), oder du bist ein geistiger Brandstifter, den man ungeachtet, welcher Seite er zuneigt, rückstandsfrei entfernen sollte: Account löschen, alle Postings löschen, virtuelles Hausverbot. Leute wie du machen Online-Communities kaputt. Normale Trolle, auch Störer, behindern eine Community und können ihr schaden. Leute wie du zerstören gnadenlos. Deshalb: bitte ziehe dich einfach dauerhaft aus dem Forum zurück. Du wirst hier nicht glücklich (außer mC.net zerstören ist dein großes Glück).
Flo schrieb: > Sheeva P. schrieb: >>> Von der Architektur her schlägt die PowerShell das schlichte, uralte >>> Zeichenstrommodell von Unix um Längen. >> >> Eigentlich implementiert sie ein sehr ähnliches Zeichenstrommodell, mit >> Pipes, Ein- und Ausgabeumleitung, ... > > Genau das tut sie nicht. > > Das ist so ziemlich das allererste, was man wissen muß, wenn man mit der > Powershell zu tun hat. Was unterscheidet (Powershell)
1 | (help | out-string -stream) | select-string get |
denn bitte von (bash)
1 | help | grep -i get |
? Ja, in der Powershell werden serialisierte .NET-Objekte weitergegeben, aber das Modell unterscheidet sich dabei nicht -- nur der Inhalt. Darüber hinaus sehe ich auch nicht, daß die Weitergabe von serialisierten Objekten der von Zeichenketten überlegen sein soll, im Gegenteil: Vorteil der Zeichenketten sind ihre Universalität und Lesbarkeit, ohne vorher die Dokumentation eines riesigen Frameworks wälzen zu müssen. Eine UNIX-Shell kann auch ein Programmier-Laie verstehen und anwenden, während es für die Powershell notwendig ist, einige Vorkenntnisse aus der objektorientierten Programmierung zu haben -- man muß schon verstanden haben, was ein Objekt ist, was Eigenschaften und Methoden sind, inwieweit sich eine Methode von einer Funktion unterscheidet, ... you get the idea. Mutmaßlich deswegen wird die Powershell nur von einem winzigen Bruchteil der Windows-Anwender genutzt, obwohl es unter Windows zweifellos genauso viele Arbeiten und Vorgänge gibt, die von einer sauberen Automatisierung profitieren könnten. > Berechtigte Kritik, selbst unberechtigte (so sie gutgläubig geäußert > wird), ist völlig in Ordnung. Nur dein simples "MS ist Scheiße" Ich kann mich nicht erinnern, das geäußert zu haben. Aber kannst Deine Behauptung hoffentlich mit einer Quellenangabe belegen, oder? >> Da liegt die Vermutung nahe, daß das an Programmen wie den "Most >> Valuable Professional" liegt, bei dem Microsoft ausgewählten Partnern >> Vergünstigungen dafür gewährt, daß diese sich in öffentlichen Foren, >> Mailinglisten, und Sozialen Netzwerken für Microsoft und seine Produkte >> einsetzen. > > Mit solchen Behauptungen torpedierst du jegliches halbwegs umgängliche > Miteinander. Ach so: die Torpedierung des umgänglichen Miteinanders erfolgt also nicht etwa durch Microsofts MVP-Programm, das Trolle dafür belohnt, daß sie die öffentliche Werbetrommel für Microsoft trommeln, sondern durch Leute, die auf die Existenz solcher Troll-Programme hinweisen? Glückwunsch für diese (fast) schlaue Verdrehung von Ursache und Wirkung, *(Gast)*. Zuletzt glaube ich -- das magst Du gerne für naiv halten -- immer noch daran, daß man Umstände durch konstruktive Kritik verbessern kann. Die Welt wird nicht besser dadurch, daß man sie einfach hinnimmt, sondern dadurch, daß Mißstände kritisiert und abgestellt werden. Natürlich gilt dies auch für Software, und meiner Erfahrung nach sind die allermeisten Softwarehersteller für konstruktive Kritik an ihren Produkten nicht nur offen, sondern meistens sogar dankbar dafür.
Blechschaden schrieb: > Tom schrieb: >> Copy&Paste > > Ein aktuelles OS würde helfen... Sowohl Windows 8.1 als auch Windows 10 > (oh wunder, das Upgrade von 7 ist sogar kostenlos...) kann natürlich in > der cmd per Strg+V/Strg+C, also DEN Standardtasten, Copy/Paste > betreiben. > > Funktioniert bei mir nicht (Windows 8.1). > > Rechte Maustaste. OK. > Mark. OK. > > STRG-C. > STRG-V. Im Fenster kommt ^V. Funktioniert auch erst seit Windows 10. 8.1 konnte das noch noch nicht. Sven B. schrieb: > Ctrl+C ist eigentlich nicht gerade die Standardtaste für Copy in einer > Shell, das ist seit 30 Jahren "Befehl abbrechen" ... Funktioniert aber verrückter weise außerhalb der Shell unter Linux meist auch. Da frag ich mich warum?
Soso, Objekte sind dasselbe wie "Zeichenströme"... keine weiteren Fragen.
Flo schrieb: > Soso, Objekte sind dasselbe wie "Zeichenströme"... keine weiteren > Fragen. Offensichtlich war meine Erklärung wohl nicht gut genug, deswegen versuche ich es noch einmal etwas ausführlicher. Ob man über das Pipe-Modell jetzt reine Zeichenketten oder serialisierte Objekte führt, ändert nichts am Modell. Es ist und bleibt ein Pipe-Modell, welches die Ausgabe eines Programmes als Eingabe an ein weiteres Programm weiterleitet. Soviel zum Prinzip des Modells; kommen wir zu den Inhalten. Bei serialisierten Objekten unterscheiden sich nicht einmal die Inhalte allzu sehr, und natürlich kann man auch mit UNIX-Pipes strukturierte Daten wie zum Beispiel mit JSON, XML oder CSV serialisierte Objekte weitergeben (das nutze ich sogar regelmäßig, zum Beispiel mit csvkit). Man kann dabei sogar Objekte übergeben, die mit Pythons pickle, mit Perls FreezeThaw oder Storable, oder mit C++' Boost::Serialization serialisiert worden sind. Das ist zwar eher unüblich, aber ebenso möglich und von mir auch alles schon eingesetzt worden, wo es sinnvoll erschien. Das Pipe-Modell von UNIX ist da vollkommen flexibel, und aus genau diesem Grunde haben es die Macher sowohl der cmd.exe als auch der Powershell dann letztlich auch übernommen -- sogar bis hin zum genutzten Pipe-Zeichen. Eigentlich gar nicht so schwierig, oder?
Flo schrieb: > Soso, Objekte sind dasselbe wie "Zeichenströme"... keine weiteren > Fragen. Ja, genau. Serialisierte Objekte sind Zeichenströme, was sollen sie denn sonst sein?
Eben. Piping ist sinnvoll. Aber Zeichenströme zu pipen ist archaisch.
Sven B. schrieb: > Ctrl+C ist eigentlich nicht gerade die Standardtaste für Copy in einer > Shell, das ist seit 30 Jahren "Befehl abbrechen" ... Ich weiß ja nicht, wie du auf die Idee kommst, gleichzeitig etwas einzufügen und einen Prozess abzubrechen. Das ist doch per Prinzip nie gleichzeitig möglich.
Torsten R. schrieb: > Hallo, > ich bin gerade gezwungen mal wieder unter Windows zu arbeiten. cmd.exe > ist ja ganz nett, aber ich vermisse da so folgende Möglichkeiten: > - Terminal-Fenster auf die gewünscht Größe ziehen. > - Anzeige aller möglichen Dateinamen mit TAB-TAB > - Mehrere Konsolen als Tabs. > - Suche nach abgesetzten Kommandos. > - Einfaches copy/past! Ganz wichtig! Sheeva P. schrieb: > Nein, eigentlich nicht. Schließlich dreht sich die Diskussion um die > Frage, warum Microsoft es im Jahre 2015 immer noch nicht geschafft hat, > mit seinen Betriebssystemen eine komfortable Shell mitzuliefern. Leute, ihr diskutiert ja immer noch. Bedenkt doch mal eines: Windows ist ein durch und durch auf grafische Oberfläche orientiertes Betriebssystem - und das macht Windows bedeutend besser als alle gefühlten tausend Geschmacksrichtungen von Linux-Oberflächen. Daß es da überhaupt noch einen textorientierten Kommandozeileninterpreter bei Windows gibt, interessiert nur ganz ganz wenige Leute. Naja, eigentlich interessiert es fast gar keinen. Die Kommandozeile ist unter Windows tatsächlich nicht zum Arbeiten gedacht, sowas macht man auf der grafischen Oberfläche. Nun frag ich mich, warum Torsten partout per Kommandozeile arbeiten will. Fehlen ihm die eigentlichen Anwendungen? Oder kommt er mit dem Prinzip "Anwendung" nicht klar und vermißt das Prinzip "Tools"? Wer ne Batch-Abarbeitung braucht, schreibt sich ne Batchdatei (per EDITOR) und doppelklickt sie bei Bedarf. Fertig. Aber selbst das ist unter Windows eher unüblich, denn selbst einfachere Editoren haben ne Toolverwaltung eingebaut, wo man auch das Starten einer Batch-Abarbeitung auf eine Funktionstaste innerhalb der Anwendung legen kann. Sowas ist Komfort - für das Herumgetippe auf ner Kommandozeile hab ich da kein wirkliches Verständnis. Also: Zu welchem eigentlichen Zweck soll da denn bloß die Kommandozeile zelebriert werden? Nostalgie? W.S.
qwertzuiopü+ schrieb: > Sven B. schrieb: >> Ctrl+C ist eigentlich nicht gerade die Standardtaste für Copy in einer >> Shell, das ist seit 30 Jahren "Befehl abbrechen" ... > > Ich weiß ja nicht, wie du auf die Idee kommst, gleichzeitig etwas > einzufügen und einen Prozess abzubrechen. Das ist doch per Prinzip nie > gleichzeitig möglich. Erstens ist Ctrl+C der Shortcut für kopieren, nicht einfügen, und zweitens konkurrieren einfügen und Prozess abbrechen selbstverständlich miteinander. Dazu brauchst du nur mal "cat" einzutippen.
W.S. schrieb: > Also: Zu welchem eigentlichen Zweck soll da denn bloß die > Kommandozeile zelebriert werden? Nostalgie? Weil ein geübter Nutzer damit viel schneller und viel reproduzierbarer Dinge tun kann als mit einer GUI.
Bernd K. schrieb: > Flo schrieb: >> Soso, Objekte sind dasselbe wie "Zeichenströme"... keine weiteren >> Fragen. > > Ja, genau. Serialisierte Objekte sind Zeichenströme, was sollen sie denn > sonst sein? Lesen bildet. Kaum schreibt irgend einer "in der Powershell werden serialisierte .NET-Objekte weitergegeben", wird das einfach geglaubt und auf der Basis lustig weiteragitiert. Da hilft vielleicht ein Blick in das ursprüngliche Designdokument (das Monad Manifesto von 2002), das zwar längst überholt ist, aber einen recht guten Blick auf die wesentlichen Ziele und Designentscheidungen liefert. "4.2 A New Approach to Composing Solutions The traditional approach to composing solutions is difficult and fragile. It uses pipelines to perform prayer-based parsing of text streams. These mechanisms are awkward, inconsistent, and imprecise. Admins spend the majority of their thought process on mechanisms instead of problem solving. Monad takes a different approach providing a precise, powerful script execution engine for creating pipelines of .Net objects. Instead of piping unstructured text, we pipe .Net objects. This allows the downstream pipeline components to operate directly on the objects and their properties using the .Net Reflection APIs. (The reflection APIs allow a utility to find the type of an object, what properties/methods it has, get its property values and invoke its methods)" Ja, serialisierte Objekte sind Zeichenströme. Aber serialisierte Objekte sind eben nur Zeichenströme, keine Objekte. Es ist robuster, effizienter und erweiterbarer, am Anfang und Ende einer Pipeline zu parsen bzw. zu serialisieren, als bei jeder Objektübergabe von Pipeelement zu Pipelement jedesmal mittendrin eine überflüssige unparse/parse-Abfolge einzulegen, die dann möglicherweise auch noch jeweils unterschiedliche Parser bzw. Serialiserer verwendet. Das Design hat durchaus potentielle Pferdefüsse, die man diskutieren könnte. Aber dazu müsste man erst mal seine Scheuklappen ablegen. Und dann bleibt auch noch die Frage, ob das hier überhaupt für irgend jemand relevant ist. Diskussionen über einen Ansatz für "the next generation platform for administrative automation" dürften in einem Mikrocontroller-Forum eher fehl am Platze sein ...
Sven B. schrieb: > W.S. schrieb: >> Also: Zu welchem eigentlichen Zweck soll da denn bloß die >> Kommandozeile zelebriert werden? Nostalgie? > Weil ein geübter Nutzer damit viel schneller und viel reproduzierbarer > Dinge tun kann als mit einer GUI. Das ist IMHO die naive Gegenposition und genau so falsch. Ein geübter Nutzer erledigt manche Dinge gern und schnell über die Kommandozeile, andere gern und schnell über ein GUI. Wobei diese Gegenüberstellung leicht vergessen läßt, daß bzgl. gut und schnell die Qualitäten der Programme, die da via Kommandozeile oder via GUI bedient werden, eine mindestens so große Rolle spielen wie die von Terminal / Shell hier und GUI-Basis und Desktop Environment dort. Was mich betrifft, ich mag auf beides nicht verzichten. Genauer gesagt, ich meine, daß ein vernünftiges Design eines Programms immer dreierlei braucht, einen algorithmischen Kern mit API, eine Kommandozeile und ein GUI.
Wolfgang S. schrieb: > Das ist IMHO die naive Gegenposition und genau so falsch. Stimmt natürlich, aber ich dachte das sei selbstverständlich, dass ich nicht 3d-Modelling mit der Kommandozeile machen will. > Was mich betrifft, ich mag auf beides nicht verzichten. Genauer gesagt, > ich meine, daß ein vernünftiges Design eines Programms immer dreierlei > braucht, einen algorithmischen Kern mit API, eine Kommandozeile und ein > GUI. Das ist in dieser Allgemeinheit mindestens genauso unsinnig wie meine Aussage. ;) Thunderbird braucht zum Beispiel bestimmt keine Kommandozeile, genausowenig wie grep eine GUI braucht.
Wolfgang S. schrieb: > It uses pipelines to perform prayer-based parsing of text streams. Spätestens an dieser Stelle würde ich die Unvoreingenommenheit des Schreibenden komplett in Zweifel stellen. Voreingenommenheit wiederum ist gewiss keine gute Grundlage für ein Design-Dokument, denn sie bringt einen dazu, „auf Teufel komm raus“ etwas zu entwerfen, was zwanghaft anders sein soll als das, von dem man sich da gerade abgrenzen möchte. Mal vom unterschiedlichen Anwendungszweck abgesehen: keiner zwingt irgendwelche Unix-Programme dazu, über ihre Pipelines ausschließlich Text weiterzureichen. Selbstverständlich könnte man darüber auch binäre Datenklumpen als Repräsentation von Objekten schieben, das ist der Pipe völlig schnuppe.
Jörg W. schrieb: > Mal vom unterschiedlichen Anwendungszweck abgesehen: keiner zwingt > irgendwelche Unix-Programme dazu, über ihre Pipelines ausschließlich > Text weiterzureichen. Selbstverständlich könnte man darüber auch > binäre Datenklumpen als Repräsentation von Objekten schieben, das > ist der Pipe völlig schnuppe. und das wird auch täglich in dieser Art genutzt. Zum Beispiel in dem man mit dd eine Partition liest und dann in netcat 'piped' um die Daten zu einem anderen Rechner im Netzwerk zu senden. Oder rsync über ssh, usw., usf. Das hier über den Nutzen und die Sinnhaftigkeit ernsthaft gestritten wird, erscheint dem täglichen Nutzer dieser Möglichkeiten einfach nur 'sehr begrenzt intelligent'
Jörg W. schrieb: > Mal vom unterschiedlichen Anwendungszweck abgesehen: keiner zwingt > irgendwelche Unix-Programme dazu, über ihre Pipelines ausschließlich > Text weiterzureichen. Selbstverständlich könnte man darüber auch > binäre Datenklumpen als Repräsentation von Objekten schieben, das > ist der Pipe völlig schnuppe. Ein Unterschied dabei ist natürlich, dass bei der typischen Unix-Shell beidseits der Pipe eigenständige Prozesse stehen. Wenn ich PowerShell richtig verstanden habe, ist das wenn nicht ausdrücklich ein externer Prozess gestartet wird, eher nicht so. Da geschieht das Überreichen der Daten durch die Pipe mutmaßlich intern gar nicht in einem einzelnen Stream? Oder zumindest könnte es als simple Übergabe eines Pointers/Handles geschehen. Vielleicht nicht ganz unwesentlich, wenn man bedenkt, wie teuer ein CreateProcess() im Vergleich zu fork() und exec() ist.
Malte S. schrieb: > Da geschieht das Überreichen der Daten durch die Pipe mutmaßlich intern > gar nicht in einem einzelnen Stream? Klar kann man sowas auch machen. IPC (oder Inter-Thread-Kommunikation) muss sich ja nicht auf die direkte Übergabe der Daten beschränken; shared memory existiert in diversen Varianten plattformübergreifend schon recht lange. Nur: auf der typischen Kommandozeile brauche ich solche Konstrukte eher nicht. Ich will ja da nicht einen Webbrowser aus drei Einzelteilen zusammensetzen, von denen einer die Daten aus dem Netz holt, der zweite die Objekte für die Darstellung daraus aufbereitet und der dritte sie dann endlich darstellt. Weiß ja nicht, was mit der PowerShell am Ende tatsächlich getan wird (und wer was damit tut). Mich beschleicht der leise Verdacht, dass es eine Lösung ohne Problem ist, die in erster Linie geschaffen worden ist, um „modern“ zu sein (das würde zum Tenor dieses Design-Dokumentes passen). Ich lass' mich da aber gern eines besseren belehren.
Powerful Bash-style command line editing for cmd.exe http://mridgers.github.io/clink/ Clink combines the native Windows shell cmd.exe with the powerful command line editing features of the GNU Readline library, which provides rich completion, history, and line-editing capabilities. Readline is best known for its use in the well-known Unix shell Bash, the standard shell for Mac OS X and many Linux distributions.
W.S. schrieb: > Bedenkt doch mal eines: Windows ist ein durch und durch auf grafische > Oberfläche orientiertes Betriebssystem Von diesem Paradigma ist sogar Microsoft wieder abgekommen, hat eingesehen, daß so etwas bei der Automatisierung von Abläufen eine gute Sache ist, und darum dann die Powershell und den Windows Scripting Host entwickelt.
Wolfgang S. schrieb: > "4.2 A New Approach to Composing Solutions > [...] Instead of piping unstructured text, we pipe .Net objects. Wie findet das denn genau statt, ganz konkret? Ich meine, "we pipe .Net objects" kann doch wohl so ziemlich alles heißen -- Serialisierung bzw. Marshalling, Übergabe von Datentypen plus Startadressen, ... Darüber hinaus sehe ich immer noch nicht, daß die Powershell ein anderes Modell benutzen würde als eine UNIX-Shell. Das Konzept ist, komplexere Funktionen aus einfachen Elementen (im Sinne von: Shell-Builtin, Programm, Powershell cmdlet) zusammenzusetzen, indem die Ausgabe eines Elements als Eingabe an ein anderes Element weitergeleitet wird. Die englischsprachige Wikipedia scheint das ähnlich zu sehen: "PowerShell implements the concept of a pipeline, which enables the output of one cmdlet to be piped as input to another cmdlet. [...] As with Unix pipelines, PowerShell pipelines are used to compose complex commands, using the | operator to connect stages."
Jürgen W. schrieb: > Powerful Bash-style command line editing for cmd.exe > > http://mridgers.github.io/clink/ Bin mit clink sehr zufrieden - - - bis auf den immer noch vorhandenen Block-Auswahl Modus. Da merkt man dann, dass es doch "nur" ein aufgebohrtes cmd.exe ist. Ansonsten eine sehr Unix-ähnliche Shell (selbst mit den selben Kommandos: ls, pwd, ...) Gerhard
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.