Ohja, bis man das mal mitbekommt, vergehen Jaare. Es sagt einem keiner sowas. Man staut nur jedesmal, wieso der richtige Verzeichnisname/Befehl sofort dasteht.
Von Fensterbank am Do, 26. Februar 2009 um 19:43 #
Ja was geht ab, das funktioniert auch für Befehle???
Danke, dass ichs jetzt auch weiß ^^ Dachte das geht nur für Dateinamen (was ich auch erst seit zwei Monaten weiß, kein Wunder habe ich die Bash früher gehasst, als man noch so viel tippen musste...
Von Polynomial-C am Di, 24. Februar 2009 um 20:07 #
Na da gratuliere ich allen Beteiligten mal für die Veröffentlichung. Gleichzeitig hoffe ich allerdings, daß Version 4.0 etwas weniger patches benötigt, als die davor veröffentlichte Version (3.2, bekam insgesamt 48 patches verpaßt). Gerade für Systeme, die mit vielen Shellskripten laufen/arbeiten, war Version 3.2 relativ problematisch, da sich etliche Fehler eingeschlichen hatten.
ich bin ja der meinung, dass man skripte, die länger als 20 Zeilen sind in python statt sh schreiben sollte. alles andere ist eine zumutung für die nachwelt. jm2c
Von Anonymer Feigling am Mi, 25. Februar 2009 um 12:40 #
Auf vielen Systemen ist Python sowieso installiert. Und Python-Skripte funktionieren auch auf Windows, besser als diese bash "ports" die dann uralt und fehlerhaft sind.
>Auf vielen Systemen ist Python sowieso installiert
Definiere "viele Systeme". Viele Systeme, die ich administriere haben kein Python installiert. Und selbst wenn: Dann musst du anfangen zu unterscheiden, ob Python Version 2 oder 3, da u. U. inkompatibel. Außerdem ist m. E. Perl immer noch verbreiteter als Python, also wenn schon, dann Perl.
Puristen schreiben eh alles mit #!/bin/sh. In der Shellskript-Szene und unter BSD'lern sind #!/bin/bash und so genannte "Bashisms" ziemlich verpönt.
Von rweqr32333345324r5ämfglasdfajs am Mi, 25. Februar 2009 um 13:40 #
Definiere "viele Systeme". Viele Systeme, die ich administriere haben kein Python installiert. Dann installiere es und es ist vorhanden.
Dann musst du anfangen zu unterscheiden, ob Python Version 2 oder 3, da u. U. inkompatibel. Außerdem ist m. E. Perl immer noch verbreiteter als Python, also wenn schon, dann Perl. Von Perl gibt es auch verschiedene Versionen -> Kein Argument.
Ob Python oder Perl ist Geschmackssache, jedenfalls ist beides besser als reines bash, damit kann man kaum was 'grösseres' anfangen oder nur über Verrenkungen, von der Les- und Wartbarkeit ist es eine Katastrophe, ausser man macht den ganzen Tag nichts anderes als bash-scripte zu schreiben.
Von Perl gibt es auch verschiedene Versionen -> Kein Argument. Doch, bei Perl zählt nur die Version 5 und die ist abwärtskompatibel und wird über Jahre gepflegt. Python ist einfach zu jung. Es wird immer irgendwas geändert, um das Design zu verbessern. Bei Perl gibts keinen neuen syntaktischen Zucker.
Na toll, . Jetzt wo ich auf zsh gewechselt bin kommen die mit sowas. :) > [...] Klein- »(^[^])« und Großschreibung »(,[,])« zu ändern. Andersrum fände ich es ein wenig logischer. Aber wer weiß.
Die zsh wird auch durch die Features in der bash 4.0 nicht eingeholt. bash ist wie der Sozialismus. Jeder muss sie irgendwann mal nutzen, aber überholen ohne einzuholen klappt einfach nicht.
Irgendwann in grauer Vorzeit muss das ja mal anders gewesen sein oder wie konnte die Bash mal zu nem quasi Standard werden? Ich meine mir fällt absolut nichts ein, wo die gut drin wäre, nichtmal standardkompatibel zu dem POSIX-Blödsinn ist sie richtig.
wie konnte die Bash mal zu nem quasi Standard werden? \begin{orakel} Irgendwo habe ich mal gelesen, dass die bash überall (auf jedem OS) gleich ist und das ist (warum auch immer) bei den anderen Shells nicht so... \end{orakel}
Nee, hier gibt es bestimmt mehrere... aber ich glaube, du möchtest dir das Paket inputenc anschauen. "u und Konsorten braucht man schon lange nicht mehr...
Von Peter Eisentraut am Mi, 25. Februar 2009 um 10:58 #
Das Problem ist wohl vielmehr, dass zsh an bestimmten kritischen Stellen nicht POSIX- oder Bourne-kompatibel ist und daher als /bin/sh nicht in Frage kommt. (War auf den ersten Versionen von Mac OS X der Fall, musste dann aber genändert werden (auf bash).) Bei bash ist die Kompatibilität dagegen sehr gut und bash hat dazu noch ganz gute interaktive Features (verglichen mit dash oder so) und eignet sich daher als vorinstallierte Universalshell.
Die Neuerungen hören sich schon etwas nach ZSH an. ZSH ist momentan mein Favorit. Ich finde den Wettbewerb gut. Sachen wie der **-glob unter ZSH sind einfach genial.
gibt es eigentlich ein Terminal, welches unter X den Cursor per Mausklick in einer Shell positionieren kann? Gerade wenn man eine ziemlich lange Zeile an Befehlen hat und dann merkt, dass mal ein Sonderzeichen falsch sitzt, dann ist es mit den Cursortasten doch recht muehsam.
Die Bash kann ja schon lange vor Kraft nimmer gehen... Typischer GNUnsinn... jedes Programm wird zur eierlegenden Wollmichsau erweitert... Das ist soooooo ununixoid! Naja... schließlich heißt es ja "GNU is not Unix"! ...und zum Glück gibt es auch echte Unixe, mit denen man sich das nicht antun muß...
Ja, wenn ich nostalgisch werde, installier ich mir auch immer ein altes NetBSD oder Solaris in einer VM, um zu sehen wie das war, als Unix noch Unix und Männer noch Männer waren ;)
Ich mein das mit dem "nicht unixoid" recht ernst... Warum muß man im GNULand alles was stat macht auch noch in find stecken und obendrauf ein stat nebenbei haben? Um einen -exec oder eine Pipe mit xargs einzusparen? Die Schönheit von Unix verliert man so komplett aus den Augen...
Geschmackssache... ok...
...ich pack den Morgenstern ja auch unbenutzt wieder weg... ;-D
;-)
Gruesse, nufap
[x] Ich habe keine Ahnung und labere hier dummes zeug.
GUI tssssss :-(
[x] Ich nehme alle todernst.
;)
Das erinnert mich an diesen tollen GameMaker den es für Windows gab/gibt.
Da spiel ich mich lieber mit Python und pygame
Hä? Ich muß auf der CLI immer noch Befehle eintippen, nicht zusammenklicken...
Naja, du hast vmtl. barrierefrei (!) gearbeitet.
Selbst die Eingabe per Tastatur ist mehr das Drücken der tabtaste^^
Tendenz
Danke, dass ichs jetzt auch weiß ^^
Dachte das geht nur für Dateinamen (was ich auch erst seit zwei Monaten weiß, kein Wunder habe ich die Bash früher gehasst, als man noch so viel tippen musste...
Dann kannst du auch eine Befehle 'zusammenklicken' ;P
Furgas
Gleichzeitig hoffe ich allerdings, daß Version 4.0 etwas weniger patches benötigt, als die davor veröffentlichte Version (3.2, bekam insgesamt 48 patches verpaßt). Gerade für Systeme, die mit vielen Shellskripten laufen/arbeiten, war Version 3.2 relativ problematisch, da sich etliche Fehler eingeschlichen hatten.
Schau einfach die Patches mal selber an. Jeder Patch hat im Header eine Beschreibung des Fehlers, den der Patch behebt.
Definiere "viele Systeme". Viele Systeme, die ich administriere haben kein Python installiert.
Und selbst wenn: Dann musst du anfangen zu unterscheiden, ob Python Version 2 oder 3, da u. U. inkompatibel.
Außerdem ist m. E. Perl immer noch verbreiteter als Python, also wenn schon, dann Perl.
Puristen schreiben eh alles mit #!/bin/sh. In der Shellskript-Szene und unter BSD'lern sind #!/bin/bash und so genannte "Bashisms" ziemlich verpönt.
Dann installiere es und es ist vorhanden.
Dann musst du anfangen zu unterscheiden, ob Python Version 2 oder 3, da u. U. inkompatibel.
Außerdem ist m. E. Perl immer noch verbreiteter als Python, also wenn schon, dann Perl.
Von Perl gibt es auch verschiedene Versionen -> Kein Argument.
Ob Python oder Perl ist Geschmackssache, jedenfalls ist beides besser als reines bash, damit
kann man kaum was 'grösseres' anfangen oder nur über Verrenkungen, von der Les- und Wartbarkeit
ist es eine Katastrophe, ausser man macht den ganzen Tag nichts anderes als bash-scripte zu schreiben.
Doch, bei Perl zählt nur die Version 5 und die ist abwärtskompatibel und wird über Jahre gepflegt.
Python ist einfach zu jung. Es wird immer irgendwas geändert, um das Design zu verbessern. Bei Perl gibts keinen neuen syntaktischen Zucker.
Und ja, ich würde auch python nehmen...
> [...] Klein- »(^[^])« und Großschreibung »(,[,])« zu ändern.
Andersrum fände ich es ein wenig logischer. Aber wer weiß.
\begin{orakel}
Irgendwo habe ich mal gelesen, dass die bash überall (auf jedem OS)
gleich ist und das ist (warum auch immer) bei den anderen Shells
nicht so...
\end{orakel}
\selectlanguage{ngerman}
\begin{begeistert}
ich bin also nicht die einzige "uberzeugte \LaTeX Benutzerin \ldots
\end{begeistert}
das Paket inputenc anschauen. "u und Konsorten braucht man schon lange
nicht mehr...
die gleiche Funktionalität bereitstellt
(wenn das System sie anbietet).
Steinigt mich nicht, aber ich dachte bis dato, dass &> genau dies macht???
Bin kein bashguru - also bitte um Nachsicht
echo test >datei.txt 2>&1
bzw.
echo test >>datei.txt 2>&1
Was gibt denn nun >>& an? Obigen ersten oder den zweiten Fall?
Und was bedeuten die "Case-Statements »;&« und »;;&« "?
perl -e 'print STDOUT "stdout\n"; print STDERR "stderr\n"' &>test.txt
funktioniert tatsächlich. Es überschreibt den Dateiinhalt. Vielleicht ist dann ein >>& tatsächlich ein Anhängen?
perl -e 'print STDOUT "stdout\n"; print STDERR "stderr\n"' &>>test.txt
Typischer GNUnsinn... jedes Programm wird zur eierlegenden Wollmichsau erweitert...
Das ist soooooo ununixoid!
Naja... schließlich heißt es ja "GNU is not Unix"!
...und zum Glück gibt es auch echte Unixe, mit denen man sich das nicht antun muß...
Warum muß man im GNULand alles was stat macht auch noch in find stecken und obendrauf ein stat nebenbei haben? Um einen -exec oder eine Pipe mit xargs einzusparen?
Die Schönheit von Unix verliert man so komplett aus den Augen...
Geschmackssache... ok...
...ich pack den Morgenstern ja auch unbenutzt wieder weg... ;-D