Linux & Shell - Shell est-il un must?


8

Une question de débutant total.

Pourquoi avons-nous besoin d'un shell sous Linux? Par exemple, lorsque je tape - find. -name xy * - On m'a dit que le shell prend cette entrée et appelle la commande find (en s'assurant que le joker est correctement interprété et tout ça). Cela ne peut-il pas être fait sans le concept d'un shell? ... si le shell garde la trace des différents processus, cela ne peut-il pas être fait sans lui?

Aussi, pourquoi est-ce que je peux taper> ls xy * et obtenir une sortie appropriée pendant que je dois échapper * avec un \ in find - find. -name xy \ * Le shell effectue-t-il l'extension générique pour l'un et pas pour l'autre exécutable?

Je vous remercie.

linux  bash  shell 

9
Utiliser Linux sans shell, c'est comme conduire Ferrari à 50 km / h dans la circulation urbaine. Tout plaisir disparaîtra.
vava

Réponses:


23

Cela ne peut-il pas être fait sans le concept d'un shell?

Et bien non. Vous avez besoin de quelque chose qui interprète votre intention et appelle le programme approprié. Cette chose s'appelle un shell.

EDIT: Pour éviter toute confusion, «shell» ne signifie pas «interface de ligne de commande». Depuis http://en.wikipedia.org/wiki/Shell_(computing) :

"Les shells du système d'exploitation se classent généralement dans l'une des deux catégories suivantes: ligne de commande et graphique. Les shells de ligne de commande fournissent une interface de ligne de commande (CLI) au système d'exploitation, tandis que les shells graphiques fournissent une interface utilisateur graphique (GUI). catégorie le but principal du shell est d'appeler ou de "lancer" un autre programme; cependant, les shells ont souvent des capacités supplémentaires telles que l'affichage du contenu des répertoires. "

Quant à votre autre question, le shell fait une expansion générique pour les deux commandes, mais lorsque vous recherchez des fichiers en utilisant find, vous voulez trouver, et non le shell, pour faire l'expansion, car vous voulez que cela se fasse dans les emplacements que find recherche dans et non à l'endroit d'où il a été invoqué; par conséquent, vous échappez à * pour empêcher le shell de le développer, afin que find puisse le voir.


donc, vous dites que dans Windows, le bouton Démarrer est appelé un shell? :-)

5
Ce n'est pas une utilisation courante, mais les interfaces graphiques sont sans doute des shells (du moins si elles s'exécutent en dehors du noyau). Le bouton Démarrer n'est qu'une fonctionnalité de l'interface graphique ...
dmckee --- chaton ex-modérateur

Le bouton Démarrer est définitivement une chose "qui interprète votre intention et appelle le programme approprié". OTOH, le shell Linux peut simplement être appelé une fonctionnalité de TUI (Text User Interface).

11
@Paul: Explorer, le programme qui fournit le bouton de démarrage est le shell Windows. En fait, c'est un shell Windows; il peut être remplacé.
moonshadow

1
Oui, le bouton de démarrage peut être vu comme un shell. Pas un shell interactif mais un shell néanmoins. Cependant, lorsque quelqu'un dit "shell", cela signifie généralement une invite interactive (par exemple, l'invite de commande sur Windows est un shell traditionnel)

5

Vous pouvez bien sûr tout faire via une interface graphique. Les fichiers de recherche de Windows (à partir de XP et versions antérieures) sont un équivalent quelque peu graphique de la commande que vous avez tapée.

Maintenant, pourquoi les utilisateurs UNIX (et Linux) aiment-ils le shell? Parce que vous pouvez prendre la sortie, l'introduire dans un autre programme et obtenir une sortie différente. Par exemple:

find | grep burek

Ce sont deux commandes findet l' grepune alimentant l'autre. findrépertorie tous les fichiers dans les dossiers en cours et tous les dossiers enfants, un par ligne, et grepimprime uniquement les lignes qui contiennent burek.

Maintenant, il y a d'autres choses plus complexes, telles que:

ls -R | sort | uniq

ls -Rrépertorie les fichiers dans les dossiers actuels et enfants et sorttrie la sortie. uniqnous donne alors que des lignes uniques.

Maintenant, alors que vous pouvez coder tout cela dans une interface graphique, vous pouvez rapidement faire des choses délicates avec la ligne de commande que vous ne pouvez pas normalement faire avec l'interface graphique à moins que vous n'écriviez la vôtre. Dans ce cas, il est plus rapide de simplement le taper en ligne de commande, n'est-ce pas?

Conclusion: si vous posez cette question, vous n'en avez pas besoin. La ligne de commande est inutile pour vous en tant qu'utilisateur régulier. La ligne de commande est cependant idéale pour les administrateurs système, pour les développeurs et ceux qui veulent jouer avec leur ordinateur de manière rapide, rapide et rapide.


1

Oui, vous pouvez exécuter la commande find sans shell - vous auriez besoin d'un programme pour le démarrer, et vous auriez besoin d'un programme pour afficher sa sortie. Souvent, vous utilisez des fonctionnalités du shell, et cette commande aura besoin d'un shell pour interpréter l'intention.

par exemple, la tuyauterie, la redirection et la globalisation sont une caractéristique du shell, et auront besoin d'un shell pour interpréter. "find. -name myfile" n'utilise aucune fonction d'un shell, et pourrait être exécuté sans shell. "find. -name myfile | sort> output" utilise à la fois la tuyauterie et la redirection et vous avez besoin d'un shell pour interpréter cela.

Quant à échapper à xy *, il y a peu de différence si c'est l'entrée à trouver ou la sortie d'une rediction, le shell va l'étendre de toute façon.

S'il y a un fichier nommé xyz dans le répertoire courant

trouver . -name xy * s'exécutera en fait comme find. -nom xyz, ce qui n'est probablement pas ce que vous voulez.

Si vous trouvez. -name xy * et il n'y a pas de fichier correspondant à xy * dans le répertoire courant, il fonctionnera comme find. -nom xy *.

De même, s'il n'y a pas de fichier correspondant à xy * dans le répertoire courant, ls> xy * créera un fichier nommé xy *. S'il y a un fichier correspondant - disons xyz, cela signifie ls> xyz. S'il y a plusieurs fichiers correspondant à xy *, alors ls> xy * échouera.

En savoir plus http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO.html


Mode lecture où?
Thomi

1

Les OS non triviaux n'exécutent pas l'interpréteur de ligne de commande dans le noyau.

Ils l'exécutent en tant que programme, et ce programme s'appelle un shell. La situation sur les interfaces graphiques semble être mitigée, mais au moins certains systèmes d'exploitation exécutent également ceux en dehors du noyau.

Maintenant, il n'y a absolument pas besoin de la coquille au travail comme le shell unix, mais vous ne besoin d' une interface.


1

Pour répondre à votre deuxième question ... le shell tentera de développer ce qu'il peut chaque fois qu'il le peut, sauf si vous l'empêchez. L'échappement de * empêche l'expansion, qui est généralement nécessaire pour la commande find.

Pour ne pas répondre à une question par une question, comment sauriez-vous si la commande ls répertorie les fichiers en raison d'une extension de la ligne de commande ou parce que la commande ls recherche légitimement la liste des répertoires à partir du système de fichiers? Par exemple, je pourrais écrire un shell for loop comme ceci:

for i in $(ls /home/mydir);

ou comme

for i in /home/mydir/*;

ils finissent par aboutir au même ensemble.


0
pourquoi est-ce que je peux taper> ls xy * et obtenir une sortie correcte tout en
J'ai besoin de m'échapper * avec un \ in find - find. -name xy \ * Is
shell faisant l'expansion du joker pour un et non pour le
autre exécutable?

Le point d'échapper '*' dans l'invocation find est d'empêcher le shell de faire l'expansion. En l'échappant, vous vous assurez que find voit les arguments: ".", "-Name", "xy *". Si vous n'avez pas échappé au '*', find verrait ".", "-Name", "xya", "xyz" (en supposant que le shell étend "xy *" à "xya xyz", ce qui arrivera si le les fichiers qui commencent par xy sont xya et xyz). Donc, la réponse à votre question est non, le shell ne développe pas le '*' dans votre invocation de find car vous lui avez explicitement demandé de ne pas le faire en l'échappant.


0

Shell sous Linux est un moyen pratique et conventionnel d'interagir avec le système de fichiers sous Linux et d'exécuter des commandes avec des arguments et en respectant les variables d'environnement. Il fournit de nombreuses fonctionnalités utiles, par exemple, la connexion de la sortie d'un processus à l'entrée d'un autre, la redirection des flux d'entrée / sortie vers / depuis des fichiers, des FIFO, etc. Un shell est un bon moyen de combiner facilement plusieurs petits programmes, chacun d'eux faire une tâche relativement petite, pour fournir quelque chose d'utile. Certains de ces programmes (tels que find et ls) ont été conçus pour fonctionner avec eux dans un shell.

Pour comprendre l'expansion, rappelez-vous simplement qu'un mot (séquence délimitée par des espaces de caractères aplhanumériques et -, et certains autres symboles), étant donné qu'il contient *ou ?des caractères de motif, n'est pas échappé ou placé à l'intérieur des guillemets ( ") ou des apostrophes ', est remplacé par une série de mots séparés par des espaces avec des noms de fichiers qui correspondent au modèle. Donc, si vous aviez un mot avec un astérisque, après expansion, vous aurez zéro, un ou plusieurs mots, qui seront traités par bash comme plusieurs arguments. Voici la conception spécifique de la lscommande: elle correspond parfaitement à ce schéma lorsqu'elle est utilisée ls foo*pour afficher tous les fichiers commençant par "foo"! Il est développé en quelque chose comme

ls foobar boobaz

et ls imprime simplement les fichiers à partir des arguments, vérifiant leur existence et les parcourant dans les dossiers, etc.

Mais c'est surtout la question de la philosophie. Dans d'autres systèmes, tout émerge du bouton "Démarrer" et de la barre des tâches. Certains utilisateurs sont d'accord avec cela. Certains essaient d'installer un shell de type Linux dans de tels systèmes. C'est une question de goût, mais pour la programmation de scripts simples, qui traitent de fichiers, le shell est extrêmement pratique.


0

Pour les commandes interactives, le shell peut être remplacé par l'interface graphique.

Mais le point clé du shell est qu'il s'agit d'un langage de script: vous pouvez créer des programmes entiers qui sont exécutés dans des situations spécifiques (démarrage, ouverture de session, tous les jours, ...). Cette fonctionnalité ne peut pas être remplacée par d'autres outils.


Et bien sûr, vous pouvez planifier des scripts shell aveccron
Wuffers

0

Bien sûr, vous pouvez exécuter Linux et ne jamais utiliser le shell. De nombreuses distributions Linux standard offrent à l'utilisateur à domicile exactement ce dont il a besoin s'il veut simplement consulter Facebook, regarder des photos et envoyer des e-mails.

Linux a de nombreux avantages, mais le shell est probablement le meilleur. Le shell permet la redirection d'E / S. C'est ce dont les gens parlent lorsqu'ils font référence à des tuyaux ("|"). Par exemple:

Je souhaite me connecter à une liste de machines et effectuer une enquête sur l'emplacement d'un compte utilisateur:

for host in `cat hostnames.txt1`; do
echo "Connecting to $host"
ssh $host "cat /etc/passwd | grep -i username"
done

Il pourrait y avoir 0 hôte dans hostnames.txt ou il pourrait y en avoir des milliers. Ce script se déplacera et fera le sondage, en crachant les informations sur stdout.

Les scripts peuvent devenir très créatifs. Je peux utiliser les caractères "/ >>" pour rediriger les entrées / sorties depuis et vers les fichiers. Je pourrais examiner toutes ces machines dans le script ci-dessus, sortir le nom du serveur de tous ceux qui ont l'utilisateur dans un fichier, puis suivre avec un autre script qui se connecte et effectue une tâche sur le compte utilisateur (verrouiller / déverrouiller / réinitialiser pw / supprimer / ajouter un groupe / etc).

Apprendre. À. Scénario. =)

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.