Diskussion:Bash (Shell)

Beispiel einer bash

Die Bildschirmkopie ist nicht lesbar und sollte entweder entfernt oder ausgetauscht werden. (nicht signierter Beitrag von 84.160.147.24 (Diskussion | Beiträge) 10:58, 14. Jun. 2009 (CEST))

Dir ist aber schon klar, dass du erst aufs Bild klicken musst? Ich kann es dann zumindest sehr gut lesen. -- chatter™ 20:59, 14. Jun. 2009 (CEST)

Programmierungabschnitt

Bezieht sich die Bedingungsauswertung nur auf Bash oder ist dies allgemeiner Natur(der Shellprogrammierung)?--91.43.60.133 22:13, 25. Mär. 2010 (CET)

Jedenfalls die doppelten eckigen Klammern sind Bash-spezifisch. Die "sh" kennt nur einzelne Klammern. -- Mfnalex (Diskussion) 14:14, 16. Jul. 2017 (CEST)

Vorschlag

• sich die englische Seit zum Vorbild zu nehmen und die Genauigkeit der short cuts ebenfalls auf der Seit zu übernehmen.

Denn so ist nichtmals der Unterschied zwischen born und bash deutlich. Sinnhafte Programmierung wird jedenfalls nicht erklärt. she bang und nicht sinnhaftes Zerhacken ist die Problematik bei selbstläufigem bash, sowie Oximorone.--Rkoll 19:28, 13. Okt. 2010 (CEST)

Die Bash und if-Abfragen

Laut dem Artikel würden die Bedingungen bei den if-Abfragen an das Programm „test“ übergeben werden, das stimmt, wenn ich mich recht entsinne, allerdings nicht: Ich meine, mich zu erinnern, dass „test“ bei der Bash ein „Builtin“ ist:

$ type test # „[“ oder „[[“ gingen auch
test is a shell builtin

Soweit ich weiß, ist das nur bei der traditionellen Shell so (Bourneshell). Aber das wird ja ein Abschnitt darunter schon erklärt. Warum steht also darüber, dass da ein (externes) Programm aufgerufen würde? – Gorlingor (Diskussion) 14:43, 6. Mär. 2012 (CET)

Die ursprünglichen Shells (Thompson-Shell und ältere) hatten kein Builtin für test sondern nutzten das externe Programm. Weil das aber umständlich zu lesen war:

if test $x -ne $y ; then

führte man das Kommando /usr/bin/[ per Softlink auf /usr/bin/test ein. So konnte man etwa schreiben:

if [ $x -ne $y ; then

Man sieht das hin und wieder noch auf sehr alten UNIX-System (unter Aegis/Domain OS zB war es so). Das war zwar besser, aber auch nicht ideal, weil Programmierer darauf trainiert sind, geöffnete Klammern auch wieder zu schließen. Deshalb änderte man /usr/bin/[ dahingehend ab, daß es zwingend als letztes Argument ein "]" erwartete, wodurch die heute übliche Schreibweise

if [ $x -ne $y ] ; then

geboren war. Das erklärt auch, warum bestimmte Leerzeichen zwingend vorgeschrieben sind:

if [ $x -ne $y ] ; then        # richtig

if [ $x -ne $y ]; then         # auch richtig

if [ $x -ne $y] ; then         # falsch

if [$x -ne $y ] ; then         # auch falsch

Weil test aber so oft gebraucht wurde, haben Shells (insbesondere bash und ksh) begonnen, ein entsprechendes Builtin beizufügen, sodaß die Anzahl der notwendigen fork()-Aufrufe reduziert wird. Zu unterscheiden ist das builtin vom externen Programm durch den Aufruf:

if [ $x -ne $y ] ; then        # Aufruf von /usr/bin/test

if [[ $x -ne $y ]] ; then      # Aufruf des Builtins

--bakunin (Diskussion) 11:14, 2. Feb. 2014 (CET)

Sachlicher Fehler bei builtin test-Statement

> und so unter anderem auch keine Anführungszeichen um Variablen mehr benötigt: Dieser Satz(-teil), der sich auf die Eigenschaften des built-in test-Statements "[[" bezieht, ist Unsinn: test selbst hat in keiner Variante, weder built-in noch sonstwie, jemals Anführungszeichen "gebraucht", aber aus Gründen der Sicherheit verwendet man sie trotzdem. Da die Shell das Leerzeichen als IFS (internal field separator) verwendet, ist das folgende Konstrukt:

x="mehr als ein Wort"
if [ $x = $y ] ; then

nämlich für die Shell nicht mehr zu verstehen: erst wird "$x" in seine Bestandteile aufgelöst und danach wird versucht, die resultierende Zeile

if [ mehr als ein Wort = $y ] ; then

zu interpretieren. Da aber nach einem Argument wie "mehr" ein Operator erwartet wird, was "als" nicht ist, gibts einen Fehler - und zwar bei JEDER Variante von test! --bakunin (Diskussion) 11:14, 2. Feb. 2014 (CET)

if abfragen mit exteren Programmen

Da wird im Abs. Programmierung festgestellt: "So wird beispielsweise bei der Verzweigung die Bedingung nicht von der Shell selbst ausgewertet, sondern an ein weiteres Programm übergeben". Und genau das erste Beispiel hinter diesem Satz ist kein externes Programm sondern ein builtin.

Im übrigen: nutzen andere Shells nicht auch externe Programme wie "test" für if-Abfragen? -- Blindblind weil BLind zu aehnlich (Diskussion) 03:18, 20. Apr. 2012 (CEST)

Vergl. m. a. Programmiersprachen

Ich habe oben schon die Formulierung/Beispiele zum If-Statemaent und ext. Programmen etwas kritisiert. Mir scheint das ganze nicht ausgegohren. Die Behauptung Bash-Programmierung unterscheidet sich in vielen Punkten von anderen Programmiersprachen ziehe ist stark in Zweifel.

Ich bin mit der bash aufgewachsen und kenne das Umgfeld nicht gut genug um es wirklich zu beurteilen. Der oben zitierte Satz ist, wenn man ihn Spitzfindig auslegt, sicherlich richtige. Im Vergl. mit irgendeiner Programmiersprache ist die Nutzung externer Prog. sicherlich richig. Im Vergl. mit anderen Shells wird es wohl nichts besonderes sein. Im Gegenteil: ich kenne wie gesagt die einzelen Shells zu wenig - aber ich kenne das Konzept von Unix. Und es gehört zum Konezpt das man bestehende Programem nutzt. Die Programme "true", "false", "test" und alle anderen die einen Exit-Status generieren sind ja nicht exkl. für dich bash geschrieben.

Im übrigen: selbst in DOS-Batchdatein (command.com war ja auch nur ne Shell) konnte man den ERRORLEVEl (ich will hier keine Aufmerksamkeit erregen - ich glaube es musste wirklich gross geschrieben werden) abfragen. Und ob ich dann den Exit-Status mit ERRORLEVER oder if Abfrage kommt ja nun auf das gleiche raus. -- Blindblind weil BLind zu aehnlich (Diskussion) 15:18, 20. Apr. 2012 (CEST)

Beispiele: Besonderheiten

Die Bespiele überschneiden sich mit dem Artikel Unix-Shell vielleicht sollte man eher auf die Besonderheiten zu anderen bournekompatiblen/bourneähnlichen Shells eingehen. --Thaodan (Diskussion) 16:47, 28. Dez. 2012 (CET)

Ein- und Ausgabe, stdin, stdout, stderr

Dieser Abschnitt erweckt den Eindruck, als ob stdin, stdout, stderr Ideen und Besonderheiten der Bash wären, und nicht grundlegende Bestandteile von Unix und der C Standard Library.

Vor allem der Satz: "Ein in der Bash ausgeführtes Programm liest von der Standardeingabe..." ist schlichtweg falsch; ein Programm liest genau dann von der Standardeingabe, wenn es dazu programmiert wurde. Der Satz legt nahe, dass Programme, die sonst z.B. Daten woanders her lesen, in der Bash magischerweise dann von der Standardeingabe lesen, was natürlich Blödsinn ist. --178.191.184.237 06:53, 19. Feb. 2013 (CET)

Der ganze Artikel strotzt nur so vor ähnlichen Dingen, siehe die Abschnitte mit "eingebauten" Variablen oder Abschnitt Programmierung. --Thaodan (Diskussion) 12:01, 1. Apr. 2013 (CEST)

Konfiguration

Der Abschnitt ist völlig mißglückt:

1. ist /etc/skel eine Linux-Besonderheit und hat aber schon gar nichts mit der bash zu tun.
2. Die Funktion von /etc/profile ist offenbar völlig mißverstanden worden, abgesehen davon, daß die Datei ebenfalls nicht mit der bash zu tun hat. Zur Klarstellung:
   /etc/profile wird immer ausgeführt, wenn sich ein User zu einer interaktiven Session anmeldet (also zB nicht, wenn er sich zu einer ftp-Session anmeldet). Es wird vom login-Kommando angestoßen und ist von der Shell völlig unabhängig. Allerdings startet der login-Prozeß auch eine Shell - und zwar diejenige, die in /etc/passwd festgelegt ist.
   Das Shell-Profile wird jedesmal ausgeführt, wenn eine Shell-Instanz startet, also auch (aber nicht nur) dann, wenn eine Login-Shell gestartet wird. Das Shell-Profile ist abhängig von der Art der jeweils gestarteten (Login-)Shell. Bei der bash ist es ~/.bashrc, bei der ksh ist es ~/.kshrc.
3. Es kann eine systemweite Grundeinstellung (System Profile)geben (muß es aber nicht, bzw., selbst wenn es sie gibt, kann sie ignoriert/deaktiviert werden). In dem Falle wird sie im User Profile üblicherweise eingesourced:

# example of ~/.bashrc
. /etc/bashrc            # systemweites RC-file eingesourced

...rest of ~/.bashrc

--bakunin (Diskussion) 23:36, 22. Jun. 2013 (CEST)

LANG=en

Meines Wissens nach ist (zumindest unter Linux) "LANG=en" nicht üblich und funktioniert meist nur, weil der Wert "en" invalid ist und deswegen auf die Fallbacksprache, zufällig ebenfalls Englisch, zurückgegriffen wird. Wenn ich mich nicht täusche, sollte man das Beispiel evtl. ändern. --pcworld (Diskussion) 23:38, 10. Aug. 2013 (CEST)

Ich wäre auch dafür, das zu ändern. Zu LANG=C, denke ich mal? --Gorlingor (Diskussion) 15:18, 16. Aug. 2013 (CEST)

Lemma

Laut Manpage und Webseite des Projektes lautet die korrekte Schreibweise der Shell Bourne-Again SHell; aber ist die Shell nicht ohnehin unter der Abkürzung Bash bekannter? Ich bin für eine Umbenennung in Bash (Shell) oder Bash (Unix-Shell) (oder zumindest in die laut Autoren richtige Schreibweise). --Kthx (Diskussion) 11:32, 28. Jan. 2014 (CET)

+1 für Bash (Shell) -ZT (Diskussion) 11:54, 28. Jan. 2014 (CET)

Auch auf die Gefahr, voreilig zu handeln: Der Widerstand hier ist überschaubar, Einigkeit in der Mehrheit, ich bin dann mal so frei. Die Verlinkung auf der BKS Bash ändere ich gleich selbst, die weiteren Links werden hoffentlich von Bots übernommen... -ZT (Diskussion) 03:03, 2. Feb. 2014 (CET)

Restricted Shell

Sollte hier nicht auch, der Vollständigkeit halber, die restricted shell erwähnt werden? Also die eingeschränkte Variante, die man mit 'rbash', 'bash -r' bzw. 'bash --restricted' erhält? Oder wäre das eher was für einen eigenständigen Artikel, wie in der en-Wiki, zu sh, ksh und bash? --ph0nq (Diskussion) 01:00, 14. Sep. 2014 (CEST)

(1/2 OT) rc ist doch keine Shell?

Suche "fellow experts". Hab ich hier gefunden (aber da würde wohl nie einer in die Disk reinschauen): Rc Also ich halt das für totalen Unsinn. Sollte da /etc/rc gemeint sein, so handelt es sich um ein nur unter BSD übliches Skript, aber keine Shell als solche. Ich bin für ganz raus damit. -andy 2.242.160.138 01:40, 8. Dez. 2014 (CET)

rc ist die shell von Version 10 Unix und Plan 9, siehe en:rc. --Ath (Diskussion) 08:38, 8. Dez. 2014 (CET)

bash oder Bash (oder BaSH)

hauptsache gleichmäßig, warum eingmal in "Code"-Auszeichnung ist unklar.--Mideal (Diskussion) 12:19, 15. Aug. 2017 (CEST)

Neuere Bugs

2015-10-16

1377613: CVE-2016-0634 bash: Arbitrary code execution via malicious hostname

https://access.redhat.com/security/cve/cve-2016-0634

2016-09-16

1379630: CVE-2016-7543 bash: Specially crafted SHELLOPTS+PS4 variables allows command substitution https://access.redhat.com/security/cve/cve-2016-7543

2003:71:EF3D:7FFD:212:79FF:FE3E:B330 18:50, 29. Sep. 2017 (CEST)