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!
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.
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
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.
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.
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
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).
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.
> ... 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...
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:> 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
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.
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?
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'
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. :-}
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.
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.
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.
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?
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?
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 abschalten