[Résolu]Input de commandes comme "ls"

ehmicky · Le 12/07/2010, à 16:31

Salut à tous,
Je me posais la question suivante :
La plupart des commandes Unix se présentent sous la forme COMMANDE [ARGUMENT], où ARGUMENT redirige en fait l'input de COMMANDE vers ARGUMENT. Ainsi, si ARGUMENT est omis, il est "remplacé" par le standard input. C'est ce mécanisme qui permet (je pense ?) de pouvoir piper COMMANDE.
Cependant, il y a quelques commandes, dont fait partie ls, qui fonctionnent différemment : il est impossible de les piper, et le fait d'omettre leur argument (quand c'est possible) remplace ARGUMENT par quelque chose d'autre que standard input (par exemple pour ls, le répertoire courant)

Ainsi, je viens encore de lire de la documentation qui précise qu'ajouter un argument à une commande revient à rediriger son input, mais du coup je me pose la question : comment fonctionne donc les commandes comme ls du point de vue de leur input et de la redirection de leur input ?

Merci beaucoup pour votre aide ! ^^

Dernière modification par ehmicky (Le 15/07/2010, à 15:54)

helly · Le 12/07/2010, à 16:41

Impossible de piper ls ?

 ls | grep a

Ça tourne très bien…

yohann · Le 12/07/2010, à 17:08

non je pense qu'il veut dire dans l'autre sens, c'est l'input de ls qui n'est pas pipable d'après sa description:

echo /home/helly | ls

ehmicky · Le 12/07/2010, à 17:10

Oui désolé, je voulais dire "piper l'input" de ls

Edit : J'adore ton lien vers le site de jvachez ! "Bienvenue à toi, visiteur qui vient du moyen-âge et ne possède pas IE 8 : voici un lien où le télécharger". Liens morts, tables, etc. ce site est une merveille

Dernière modification par ehmicky (Le 12/07/2010, à 17:15)

helly · Le 12/07/2010, à 17:11

Ha dans ce sens là je dis pas…
Mais ça a pas vraiment de sens comme ça, et au pire on peut faire

ls $(une commande)

ehmicky · Le 12/07/2010, à 17:19

Merci pour vos réponse
A vrai dire ça aurait pu avoir un sens du style : l'input de ls est ARGUMENT, c'est-à-dire que :

echo "/home" | ls

serait équivalent à :

ls /home

Mais la question que je me pose vraiment, c'est pourquoi la plupart de la documentation dit que COMMANDE ARGUMENT signifie que l'input de COMMANDE est redirigé vers ARGUMENT, ce qui revient à dire que :

COMMANDE ARGUMENT

équivaut à :

COMMANDE < ARGUMENT

ce qui marche pour la plupart des commandes, mais pas toutes, notamment ls. Ainsi, qu'en est-il de l'input de ces commandes ?

Dernière modification par ehmicky (Le 12/07/2010, à 17:20)

ehmicky · Le 12/07/2010, à 17:25

Je crois que j'aurais un début de réponse à vrai dire qui serait que COMMANDE ARGUMENT redirige l'input d'ARGUMENT vers COMMANDE seulement si ARGUMENT est un fichier. S'il s'agit d'un chaîne de caractère, ou qu'aucun argument n'est spécifiable, la commande ne reçoit tout bonnement pas d'input.
Est-ce bien ça ?

yohann · Le 12/07/2010, à 17:49

J'ai fait une petite recheche google rapide, et il s'avère que ls ne semble pas pipable, et d'après les conversation sur les forum, se trouver à vouloir piper ls dénote un probleme de conception (en meme temps peut etre que c'est la frustration du fait que cela ne fonctionne pas) mais dans la plupart des cas c'est contournable par une bonne utilisation de find

ehmicky a écrit :

Oui désolé, je voulais dire "piper l'input" de ls

Edit : J'adore ton lien vers le site de jvachez ! "Bienvenue à toi, visiteur qui vient du moyen-âge et ne possède pas IE 8 : voici un lien où le télécharger". Liens morts, tables, etc. ce site est une merveille

J'espere que tu en a profité pour prendre un petite leçon sur les tableau dynamique en C et les manipulation web avancées avec frontpage dont "seules les fonctions les plus compliqué seront décrites ici.."

ehmicky · Le 12/07/2010, à 18:01

J'espere que tu en a profité pour prendre un petite leçon sur les tableau dynamique en C et les manipulation web avancées avec frontpage dont "seules les fonctions les plus compliqué seront décrites ici.."

Sinon pour ls, justement mon problème n'est pas pour la commande ls en particulier ni pour réussir à "piper son input", il y a bien des façons de mimer cela. Mon problème était justement conceptuel, c'est pour ça que j'utilise les termes généraux COMMANDE et ARGUMENT.

yohann · Le 12/07/2010, à 18:05

alors si c'est d'ordre général voilà coment cela ce passe:

certaine commande lancé sans argument lise sur l'entrée standard, d'autre on un comportement par défaut.

on peut illuster cela avec ls et cat:

ls seul va avoir le comportement de ls .

cat seul va revoyer une ligne et ecrire ce que tu entres au clavier

ehmicky · Le 12/07/2010, à 18:15

ehmicky a écrit :

Je crois que j'aurais un début de réponse à vrai dire qui serait que COMMANDE ARGUMENT redirige l'input d'ARGUMENT vers COMMANDE seulement si ARGUMENT est un fichier. S'il s'agit d'un chaîne de caractère, ou qu'aucun argument n'est spécifiable, la commande ne reçoit tout bonnement pas d'input.
Est-ce bien ça ?

C'est ce que je voulais dire ici (en rajoutant que sans argument, ces dernières commandes peuvent avoir un argument par défaut)
Je vais de ce pas essayer de trouver les sites dont tu parles pour voir les commentaires parlant des "erreurs de conception"

PS : Le livre d'or de J.vachez est une merveille : "quelle(s) demonstration(s) ! je vais de ce pas formater mon disque, enlever donc mon linux et installer windows xp... ou même une beta de vista. merci de m'avoir ouvert les yeux."
PPS : "input ls" sur Google : ce post en premier lien... Ils sont trop rapides chez Google ^^
PPPS : pour une commande n'acceptant comme argument que des chaines de caractères (ls, yes, etc.), il est possible de virtuellement "rediriger l'input" avec xargs.

Dernière modification par ehmicky (Le 12/07/2010, à 18:22)

ehmicky · Le 12/07/2010, à 18:44

Ca m'a l'air décidément peu documenté ou bien je cherche sur les mauvais sites !
Ma version pour l'instant est :
- certaines commandes Unix prennent comme arguments des chemins de fichiers. L'input de ces commandes est redirigé vers leurs arguments. Lorsqu'aucun argument n'est spécifié, l'input standard est substituée. Il est possible de piper l'input de ces commandes.
- certaines commandes Unix prennent comme argument des chaines de caractère ou des nombres. Ces commandes n'ont pas d'input. Lorsqu'aucun argument n'est spécifié, une erreur se produit ou un argument par défaut est substitué. Il est impossible de piper l'input de ces commandes (car elles n'en ont pas), mais il est possible de mimer cela en plaçant xargs devant la commande.
- certaines commandes Unix ne prennent pas d'arguments. Elles n'ont pas d'input, et cela n'a aucun sens de vouloir rediriger leur input.

Est-ce que selon vous j'y suis maintenant ?

PS : par "chaines de caractères ou des nombres", les variables Bash n'étant pas typées, j'entends toute chaine de caractère possible, par opposition à "chemins de fichiers" signifiant une chaine de caractère contenant un chemin de fichier valide.

yohann · Le 12/07/2010, à 19:19

merde je pensais que tu avais compris:

les commande pipables sont celle qui lisent sur l'entrée standard

ça ne va pas chercher plus loin que cela, donc ne te complique pas la vie plus qu'il ne faut.

man cat a écrit :

...
Concatenate FILE(s), or standard input, to standard output.
...

on peut piper vers cat

man grep a écrit :

...
grep searches the named input FILEs (or standard input if no files are named,
...

On peut piper vers grep

man ls a écrit :

List information about the FILEs (the current directory by default).

ls ne lit pas l'entrée standard = pas de pipe vers ls

peut importe tout le reste.

pipe = redirection de la sortie standard d'un commande vers l'entrée standard d'une autre commande.

tout est traiter comme une chaine de caractère à ce niveau.

pour des meilleur renseignement recherche avec les mots clés:
pipe, entrée standard, sortie standard, redirection

Dernière modification par yohann (Le 12/07/2010, à 19:20)

ehmicky · Le 12/07/2010, à 21:09

yohann a écrit :

les commande pipables sont celle qui lisent sur l'entrée standard

Oui, c'est ce que j'entendais par :

certaines commandes Unix prennent comme arguments des chemins de fichiers. L'input de ces commandes est redirigé vers leurs arguments. Lorsqu'aucun argument n'est spécifié, l'input standard est substituée par défaut. Il est possible de piper l'input de ces commandes.

Je voulais donc dire que les commande qui prennent "l'input standard par défaut" sont donc celles où "il est possible de piper l'input", contrairement au type 2 et 3 dans la liste.

ça ne va pas chercher plus loin que cela, donc ne te complique pas la vie plus qu'il ne faut.

En fait, le truc c'est que je me fais une documenation personnelle des commandes Unix (plus de 100 déjà !), avec certaines (comme find !!) qui font vraiment des tas des lignes, et donc du coup, ayant vu que certaines commandes pouvaient être pipées et d'autres non, je voulais avoir un moyen de savoir directement si c'était le cas ou non pour chaque commande.
Donc, je pouvais indiquer pour chaque commande : prend l'entrée standard par défaut (et donc peut être pipée), mais le problème, c'est que je voulais comprendre pourquoi certaines commandes prenait l'entrée standard et d'autres non. Or, si finalement c'est vrai, savoir que les commandes qui prennent un chemin de fichier comme argument prennent toujours l'entrée standard par défaut, ça me permet de savoir si la commande peut être pipée sans même consulter ma doc' !

Mais sinon, dans la question, il y avait aussi le fait que je comprenais pas à 100% la redirection des inputs de certaines commandes et grâce à vos lanternes (à moins que quelqu'un contredise ce qui a été dit jusqu'ici), j'y comprends bien plus ! Donc merci beaucoup pour votre aide !

ehmicky · Le 12/07/2010, à 23:02

Ok, donc je pensais être ok sur la question, quand je me suis rendu compte après quelques tests que non !

Donc en fait, il y a des commandes, comme touch, qui prennent un fichier comme argument, mais qui ne lisent pas stdin par défaut, et qui ne peuvent pas être pipé : du coup mon "listing" était faux.
Du coup, c'est comme tu dis Yohann, il y a juste des commandes qui lisent stdin par défaut, et qui peuvent être pipées, et d'autres non. Faut juste connaître tout par coeur, pas moyen de savoir a priori dans quelle catégorie les ranger...

Pendant que j'y suis, deux nouvelles questions ont émergé concernant la question de l'input :
- A mon sens, xargs envoie son propre input comme argument(s) de la commande qui le suit, ce qui permet de "piper" des commandes ne le pouvant normalement pas. Mais pourquoi donc xargs fonctionne-t-il avec certaines commandes et non d'autres au mécanisme totalement similaire ? S'agit-il encore de savoir par coeur lesquelles fonctionnent et lesquelles ne fonctionnent pas ? Exemple :

$ which echo
/bin/echo
$ echo "echo" | xargs which
/bin/echo
$ type echo
echo is a shell builtin
$ echo "echo" | xargs type
xargs: type: No such file or directory

- pourquoi certaines commandes (pas toutes !) prenant comme argument par défaut l'entrée standard ne traite pas stdin comme un argument spécifié "normalement". Exemple avec wc :

$ wc /etc/passwd
  34   56 1672 /etc/passwd
$ wc < /etc/passwd
  34   56 1672

Je sais que je suis , mais je veux vraiment essayer de comprendre le fonctionnement à fond

Dernière modification par ehmicky (Le 12/07/2010, à 23:07)

credenhill · Le 13/07/2010, à 09:03

hello
type est une commande interne du shell, xargs ne la trouve donc pas.
echo est aussi une commande interne du shell mais également un exécutable.

$ type type
type is a shell builtin
$ which type
$ type echo
echo is a shell builtin
$ which echo
/bin/echo

la redirection est gérée par le shell, pas par la commande
wc < /etc/passwd est équivalent à cat /etc/passwd| wc, aucun argument n'est passé à wc, seul le flux stdin est géré par le shell,alors qu'avec wc /etc/passwd, c'est la commande wc qui ouvre le fichier

Dernière modification par credenhill (Le 13/07/2010, à 09:16)

yohann · Le 13/07/2010, à 09:25

salut, c'est très louable de ta part de vouloir progresser et je suis ravi de pouvoir modestement t'aider à comprendre.
déjà il n'y a rien a savoir part coeur, ensuite refaire les page de man à sa sauce est un bon moyen pour apprendre les commandes a fonds, (je n'ai jamais eu le courage de le faire sur plusieurs centaine de commandes, bravo).

seulement savoir lire les man qui existent déjà (et qui son tous batit sur le meme modèle), c'est pas la chose la plus facile, (je me rappel quand j'ai commencé ces mans c'était vraiment du chinois pour moi, maintenant j'arrive a les décrypter, (mais je les lis pas encore courament malheureusement)).

toujours est-il que les première lignes du man de n'importe quelle commande sont d'abord un synopsis de la commande suivi d'une breve description, qui indique toujours si la commande peux ou pas lire sur l'entrée standard, et donc être utilisé depuis un pipe.

bonne continuation dans ton apprentissage en tout cas

ehmicky · Le 13/07/2010, à 15:30

hello
type est une commande interne du shell, xargs ne la trouve donc pas.
echo est aussi une commande interne du shell mais également un exécutable.

Cela signifie que xargs ne marche pas associé à un builtin, mais seulement à une commande externe ?
Cependant :

$ echo "message" | xargs echo
message

xargs marche ici sur un builtin (parce qu'il s'agit bien du builtin à partir du moment où je n'ai pas spécifié /bin/echo ?)

wc < /etc/passwd est équivalent à cat /etc/passwd| wc, aucun argument n'est passé à wc, seul le flux stdin est géré par le shell,alors qu'avec wc /etc/passwd, c'est la commande wc qui ouvre le fichier

Ok, mais pour autant, certaines commandes réagissent de la même manière qu'elles soient sous la forme COMMANDE ARGUMENT ou COMMANDE < ARGUMENT (par exemple cat). S'agit-il encore de connaître par coeur lesquelles réagissent pareil, et lesquelles ne réagissent pas pareil ?

Dernière modification par ehmicky (Le 13/07/2010, à 15:30)

yohann · Le 13/07/2010, à 17:10

S'agit-il encore de connaître par coeur lesquelles réagissent pareil, et lesquelles ne réagissent pas pareil ?

non

toujours est-il que les première lignes du man de n'importe quelle commande sont d'abord un synopsis de la commande suivi d'une breve description, qui indique toujours si la commande peux ou pas lire sur l'entrée standard, et donc être utilisé depuis un pipe.

et oui il faut lire souvent le man

johndo · Le 13/07/2010, à 22:39

ehmicky a écrit :

xargs marche ici sur un builtin (parce qu'il s'agit bien du builtin à partir du moment où je n'ai pas spécifié /bin/echo ?)

Non. xargs utilise bien la commande /bin/echo et en aucun cas la builtin car il la trouve dans les chemins précisés par la variable d'environnement PATH (valeur exportée). la version "builtin", il ne peut pas la connaitre puisqu'elle est propre au shell et ne constitue pas un binaire en tant que tel.

je découvre ce fil et je trouve que tu te tortures l'esprit pour pas grand chose à cause d'un malentendu sur la notion d'argument.
Un argument est ni plus ni moins une option ou une valeur passé en paramètre d'une commande (tout comme les arguments d'une procédure et ou d'une fonction). Les mécanismes de redirection ne sont en aucun cas des arguments car ce sont des outils de manipulation des flux d'entrée/sortie fournis et réalisés par le shell.

Après, qu'une commande utilise le nom d'un fichier en argument ou utilise le flux d'entrée comme source de données, c'est son mécanisme. En aucun il ne s'agit d'une convention pour toutes les commandes.
Comme d'autres l'ont écris, la seule façon de connaitre le fonctionnement d'une commande est la consultation de sa documentation : man commande ou info commande (ou il y a parfois des informations complémentaires (ex. info date))

Il existe également une syntaxe où je te laisse découvrir le résultat :

wc <(cat /etc/password)

j'espère qu'elle ne t'embrouillera pas plus l'esprit

Dernière modification par johndo (Le 14/07/2010, à 09:25)

credenhill · Le 14/07/2010, à 11:42

je dirais plutôt

wc <(cat /etc/passwd)

johndo · Le 14/07/2010, à 13:20

oui effectivement

ehmicky · Le 15/07/2010, à 00:04

Ok donc j'y vois plus clair maintenant, grâce à vous ^^
Donc, ce qui m'a embrouillé depuis le début, c'est en fait la citation de ce site :

An argument is [used by a command] as an input, and it redirects standard input from being the keyboard to being that file or data.

J'ignore si j'ai mal compris la citation ou si c'est une erreur de leur part, mais du coup j'ai commencé à me dire qu'ajouter un argument à une commande revenant à rediriger son input vers cet argument. Du coup, pour résumé, ça m'a embrouillé sur le reste !

Maintenant, tout est clair !!

Néanmoins ultime question, car j'ai toujours quelque chose qui me chiffonne... Toujours d'après la documentation, j'ai le sentiment que tout fichier ouvert a un file descriptor, quelque part, qui pointe vers lui. Cependant, si c'est le cas, faire par exemple :

$ ls /home

devrait créer un file descriptor pointant vers /home, temporairement, le temps de l'exécution de ls. Et du coup, je me dis, ce file descriptor est bien utilisé par ls, non ? Donc ne s'agit-il pas en quelque sorte d'une redirection de /home, mais bien plus complexe qu'un simple :

< FICHIER

Du coup, si on venait à mater les file descriptors du subshell créé par ls (puisque ls, en tant que commande externe, forke), n'y verrait-on pas un file descriptor pointant vers /home ??

Merci de me taper bien fort sur le crâne (ou au choix de me donner une petite tape amicale), si je suis encore à vingt mille lieues de la vérité sur le sujet !

Dernière modification par ehmicky (Le 15/07/2010, à 00:04)

ehmicky · Le 15/07/2010, à 00:30

Pour tester cela, j'ai fait :

$ split -a 4 -b 1000000 /a/grosfichier &
[1] 20119

Gros fichier est un fichier de 4Gio rempli de x00. Pendant que split s'exécutait, je suis allé dans son répertoire dans /proc, et voici ce que j'ai trouvé :

$ ls -l /proc/20119/exe
lrwxrwxrwx 1 root root 0 2010-07-15 00:19 exe -> /usr/bin/split
$ ls -l/proc/20119/fd/
total 0
lr-x------ 1 root root 64 2010-07-15 00:19 0 -> /a/grosfichier
lrwx------ 1 root root 64 2010-07-15 00:19 1 -> /dev/pts/3
lrwx------ 1 root root 64 2010-07-15 00:19 2 -> /dev/pts/3
l-wx------ 1 root root 64 2010-07-15 00:19 3 -> /a/xacmn

Ainsi quand on fait split FICHIER, l'input de split a bien l'air d'être redirigé depuis FICHIER ?? Donc dans le cas de cette commande, lui donner un argument revient à rediriger son input ?
Mais bon là j'ignore complètement si je fais fausse route, en tout cas désolé de vous importuner ! C'est juste que je trouve ça intéressant ^^

Dernière modification par ehmicky (Le 15/07/2010, à 00:44)

johndo · Le 15/07/2010, à 15:35

ehmicky a écrit :

Ok donc j'y vois plus clair maintenant, grâce à vous ^^
Donc, ce qui m'a embrouillé depuis le début, c'est en fait la citation de ce site :
An argument is [used by a command] as an input, and it redirects standard input from being the keyboard to being that file or data.

La citation signifie qu'un argument peut être le nom d'un fichier ou tout autre donnée à la place de l'entrée standard. Auquel cas, la commande associe l'entrée "clavier" par le fichier ou ces données.

AMHA, l'utilisation de "its redirects standard input" porte à confusion (c'est pour cela que j'ai utilisé le terme "associe"). Il n'est pas systématique qu'il y ait "redirection". Pour exemple : comment fait une commande qui a plusieurs fichiers en même temps comme source de données ??? On peut poser la question autrement : Plusieurs fichiers peuvent ils être associés au fd 0 en même temps ?

Néanmoins ultime question, car j'ai toujours quelque chose qui me chiffonne... Toujours d'après la documentation, j'ai le sentiment que tout fichier ouvert a un file descriptor, quelque part, qui pointe vers lui.

oui

Donc ne s'agit-il pas en quelque sorte d'une redirection de /home

Non, c'est un descripteur de fichier, ou encore un pointeur/lien vers le fichier.

Du coup, si on venait à mater les file descriptors du subshell créé par ls (puisque ls, en tant que commande externe, forke), n'y verrait-on pas un file descriptor pointant vers /home ??

normalement oui car un dossier est un fichier particulier. lorsque "ls" liste le contenu du dossier, il l'ouvre, un fd devrait donc lui être associé.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 12/07/2010, à 16:31

[Résolu]Input de commandes comme "ls"

#2 Le 12/07/2010, à 16:41

Re : [Résolu]Input de commandes comme "ls"

#3 Le 12/07/2010, à 17:08

Re : [Résolu]Input de commandes comme "ls"

#4 Le 12/07/2010, à 17:10

Re : [Résolu]Input de commandes comme "ls"

#5 Le 12/07/2010, à 17:11

Re : [Résolu]Input de commandes comme "ls"

#6 Le 12/07/2010, à 17:19

Re : [Résolu]Input de commandes comme "ls"

#7 Le 12/07/2010, à 17:25

Re : [Résolu]Input de commandes comme "ls"

#8 Le 12/07/2010, à 17:49

Re : [Résolu]Input de commandes comme "ls"

#9 Le 12/07/2010, à 18:01

Re : [Résolu]Input de commandes comme "ls"

#10 Le 12/07/2010, à 18:05

Re : [Résolu]Input de commandes comme "ls"

#11 Le 12/07/2010, à 18:15

Re : [Résolu]Input de commandes comme "ls"

#12 Le 12/07/2010, à 18:44

Re : [Résolu]Input de commandes comme "ls"

#13 Le 12/07/2010, à 19:19

Re : [Résolu]Input de commandes comme "ls"

#14 Le 12/07/2010, à 21:09

Re : [Résolu]Input de commandes comme "ls"

#15 Le 12/07/2010, à 23:02

Re : [Résolu]Input de commandes comme "ls"

#16 Le 13/07/2010, à 09:03

Re : [Résolu]Input de commandes comme "ls"

#17 Le 13/07/2010, à 09:25

Re : [Résolu]Input de commandes comme "ls"

#18 Le 13/07/2010, à 15:30

Re : [Résolu]Input de commandes comme "ls"

#19 Le 13/07/2010, à 17:10

Re : [Résolu]Input de commandes comme "ls"

#20 Le 13/07/2010, à 22:39

Re : [Résolu]Input de commandes comme "ls"

#21 Le 14/07/2010, à 11:42

Re : [Résolu]Input de commandes comme "ls"

#22 Le 14/07/2010, à 13:20

Re : [Résolu]Input de commandes comme "ls"

#23 Le 15/07/2010, à 00:04

Re : [Résolu]Input de commandes comme "ls"

#24 Le 15/07/2010, à 00:30

Re : [Résolu]Input de commandes comme "ls"

#25 Le 15/07/2010, à 15:35

Re : [Résolu]Input de commandes comme "ls"

Pied de page des forums