ls = shell = coreutils = ???

[muckelfloh]

Hallo zusammen!
Ich arbeite mich gerade in die Shell (???) ein und bin da nun über ein (für mich) komisches Ding gestolpert.
Wenn ich zum Beispiel ls eingebe wird das Verzeichnis aufgelistet. Dieses ls ist für mich ein Befehl der Sprache Shell. Nun bin ich aber darüber gestolpert dass das eigentlich ein Befehl der Coreutils ist.

Gehts noch verwirrender? Was ist denn nun was?

[JaKlaRo]

Code: Alles auswählen

apt-cache show coreutils

[muckelfloh]

Und was sagt mir die Ausgabe nun?
Lerne ich Shell, lerne ich Coreutils oder lerne ich beides auf einmal?

[uname]

Naja. In der Shell gibst du Befehle ein. Einige grundlegende Befehle sind hierbei im Paket coreutils zusammengefasst.

Code: Alles auswählen

dpkg -S /bin/ls
man ls

zeigt dir, dass das Programm zu "coreutils" gehört. Im übrigen ist die Shell schon ein anderes Programm.

Auch andere Programme z.B. unter /usr/bin , die du in der Shell eingeben kannst sind Zusatzpakete. Es gibt nur sehr wenige Befehle, die nicht direkt als Paket erkennbar sind. Schau dir z.B. den Befehl "bg" an.

Vergleiche

Code: Alles auswählen

which ls
which bg

[TobiSGD]

Hallo zusammen!
Ich arbeite mich gerade in die Shell (???) ein und bin da nun über ein (für mich) komisches Ding gestolpert.
Wenn ich zum Beispiel ls eingebe wird das Verzeichnis aufgelistet. Dieses ls ist für mich ein Befehl der Sprache Shell. Nun bin ich aber darüber gestolpert dass das eigentlich ein Befehl der Coreutils ist.

Gehts noch verwirrender? Was ist denn nun was?

Ja, es geht noch verwirrender. Du arbeitest dich nämlich gar nicht in die Shell ein, sondern nur in eine davon, in deinem Fall wird das die Bash-Shell sein. Davon gibt es nämlich verschiedene. Deswegen gibt es auch keine Sprache Shell, was du lernst ist eine Mischung aus den Befehlen der Shell Bash und den Gnu-Tools. Zu den Gnu-Tools gehören so spannende Dinge wie ls, grep, ps und so weiter, und diese findest du im Paket core-utils. In die Shell eingebaute Befehle sind zum Beispiel cd und die Kontrollstructuren, wie if/the oder for.
Aufgrund dieser Trennung funktioniert zum Beispiel der grep-Befehl auch in der zshell oder der korn-shell. Nur die eingebauten Befehle der Shells unterscheiden sich, wobei aber die meisten Shells mindestens grob kompatibel zur Bash sind.

[muckelfloh]

Vergleiche

Code: Alles auswählen

which ls
which bg

Der Befehl which bg zeigt gar nichts an und der Befehl which ls zeigt bin/ls
Schaue ich jedoch in das Verzeichnis bin, finde ich dort kein ls auch nicht wenn ich versteckte Dateien anzeigen lasse.
Wieso nicht?

Und ganz wichtig: Vielen Dank für Deine Mühen!!!

[muckelfloh]

Ja, es geht noch verwirrender. Du arbeitest dich nämlich gar nicht in die Shell ein, sondern nur in eine davon, in deinem Fall wird das die Bash-Shell sein. Davon gibt es nämlich verschiedene. Deswegen gibt es auch keine Sprache Shell, was du lernst ist eine Mischung aus den Befehlen der Shell Bash und den Gnu-Tools. Zu den Gnu-Tools gehören so spannende Dinge wie ls, grep, ps und so weiter, und diese findest du im Paket core-utils. In die Shell eingebaute Befehle sind zum Beispiel cd und die Kontrollstructuren, wie if/the oder for.
Aufgrund dieser Trennung funktioniert zum Beispiel der grep-Befehl auch in der zshell oder der korn-shell. Nur die eingebauten Befehle der Shells unterscheiden sich, wobei aber die meisten Shells mindestens grob kompatibel zur Bash sind.

Jetzt verstehe ich auch die Probleme die ich ab und an habe wenn ich aus einem Buch Befehle abtippe und der Compi nicht kapiert was ich von ihm will; der Befehl wurde einfach noch nicht installiert.
Du bist der geborene Erklärbär. Mit Deiner Art und der Möglichkeit darauf hin bei Wikipedia weiter zu forschen, ist das "Lernen" geradezu ein Klacks, es geht echt voran und macht höllisch Spaß.
Falls Du mal über ein LinuxBuch nachdenken solltest, ich kauf Dir gleich zehn ab

[WinMaik]

Das du in /bin kein ls hast, halte ich für sehr unwahrscheinlich.

Code: Alles auswählen

ls /bin | grep ls

sollte ls ausgeben, wenn das der Fall ist, hast du auch ls in /bin.
which bg sollte auch nichts anzeigen, da es kein eigenständiges Programm ist, sondern eben ein Teil der Bash.

[muckelfloh]

Das du in /bin kein ls hast, halte ich für sehr unwahrscheinlich.

Code: Alles auswählen

ls /bin | grep ls

sollte ls ausgeben, wenn das der Fall ist, hast du auch ls in /bin.
which bg sollte auch nichts anzeigen, da es kein eigenständiges Programm ist, sondern eben ein Teil der Bash.

ENTWARNUNG und ganz dolles Sorry: Ich habe aus Versehen in usr/bin geschaut. Unter bin habe ich ls.

[KBDCALLS]

Wozu ein Befehl gehört ob intern oder ein externer kann man erstmal sehen indem das mit Type überprüft.

Code: Alles auswählen

type -a ls

Das ergibt obiges bei mir

Code: Alles auswählen

ls is aliased to `ls --color=auto'
ls is /bin/ls

type von Dos/Windows und der Bash von Linux unterscheiden sich.

Der einzige Befehl der mir momentan einfällt der intern in der Bash und extern vorkommt ist pwd

Code: Alles auswählen

matthias@svetlana:~$ type -a pwd
pwd is a shell builtin
pwd is /bin/pwd

Welche builtins es in der Bash gibt läßt sich mit help feststellen.

Zu guter letzt kann man mit dlocate feststellen , zu welchem Paket ein Programm gehört.

Code: Alles auswählen

dlocate /bin/ls
dlocate /bin/pwd

und wenn ich wissen will welche Programme sich in einem bestimmten Paket befinden

Code: Alles auswählen

dlocate -lsbin coreutils

[roth]

Grüß Gott,

Falls Du mal über ein LinuxBuch nachdenken solltest, ich kauf Dir gleich zehn ab

Nicht immer gleich das Rad neu erfinden (lassen) wollen.
Du kennst schon die Beitragsfolge Bitte lesen: Einstieg in Debian?
Insbesondere das Debiananwenderhandbuch finde ich lesenswert.
Ansonsten kann ich Deine Stolperstellen nachvollziehen. Das hört sich nämlich so an, als wäre eine bisherige Bedinung von Rechnern rein grafisch basiert gewesen und eine Textkonsole ist nun Neuland. Insbesondere das modulare Konzept eines Unix-(artigen) Systems frei nach dem Motto "Regel-Nr. 1: Jeder macht seins!" bietet eben für jede Problemstellung grundsätzlich ein eigenes Programm, was wiederum in der Regel auch als separates Paket installiert werden kann. Aber gerade bei einer (textbasierten) Benutzerumgebung ("shell") werden einige Kommandos nicht als binäre Programme, sondern auch als Abkürzungen oder Aliase oder Skripte angeboten. Hauptsache der Bediener kann ein Kommando eingeben und das gewünschte Ergebnis erzielen.

Gruß
Sven

[muckelfloh]

Nicht immer gleich das Rad neu erfinden (lassen) wollen.
Du kennst schon die Beitragsfolge Bitte lesen: Einstieg in Debian?
Insbesondere das Debiananwenderhandbuch finde ich lesenswert.

Hallo Sven,
Danke für Deine Links!
Ich als absoluter Anfänger sehe wenn jemand gut erklären kann und TOBI kann es auf jeden Fall. Wieso soll ich da mit meinem Lob hinterm Berg halten wenn er es sich mehr als verdient hat?!

Zum Thema Linux gibt es im Web Anleitungen so weit das Auge reicht. Ebenfalls Bücher ohne Ende: Linux für Dummies, Nickles, Kofler, Handbuch von Gallileo, usw usf. Aber es gibt nur wenig gute. Dein Beispiel mit dem Debianhandbuch ist in meinen Augen nichts für absolute Anfänger. Ich kopiere hier mal einen Satz aus dem EINSTIEG!!!:

Code: Alles auswählen

adduser [--home DIR] [--shell SHELL] [--no-create-home] [--uid ID]

Tut mir Leid, ich verstehe NULL, NADA, NICHT DIE BOHNE!!!!! Und nun kommt etwas sehr wichtiges dazu: Du verstehst nicht was ich gerade schreibe, denn für Dich ist das völlig normal und alltäglich, deshalb kannst Du meine Schwierigkeiten nicht nachvollziehen. Du bist Profi, ich bin absoluter Anfänger. Und aus diesem Grund kann ich wesentlich besser einschätzen wer Erklären kann und wer nicht.
Tobi hat etwas was mindestens 90% der deutschen Lehrer nicht drauf haben -obwohl sie es können MÜSSTEN und auch denken sie können es- er kann einem Anfänger in ein zwei Sätzen schwierige Sachverhalte leicht erklären. Deshalb bin ich mir sehr sicher dass viele Leute seine Bücher kaufen würden wenn er denn welche schreiben würde.