Vous n'êtes pas identifié(e).
Je ne pense pas qu'il soit nécessaire de séparer les sujets pour ces 3 pages pour l'instant. On verra si ça le devient.
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
============
De par la définition même d'un flux (déplacement d'informations), qui implique donc une direction à ce déplacement,
je pense qu'on est si près de ça qu'il pourrait être très simple et édifiant pour le lecteur
de lui présenter par un petit schéma les 3 "flux standards" : stdin stdout et stderr.
Ceci, bien sûr juste avant de lui exposer les concepts de redirection de flux.
Dernière modification par MicP (01-10-2013 08:37:27)
Ben
___________________
La seule question bête, c'est celle qu'on ne pose pas.
Hors ligne
Ce simple petit schéma pourrait aussi l'aider à mieux comprendre où se situe le shell.
Oui et non, il ne faut pas oublier que le shell est un programme comme les autres. Tous les programmes ont par défaut un stdin, un stdout et un stderr. D'ailleurs, quand on a un shell dans un émulateur de terminal sous X, c'est plutôt
matériel (clavier) -> noyau (via interruptions matérielles) -> serveur X -> (window-manager ->) émulateur de terminal -> terminal virtuel -> shell ou commande
Mais on peut lancer un programme directement dans un terminal, auquel cas le shell n'est plus présent dans le schéma.
Un shell peut également être lancé par un autre shell, etc. Donc trop de simplification me semble dangereux
De par la définition même d'un flux (déplacement d'informations), qui implique donc une direction à ce déplacement,
je pense qu'on est si près de ça qu'il pourrait être très simple et édifiant pour le lecteur
de lui présenter par un petit schéma les 3 "flux standards" : stdin stdout et stderr.
|====================|
| stdin <--
| Programme |
| stdout -->
| stderr -->
|====================|
Ceci, bien sûr juste avant de lui exposer les concepts de redirection de flux.
Ceci est lié aussi bien au terminal qu'au shell (en fait, à tous les processus), mais oui, la présentation de ces flux mérite d'être faite si ça n'est pas déjà le cas, dans la page chevrons ou chevrons-2. (Je crois que c'est fait dans la deuxième.)
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
Hors ligne
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
Hors ligne
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
Ben
___________________
La seule question bête, c'est celle qu'on ne pose pas.
Hors ligne
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
Hors ligne
Cool, tu peux parler de ';' au même endroit à mon avis, et surtout donner un lien vers ici : http://debian-facile.org/doc:progr … ll:avancee puisque les && et les if sont un peu la même chose…
C'est fait
Mais bon, reste que quand on veut comprendre le fonctionnement du bouzin, faut lire.
Certes, laissons comme ça alors
Ben
___________________
La seule question bête, c'est celle qu'on ne pose pas.
Hors ligne
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
par exemple je crée un fichier "script.age" dans mes documents contenant
Je donne les droit d'exécution
pour exécuter on doit faire depuis le répertoire parent :
2) (qui correspond à ton premier paragraphe) indiquer l'interpéteur au début de son script : #!/bin/sh ou #!/bin/bash (sha bang et le PATH )
par exemple je crée le fichier script.nom dans mes Documents :
Je donne les droits d'exécution à l'utilisateur sur script.nom :
Et cette fois je peux exécuter depuis son répertoire parent script.nom en faisant :
Je me rends bien compte que cela double ce wiki ci : https://debian-facile.org/doc:systeme:script mais il est très succin.
Enfin la deuxième partie "Récupération des arguments" est très raide aussi pour un débutant ; on pourrait montrer comment mettre le chemin de son script dans le PATH pour pouvoir l'exécuter avec son simple nom ("monscript s'il est dans le PATH"), comme on le fait pour les commandes. Expliquer peut-être au début de ce paragraphe, qu'une commande est un programme qui s'exécute en tapant son nom parce que le chemin de leur programme est dans la variable PATH en le montrant ( echo $PATH avec le retour : /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games).
Je ne sais pas s'il y a une raison particulière à choisir sh plutôt que bash et si cela t'irait de mettre une petite phrase d'intro au tout début sur le fait que ce sont deux langages de shell (ou deux environnements de console).
Enfin, je n'ai pas compris encore tout à fait ton exemple mais j'y travaille.
Voilà j'espère que ça ne t'embête pas que je te renvoie des choses de points de vue de débutant, mais je m'y suis sentie invitée par ton dernier message. Ses wiki m'ont donné envie d'apprendre le shell
Bien amicalement
Dernière modification par Hypathie (11-03-2014 11:17:57)
Hors ligne
j'ai essayé de suivre ton wiki et j'ai dû aller chercher ailleurs des étapes ou définitions. Des trucs vraiment de très très nuls du genre les commandes d'exécution du script. Je te demande la permission d'ajouter deux exemples dans ton wiki qui visent à faire comprendre qu'un script, c'est juste un regroupement de commandes et de syntaxe connu par le shell.
1) (mettre avant ta première partie) lancer un script qui ne débute pas avec les lignes
#!/bin/bash
[…]
Ben…
Le seul intérêt que je vois (mais je suis ouvert aux propositions), d'exécuter en script shell avec
, c'est de ne pas avoir à rendre le fichier exécutable, ou de forcer l'interpréteur quand un autre a été défini.
Du coup, ça ne me semble pas être une «bonne pratique», et en particulier pour un débutant.
Du coup, je vois plus ça dans une note en fin de 1) que dans un 0) avant la bonne manière de faire.
Mais tu as du chercher ailleurs, c'est que tout n'était pas clair. Et il faut éclaircir cela
Je n'ai pas trop compris ce qui n'est pas clair, mais peut-être qu'avec ce que je viens de dire ici tu vas pouvoir me le préciser.
Je me rends bien compte que cela double ce wiki ci : https://debian-facile.org/doc:systeme:script mais il est très succin.
Attention, tu confonds, ce lien fait référence à la commande script (voir man script) que tu as utilisée par erreur dans ton sujet précédent.
Enfin la deuxième partie "Récupération des arguments" est très raide aussi pour un débutant ; on pourrait montrer comment mettre le chemin de son script dans le PATH pour pouvoir l'exécuter avec son simple nom ("monscript s'il est dans le PATH"), comme on le fait pour les commandes. Expliquer peut-être au début de ce paragraphe, qu'une commande est un programme qui s'exécute en tapant son nom parce que le chemin de leur programme est dans la variable PATH en le montrant ( echo $PATH avec le retour : /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games).
Euh, je préfère ne pas mélanger les problématiques, et surtout éviter la redondance
Par contre, c'est sûr que cette partie mériterait quelques explications (supplémentaires). Pour l'instant il n'y a qu'un exemple, et c'est loin d'être le plus simple que l'on puisse trouver, mais il a l'avantage d'être relativement complet (si tu le comprends, t'as tout compris). Libre à toi de l'enrichir, en gardant en tête d'éviter absolument la redondance sur le forum, et de ne pas mélanger les difficultés
L'histoire du PATH est dans le tuto PATH. Tu peux mettre une note <note info>Pour pouvoir exécuter votre script depuis n'importe où, n’oubliez-pas de mettre le dossier le contenant dans le PATH</note> avec un lien vers le tuto path.
Je ne sais pas s'il y a une raison particulière à choisir sh plutôt que bash et si cela t'irait de mettre une petite phrase d'intro au tout début sur le fait que ce sont deux langages de shell (ou deux environnements de console).
sh, est un lien symbolique vers le shell par défaut du système.
Un script conforme au standard POSIX n'utilisant pas de commandes ou syntaxe particulières à bash, zsh ou autre peut utiliser sh comme interpréteur. Cela signfie un peu «Ce script est tellement bien écrit qu'il fonctionnera avec n'importe quel interpréteur, donc lance-le avec ton interpréteur favoris.»
Dans le cas contraire, il faut impérativement préciser l'interpréteur de shell à utiliser. «Ce script utilise des fonctionnalités avancés que les gueux posixiens ne peuvent pas comprendre, il doit impérativement être lancé avec bash/zsh/whatever».
Donc bon, il n'y a pas vraiment de «bonne pratique», juste une mauvaise : mettre sh pour un script non-posix.
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
=> a b c d e f g h i j k l m n o p q r s t u v w x y z
tandis que :
=> {a..z}
Et l'avantage d'utiliser sh n'est pas expliquer dans un wiki.
Je ne savais pas que :
sh, est un lien symbolique vers le shell par défaut du système
ni qu'utiliser sh permettait d'être conforme au standard POSIX (je ne connaissait pas ce terme !) )
Donc je te suis maintenant sur le fait de ne pas ajouter sur ce que je proposais.
Merci encore pour tout cela je vais essayer d'accéder à la compréhension de l'exemple.
Hors ligne
Un site qui s'amuse à les décortiquer : http://rgeissert.blogspot.fr/search/label/bashisms
Un script qui permet de les détecter : checkbashisms du paquet devscripts.
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Suite à une recherche perso sur l'espeluette et son usage, j'ai modifié un tantinet ce tuto pour ce qui les concernait.
Si tu 'ech'ches l'espe'luette, tu vas pas la t'ouvé, là ! Ah ouais, mon ga !
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Hors ligne
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Hors ligne