Diskussion:Unix-Shell/Archiv/1
Interaktiv
"nicht interaktiv" ist vielleicht bei der C-Shell eine etwas unglückliche Formulierung, denn was ist schon interaktiv. Kommandozeileneingabe ist doch auch schon interaktiv. Ich würde so definieren:
- Der alte Batch Betrieb ist nicht interaktiv
- Programm nach dem Schema Eingabe/Verarbeitung/Ausgabe sind nicht interaktiv
- Hintergrundprogramme sind nicht interaktiv
Das meist, das nicht in diese Kategorien fällt, ist damit interaktiv. Damit sollte bei der C-Shell klarer formuliert werden, was gemeint ist. Hubi 08:46, 8. Mär 2004 (CET)
- Der Begriff "interaktiv" hat eine feste Bedeutung in Zusammenhang mit Shells. Es werden nun mal auf der einen Seite Login- u. Non-Login-Shells und auf der anderen Seite Interactive- u. Non-Interactive-Shells unterschieden, sodass sich hieraus 4 mögliche Zustände bilden lassen. Eine Interactive-Shell hat ein Control-Terminal zugeordnet und z. B. bei der Bash wird zum Einlesen von Zeilen Readline verwendet (was erweiterte Editiermöglichkeiten für den Benutzer ergibt. --Catwisle 14:52, 16. Nov 2005 (CET)
- Per Definition ist ein Shell dann interaktiv, wenn er Kommandos von einer Terminalschnittstelle liest. Tut er das nicht, dann schaltet ein Shell in einen anderen Modus. Schily 13:10, 1. Mär. 2010 (CET)
- „An interactive shell is one ... whose input and error output are both connected to terminals ... An interactive shell generally reads from and writes to a user’s terminal.“Bash Reference Manual Eine interaktive Shell liest von einem Endgerät und gibt eventuelle Rückmeldungen auf einem Endgerät aus. Nicht mehr und nicht weniger. --84.157.202.213 01:12, 15. Jul. 2013 (CEST)
Einzelne Shells auf Einzelseiten
Ich bin dafür einigen Shells eine eigene Seite zu geben (z.B. Bourne) Vinci 16:18, 11. Nov 2004 (CET)
- Ich schliesse mich Dir an. Warum nicht jeder Unix-Shell einen eigenen Artikel spendieren? -/dev/tonne
- (falsch signierter Beitrag von Devnull (Diskussion | Beiträge) 22:54, 11. Aug. 2005 (CEST))
- seh ich genauso. in diesem artikel die gemeinsamkeiten, den rest auslagern. das wird langsam unübersichtlich. -- ∂ 23:00, 11. Aug 2005 (CEST)
- Spricht etwas dagegen, einen einzelnen Artikel für manche Shells (bash, zsh, etc.) anzulegen und diese zu verlinken? --87.171.92.153 11:04, 10. Mär. 2008 (CET)
- Nichts spricht dagegen. Sei mutig und schreibe einen! Er müsste allerdings aus mehr bestehen, als hier schon steht. Auch sollte dieser Artikel dadurch nicht gekürzt werden. Was ich damit meine ist, dass es nicht in Ordnung ist, wenn du diesen Artikel einfach in viele kleine zerteilst. --Thornard, Diskussion, 09:26, 24. Apr. 2008 (CEST)
"ursprünglichste" Unix-Shell
Die Bourne-Shell ist nicht die "ursprünglichste" Unix-Shell. Bereits einige Jahre vor ihr existierte die Thompson-Shell (Unix Verion 1 bis 6), in der sowohl *Pipes* gebaut, als auch Hintergrundprozesse gestartet werden konnten. Zwar konnte man nicht explizit Variablen verwenden, einfache Programmierungen waren jedoch über einen extern realisierten if- und goto-Befehl möglich. Die Bourne-Shell ist Ahne der gängigen modernen Shells; die Shell-Geschichte beginnt jedoch nicht mit ihr.
(nicht signierter Beitrag von 217.184.16.205 (Diskussion) 15:47, 11. Mär. 2005 (CET))
bash
In der modernen bash kann man das Beispiel mit der Schleife auch folgendermaßen schreiben:
#!/bin/bash
for (( i=1 ; i<=100 ; i++ ))
do
echo "$i"
done
(nicht signierter Beitrag von 141.113.101.23 (Diskussion) 09:45, 14. Jun. 2005 (CEST))
sash
Könnte man vielleicht noch die sash (Standalone Shell) vermerken? (nicht signierter Beitrag von Pddywnger (Diskussion | Beiträge) 13:21, 15. Aug. 2006 (CEST))
Weblinks
Moin!
Ich habe alle Weblinks hier entfernt, da sie nur zu Unterthemen zeigen, die sollen laut WP:WEB nur in den Artikeln zu diesen Unterthemen (Bash, Zsh, etc...) --Trublu ?! 12:23, 7. Jul. 2007 (CEST)
- Es ist aeusserst unpraktisch, dass es zu den einzelnen Programmen keinerlei Querverweise ins Netz und insbesondere nicht zu den Entwicklerseiten gibt! Hauptsache, das Reglement ist erfuellt. Warum bezieht sich Trublu auf Unterthemen-Artikel (Bash, Zsh), die gar nicht existieren? --84.146.96.114 12:00, 29. Dez. 2007 (CET)
Weil Weblinks unerwünscht sind und nur in genau umschriebenen Fällen (WP:WEB) doch zulässig sind. Dazu gehört, dass Unterthemen keine Weblinks bekommen - es sei denn sie sind relevant genug um eigene Artikel zu haben (Und die Weblinks dann dort hinkommen). Vgl auch WP:WWNI Punkt 7.3: [...] keine Linksammlung. --Trublu ?! 12:13, 29. Dez. 2007 (CET)
- Ein Link zur Entwicklerseite wäre meiner Meinung nach sogar als Quelle notwendig. --Thornard, Diskussion, 09:26, 24. Apr. 2008 (CEST)
Schnittstelle
Dieser (und andere) Artikel basieren ist zu sehr auf der primitiven Architektur eines PCs bei dem viele Komponenten zusammenfallen. Daher sine viele Darstellungen inakkurat und irreführend.
Eine treffende Beschreibung einer Shell ist in der man-page der Korn Shell zu finden:
Ksh [wie jede andere Shell] is a command and programming language that executes commands read from terminal or a file.
Punkt!
Auch ist eine Shell keine Benutzereschnitstelle. Ein Zeichen- oder Grafikterminal ist die Benutzerschnittstelle. Der Benutzter sitzt (weit weg) vor dem Terminal (= Schnittstelle) und die Eingaben werden u.a. über ein Device an die Shell geleitet.
Eine Shell ist genaugenommen eine Schnittstelle zur Programmsammlung eine DVA.
(nicht signierter Beitrag von Ahaack (Diskussion | Beiträge) 01:16, 20. Okt. 2007 (CET))
- Die Beschränkung der Schnittstelle auf die Hardware erscheint mir willkürlich. Ich würde es für viel sinnvoller halten, die Schnittstelle als die Gesamtheit dessen aufzufassen, was nötig ist, um als Benutzer mit dem Betriebssystem zu interagieren und z. B. Befehle abzusetzen; dazu gehört selbstverständlich auch eine textuelle oder graphische Shell. Aus der Tatsache, daß im oben zitierten Sätzchen über die ksh das Wort Interface (Schnittstelle) nicht vorkommt, kann jedenfalls nicht gefolgert werden, daß es sich nicht um ein solches handele. --Tobias 16:06, 4. Jul. 2008 (CEST)
- „A Unix shell is both a command interpreter and a programming language.“[1] Der Unterschied zwischen beidem ist die Syntax, durch die aus einzelnen Kommandos komplexe Ausdrücke werden. Der Kommandointerpreter und die Programmiersprache sind in einem gemeinsamen Computerprogramm implementiert. Bei frühen Unix-Shells von einer eigenen Programmiersprache zu sprechen, ist jedoch gewiss überzogen. In Richtung Benutzer kennt eine Shell nur Schnittstellen wie stdin und stdout, die für sie Dateien gleichen. Eine Shell ist eine Schnittstelle zum Betriebssystem, aber nicht direkt für den Benutzer. Das ist wesentliches Merkmal der Architektur und Ursache ihrer Portierbarkeit. Eine Schnittstelle als Gesamtheit von irgendetwas aufzufassen, ist so ziemlich das Gegenteil dessen, was der Begriff bedeutet. --84.157.202.213 01:12, 15. Jul. 2013 (CEST)
Interne Komandos
Interne Kommandos oft kein Feature sondern eine technische Notwendigkeit und damit nicht erwähnenswert. So war z.B. cd in der ersten Unix Variante ein externes Programm.
Mit der Einführung des fork und exec Mechanismus funktionierte der Befehl nicht mehr:
fork dupliziert den Shell Prozess und exec läd cd diese wechselt das Working Dir und dann terminiert der Prozess. Daher musser es als internes Komando entwickelt werden.
>type expr expr is /usr/bin/expr
ist ein externes Kommando.
Aber :
>echo $((2+2)) 4
test
ist sowohl extern als auch intern.
(nicht signierter Beitrag von Ahaack (Diskussion | Beiträge) 02:23, 20. Okt. 2007 (CET))
- Also die älteste Shell Source die ich finden kann ist die von UNIX V5 und die hat sehr wohl etwas wie "cd" als eingebautes Kommando. Das geht auch gar nicht anders. Allerdings hieß der Befehl vor UNIX V6 "chdir". Grund: Später kamen 110 Baud Modems und die Kommandonamen wurden zur Effizienssteigerung verkürzt. Selbst der Bourne Shell akzeptiert heute noch "chdir". Schily 13:00, 1. Mär. 2010 (CET)
- Genauer: die Bash ruft bei Verwendung doppelter eckiger Klammern ([[ ... ]]) eine eingebaute Version des Test-Kommandos auf, ansonsten das eigenständige Programm. Vorteil ist eine gesteigerte Ausführungsgeschwindigkeit (weil kein neuer Prozeß gestartet werden muß), Nachteil die reduzierte Portabilität (funktioniert nicht mit der Bourne-Shell; deswegen sollte der She-Bang-Kommentar auf /bin/bash verweisen).
- Ich finde übrigens, daß technische Notwendigkeiten durchaus erwähnenswert sind, zumal die Kenntnis des Unterschieds zwischen internen und externen Kommandos ja nicht ganz unwichtig ist. Im übrigen gibt es eben Features, die aus technischen Notwendigkeiten geboren wurden; insofern ist das kein Widerspruch. --Tobias 15:16, 4. Jul. 2008 (CEST)
- Das ist auch so nicht richtig: Doppelte runde Klammern sind eine Korn Shell und nicht im Buourne Shell bekannt. Allerdings wird bei if [ bla = huhu ] auch schon beim Bourne Shell ein eingebautes "test" verwendet, denn "[" ist ganz einfach ein Alias für das "test" Kommando. Schily 13:03, 1. Mär. 2010 (CET)
- Angesagt waren doppelte eckige Klammern und nicht doppelte runde Klammern ;)
- Eine Bourne Shell hab ich jetzt nicht leider nicht vor Ort, aber eine Bourne Again Shell:
m@devel:~> which \[ /usr/bin/[ m@devel:~> file /usr/bin/\[ /usr/bin/[: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.4, stripped m@devel:~> rpm -ql /usr/bin/\[ package /usr/bin/[ is not installed m@devel:~> rpm -qf /usr/bin/\[ coreutils-7.1-11.1.1.x86_64 m@devel:~>echo $SHELL /bin/bash m@devel:~ #
- Irgendjemand gerade mit einer Bourne Shell zur Hand? (--Anniyka 13:46, 11. Jan. 2011 (CET))
Skripts
- Ausführung von Kommandos in Dateien, so genannte Skripts.
Shells unterscheiden Skripts nicht von anderen Programmen, denn beide werden über den exec Call von Kernel gestartet. Der Kernel interpretiert das #!.
(nicht signierter Beitrag von Ahaack (Diskussion | Beiträge) 02:23, 20. Okt. 2007 (CET))
- "Einige" Betriebssystemkerne interpretieren das #!. Generell gilt: Bei einem Skript liefert der Kern ENOEXEC (invalid magic number) und der Shell reagiert auf diesen "Fehler" durch interpretieren des Inhaltes der Datei. Schily 13:06, 1. Mär. 2010 (CET)
Zugrundeliegender Terminal-Gerätetreiber
"Hinsichtlich des Abbruchs eines Kommandos machen sich die Shells die Eigenschaften des zugrundeliegenden Terminal-Gerätetreibers zunutze" -- Kann jemand erklären, was es damit auf sich hat? --Dk 20:15, 29. Nov. 2007 (CET)
Kompatibilitätschaos
Bisher habe ich immer mit Suse gearbeitet und nun auf Ubuntu gewechselt. Und ich habe mir immer eingebildet, das ich gut dokumentierte und leserliche Shell-Scripte schreibe. Folgendes läuft nach der Umstellung nicht mehr:
#!/bin/sh
function HalloWelt () # Definition der Funktion Hallo Welt
{
echo 'Hallo Welt'
}
HalloWelt # Aufruf der Funktion Hallo Welt
Den Grund habe ich auch gefunden. Unter Ubuntu und Suse zeigt der Link sh jeweils auf andere Shells:
- Unbuntu: sh -> dash
- Suse: sh -> bash
Und die dash kennt offensichtlich nicht das Schlüsselwort "function". Folgendes läuft also nun unter Ubuntu (weglassen des Schlüsselworts "function"):
#!/bin/sh
HalloWelt () # Definition der Funktion Hallo Welt
{
echo 'Hallo Welt'
}
HalloWelt # Aufruf der Funktion Hallo Welt
Lesefreundlich finde ich das gerade nicht ... natürlich gäbe es auch die Möglichkeit den Link passend umzubiegen oder im Shebang die bash anzugeben damit das Script läuft.
Aber insgesamt ärgert es mich, das man bei der Fehleranalyse und Behebung völlig unnütz Lebenszeit verplämpert (hoffe wenigstens das diese Zeilen irgendwem nützen - vieleicht kann man so ein Beispiel ja auch in den Artikel aufnehmen).
In den manpages von bash und dash ist die Definition einer Funktion auch entsprechend den tatsächlichen Gegebenheiten definiert. Wie es die urspüngliche sh hält, zu der ja beide kompatibel sein wollen, ist wohl nur durch Detektivarbeit rauszukriegen (und da sind wir wieder bei der Zeitverschwendung eines unschuldigen Gelegenheits_shell_Programmierer). -- Nohome 13:29, 11. Jan. 2011 (CET)
- Du hast gut dokumentierte Shell-Skripte geschrieben und dir keine Gedanken über die erste Zeile gemacht? Dann wurde es Zeit. --84.157.202.213 01:12, 15. Jul. 2013 (CEST)
- function ist etwas was die bash zusätzlich beherrscht. Für die sh ist nur ein () hinter dem Funktionsnamen nötig für die sh Kompatibilität also kein function. Das läuft auch unter der bash. Die bash ist also weiterhin kompatibel zur sh. --Anniyka 13:57, 11. Jan. 2011 (CET)
- Aus man bash
If bash is invoked with the name sh, it tries to mimic the startup behavior of
historical versions of sh as closely as possible, while conforming to the POSIX
standard as well.
When invoked as sh, bash enters posix mode after the startup files are read.
[ function ] name () compound-command [redirection]
This defines a function named name. The reserved word function is
optional.
- Hilft das weiter? --Anniyka 14:10, 11. Jan. 2011 (CET)