Diskussion:Bash (Shell)

message: 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)
replies: text: 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)
thread_title:  Beispiel einer bash 

message: 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)
replies: text: Jedenfalls die doppelten eckigen Klammern sind Bash-spezifisch. Die "sh" kennt nur einzelne Klammern. -- Mfnalex (Diskussion) 14:14, 16. Jul. 2017 (CEST)
thread_title:  Programmierungabschnitt 

message: *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)
thread_title:  Vorschlag 

message: > 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)
thread_title:  Sachlicher Fehler bei builtin test-Statement 

message: 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)
thread_title:  if abfragen mit exteren Programmen 

message: 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)
thread_title:  Vergl. m. a. Programmiersprachen 

message: 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)
thread_title:  Beispiele: Besonderheiten  

message: 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)
replies: text:  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)
thread_title:  Ein- und Ausgabe, stdin, stdout, stderr 

message: Der Abschnitt ist völlig mißglückt:
# ist /etc/skel eine Linux-Besonderheit und hat aber schon gar nichts mit der bash zu tun.
# 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.
# 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)
thread_title:  Konfiguration 

message: 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)
replies: text: Ich wäre auch dafür, das zu ändern. Zu LANG=C, denke ich mal? --Gorlingor (Diskussion) 15:18, 16. Aug. 2013 (CEST)
thread_title:  LANG=en 

message: 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)
replies: text: +1 für Bash (Shell) -ZT (Diskussion) 11:54, 28. Jan. 2014 (CET)
replies: text: 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)
thread_title:  Lemma 

message: 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)
thread_title:  Restricted Shell 

message: 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)
replies: text: rc ist die shell von  Version 10 Unix und Plan 9, siehe :en:rc. --Ath (Diskussion) 08:38, 8. Dez. 2014 (CET)
thread_title:  (1/2 OT) rc ist doch keine Shell? 

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

message: 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)
thread_title:  Neuere Bugs