Je suis en ksh même si je pense que ça n'a pas d'importance ici
1/ Pourquoi ceci ne marche pas :
echo nomfichier | xargs vi
(je m'attendais ici à ce que vi ouvre le fichier nomfichier)
Ceci ne marche pas non plus :
echo nomfichier | vi
2/ J'ai remarqué que
vi `echo nomfichier`
marche
Y a-t-il 2 lignes équivalentes parmi les 3 suivantes parce que je m'y perd
un peu à vrai dire ? sinon quelles différences ?
commande1 `commande2`
commande2 | commande1
commande2 | xargs commande1
3/ Quelle est la taille limite d'un argument que je peux passer en paramètre
à un programme ?
(est-ce que je peux lancer un programme nomprog prenant une chaine de
caractères de 100000 caractères par exemple ?)
4/ Je suis tombé sur un script qui comporte l'instruction mknod
ne connaissant pas j'ai regardé les pages man, il semblerait que ça serve à
créer un répertoire servant à
stocker des fichiers spéciaux. Qu'appelle-t-on fichier spécial ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicolas George
"Fred S" wrote in message <41813928$0$6933$:
1/ Pourquoi ceci ne marche pas : echo nomfichier | xargs vi
Probablement parce que Vi s'attend à ce que son entrée standard soit un terminal. C'est en tout cas le cas pour Vim.
commande1 `commande2` commande2 | xargs commande1
Ces deux-ci sont vaguement équivalentes.
commande2 | commande1
Celle-ci n'a rien à voir du tout en revanche.
3/ Quelle est la taille limite d'un argument que je peux passer en paramètre à un programme ?
`getconf ARG_MAX`
4/ Je suis tombé sur un script qui comporte l'instruction mknod ne connaissant pas j'ai regardé les pages man, il semblerait que ça serve à créer un répertoire servant à stocker des fichiers spéciaux.
Non, elle sert à créer les fichiers spéciaux eux-mêmes.
Qu'appelle-t-on fichier spécial ?
Soit des tubes només (tels que si un programme l'ouvre en lecture, un autre en écriture, ils se retrouvent en fait connectés), soit des devices, c'est à dire des pseudo-fichiers gérés par le noyau pour fournir une interface à des périphériques ou certaines fonctions. Essayer par exemple, après avoir mis le son au maximum, quelque chose comme :
cat un_gros_fichier > /dev/dsp
ou
cat un_gros_fichier > /dev/audio
"Fred S" wrote in message <41813928$0$6933$636a15ce@news.free.fr>:
1/ Pourquoi ceci ne marche pas :
echo nomfichier | xargs vi
Probablement parce que Vi s'attend à ce que son entrée standard soit un
terminal. C'est en tout cas le cas pour Vim.
commande1 `commande2`
commande2 | xargs commande1
Ces deux-ci sont vaguement équivalentes.
commande2 | commande1
Celle-ci n'a rien à voir du tout en revanche.
3/ Quelle est la taille limite d'un argument que je peux passer en paramètre
à un programme ?
`getconf ARG_MAX`
4/ Je suis tombé sur un script qui comporte l'instruction mknod
ne connaissant pas j'ai regardé les pages man, il semblerait que ça serve à
créer un répertoire servant à
stocker des fichiers spéciaux.
Non, elle sert à créer les fichiers spéciaux eux-mêmes.
Qu'appelle-t-on fichier spécial ?
Soit des tubes només (tels que si un programme l'ouvre en lecture, un autre
en écriture, ils se retrouvent en fait connectés), soit des devices, c'est à
dire des pseudo-fichiers gérés par le noyau pour fournir une interface à des
périphériques ou certaines fonctions. Essayer par exemple, après avoir mis
le son au maximum, quelque chose comme :
1/ Pourquoi ceci ne marche pas : echo nomfichier | xargs vi
Probablement parce que Vi s'attend à ce que son entrée standard soit un terminal. C'est en tout cas le cas pour Vim.
commande1 `commande2` commande2 | xargs commande1
Ces deux-ci sont vaguement équivalentes.
commande2 | commande1
Celle-ci n'a rien à voir du tout en revanche.
3/ Quelle est la taille limite d'un argument que je peux passer en paramètre à un programme ?
`getconf ARG_MAX`
4/ Je suis tombé sur un script qui comporte l'instruction mknod ne connaissant pas j'ai regardé les pages man, il semblerait que ça serve à créer un répertoire servant à stocker des fichiers spéciaux.
Non, elle sert à créer les fichiers spéciaux eux-mêmes.
Qu'appelle-t-on fichier spécial ?
Soit des tubes només (tels que si un programme l'ouvre en lecture, un autre en écriture, ils se retrouvent en fait connectés), soit des devices, c'est à dire des pseudo-fichiers gérés par le noyau pour fournir une interface à des périphériques ou certaines fonctions. Essayer par exemple, après avoir mis le son au maximum, quelque chose comme :
cat un_gros_fichier > /dev/dsp
ou
cat un_gros_fichier > /dev/audio
Pascal Bourguignon
"Fred S" writes:
Je suis en ksh même si je pense que ça n'a pas d'importance ici
1/ Pourquoi ceci ne marche pas : echo nomfichier | xargs vi
Oui, xargs est étrange... Voyons voir: man xargs
Mais chez moi (GNU/Linux): echo nomfichier | xargs vi fonctionne parfaitement bien.
(je m'attendais ici à ce que vi ouvre le fichier nomfichier) Ceci ne marche pas non plus : echo nomfichier | vi
2/ J'ai remarqué que vi `echo nomfichier` marche
Y a-t-il 2 lignes équivalentes parmi les 3 suivantes parce que je m'y perd un peu à vrai dire ? sinon quelles différences ? commande1 `commande2` commande2 | commande1 commande2 | xargs commande1
Ces deux là donnent dans certains cas le même résultat:
fd=0 == données venant de command2 via un tube (stdin).
3/ Quelle est la taille limite d'un argument que je peux passer en paramètre à un programme ?
Ça dépend du noyeau et du shell.
(est-ce que je peux lancer un programme nomprog prenant une chaine de caractères de 100000 caractères par exemple ?)
En la prenant comment? Par devant ou par derrière?
En général, en argument: non.
4/ Je suis tombé sur un script qui comporte l'instruction mknod ne connaissant pas j'ai regardé les pages man, il semblerait que ça serve à créer un répertoire servant à stocker des fichiers spéciaux. Qu'appelle-t-on fichier spécial ?
Sur unix, la hierarchie de nommage ne sert pas uniquement à nommer les fichiers. Elle sert aussi à nommer les répertoires, les liens symboliques, les volumes (/mnt ou ailleurs), les pilotes (/dev ou ailleurs), les tubes nommés (/tmp ou ailleurs), les prises (/tmp ou ailleurs) et beaucoup d'autres choses (/proc,...).
Ça simplifie beaucoup de choses: tous les objets manipulables dans le système sont accessibles (ou non, selon les droits d'accès) dans la hierarchie de nommage. Enfin presque tous, il y en a qui ne comprennent rien et qui créent dans le système des objets non accessibles...
Comme la page de manuel de mknod l'indique, ce qu'elle appelle les fichiers spéciaux sont les pilotes en mode bloc, les pilotes en mode caractères, et les tubes nommés.
En général, la liste des pilotes est figée, compilés dans le noyaux, ou au mieux chargés dynamiquement par root, alors les utilisateurs n'ont pas besoin de créer un fichier special pour accéder aux pilotes car ils sont tous accéssibles via les fichiers speciaux dans /dev.
Mais root peut parfois ajouter des fichiers spéciaux pour accéder aux pilotes afin de gérer finement les droits d'accès. Par exemple, s'il y a un pilote pour un appareil Machine à Café /dev/mac0 qui a comme droits d'accès:
un utilisateur Toto ne peut pas l'utiliser. Normal, l'administrateur système root se réserve les droits d'utiliser la machine à café. Mais maintenant si root veut permettre à un utilisateur Delphine d'utiliser la machine à café, il peut créer un autre fichier spécial:
et qui permet à delphine d'utiliser le pilote en passant par ce fichier spécial.
Mais le plus souvent, un utilisateur va utiliser mknod pour créer un tube nommé. L'intérêt de la manipulation est quand on a un programme mal foutu qui veut absolument lire ou écrire ses données dans un fichier, si on lui donne un tube nommé à la place du fichier, on peut le brancher sur un autre processus. Encore faut il pour que ça marche que ce programme n'utilise que des accès séquentiels.
Voting Democrat or Republican is like choosing a cabin in the Titanic.
"Fred S" <r5tr@free.fr> writes:
Je suis en ksh même si je pense que ça n'a pas d'importance ici
1/ Pourquoi ceci ne marche pas :
echo nomfichier | xargs vi
Oui, xargs est étrange... Voyons voir: man xargs
Mais chez moi (GNU/Linux): echo nomfichier | xargs vi
fonctionne parfaitement bien.
(je m'attendais ici à ce que vi ouvre le fichier nomfichier)
Ceci ne marche pas non plus :
echo nomfichier | vi
2/ J'ai remarqué que
vi `echo nomfichier`
marche
Y a-t-il 2 lignes équivalentes parmi les 3 suivantes parce que je m'y perd
un peu à vrai dire ? sinon quelles différences ?
commande1 `commande2`
commande2 | commande1
commande2 | xargs commande1
Ces deux là donnent dans certains cas le même résultat:
fd=0 == données venant de command2 via un tube (stdin).
3/ Quelle est la taille limite d'un argument que je peux passer en paramètre
à un programme ?
Ça dépend du noyeau et du shell.
(est-ce que je peux lancer un programme nomprog prenant une chaine de
caractères de 100000 caractères par exemple ?)
En la prenant comment? Par devant ou par derrière?
En général, en argument: non.
4/ Je suis tombé sur un script qui comporte l'instruction mknod
ne connaissant pas j'ai regardé les pages man, il semblerait que ça serve à
créer un répertoire servant à
stocker des fichiers spéciaux. Qu'appelle-t-on fichier spécial ?
Sur unix, la hierarchie de nommage ne sert pas uniquement à nommer les
fichiers. Elle sert aussi à nommer les répertoires, les liens
symboliques, les volumes (/mnt ou ailleurs), les pilotes (/dev ou
ailleurs), les tubes nommés (/tmp ou ailleurs), les prises (/tmp ou
ailleurs) et beaucoup d'autres choses (/proc,...).
Ça simplifie beaucoup de choses: tous les objets manipulables dans le
système sont accessibles (ou non, selon les droits d'accès) dans la
hierarchie de nommage. Enfin presque tous, il y en a qui ne
comprennent rien et qui créent dans le système des objets non
accessibles...
Comme la page de manuel de mknod l'indique, ce qu'elle appelle les
fichiers spéciaux sont les pilotes en mode bloc, les pilotes en mode
caractères, et les tubes nommés.
En général, la liste des pilotes est figée, compilés dans le noyaux,
ou au mieux chargés dynamiquement par root, alors les utilisateurs
n'ont pas besoin de créer un fichier special pour accéder aux pilotes
car ils sont tous accéssibles via les fichiers speciaux dans /dev.
Mais root peut parfois ajouter des fichiers spéciaux pour accéder aux
pilotes afin de gérer finement les droits d'accès. Par exemple, s'il
y a un pilote pour un appareil Machine à Café /dev/mac0 qui a comme
droits d'accès:
un utilisateur Toto ne peut pas l'utiliser. Normal, l'administrateur
système root se réserve les droits d'utiliser la machine à café. Mais
maintenant si root veut permettre à un utilisateur Delphine d'utiliser
la machine à café, il peut créer un autre fichier spécial:
et qui permet à delphine d'utiliser le pilote en passant par ce
fichier spécial.
Mais le plus souvent, un utilisateur va utiliser mknod pour créer un
tube nommé. L'intérêt de la manipulation est quand on a un programme
mal foutu qui veut absolument lire ou écrire ses données dans un
fichier, si on lui donne un tube nommé à la place du fichier, on peut
le brancher sur un autre processus. Encore faut il pour que ça marche
que ce programme n'utilise que des accès séquentiels.
Je suis en ksh même si je pense que ça n'a pas d'importance ici
1/ Pourquoi ceci ne marche pas : echo nomfichier | xargs vi
Oui, xargs est étrange... Voyons voir: man xargs
Mais chez moi (GNU/Linux): echo nomfichier | xargs vi fonctionne parfaitement bien.
(je m'attendais ici à ce que vi ouvre le fichier nomfichier) Ceci ne marche pas non plus : echo nomfichier | vi
2/ J'ai remarqué que vi `echo nomfichier` marche
Y a-t-il 2 lignes équivalentes parmi les 3 suivantes parce que je m'y perd un peu à vrai dire ? sinon quelles différences ? commande1 `commande2` commande2 | commande1 commande2 | xargs commande1
Ces deux là donnent dans certains cas le même résultat:
fd=0 == données venant de command2 via un tube (stdin).
3/ Quelle est la taille limite d'un argument que je peux passer en paramètre à un programme ?
Ça dépend du noyeau et du shell.
(est-ce que je peux lancer un programme nomprog prenant une chaine de caractères de 100000 caractères par exemple ?)
En la prenant comment? Par devant ou par derrière?
En général, en argument: non.
4/ Je suis tombé sur un script qui comporte l'instruction mknod ne connaissant pas j'ai regardé les pages man, il semblerait que ça serve à créer un répertoire servant à stocker des fichiers spéciaux. Qu'appelle-t-on fichier spécial ?
Sur unix, la hierarchie de nommage ne sert pas uniquement à nommer les fichiers. Elle sert aussi à nommer les répertoires, les liens symboliques, les volumes (/mnt ou ailleurs), les pilotes (/dev ou ailleurs), les tubes nommés (/tmp ou ailleurs), les prises (/tmp ou ailleurs) et beaucoup d'autres choses (/proc,...).
Ça simplifie beaucoup de choses: tous les objets manipulables dans le système sont accessibles (ou non, selon les droits d'accès) dans la hierarchie de nommage. Enfin presque tous, il y en a qui ne comprennent rien et qui créent dans le système des objets non accessibles...
Comme la page de manuel de mknod l'indique, ce qu'elle appelle les fichiers spéciaux sont les pilotes en mode bloc, les pilotes en mode caractères, et les tubes nommés.
En général, la liste des pilotes est figée, compilés dans le noyaux, ou au mieux chargés dynamiquement par root, alors les utilisateurs n'ont pas besoin de créer un fichier special pour accéder aux pilotes car ils sont tous accéssibles via les fichiers speciaux dans /dev.
Mais root peut parfois ajouter des fichiers spéciaux pour accéder aux pilotes afin de gérer finement les droits d'accès. Par exemple, s'il y a un pilote pour un appareil Machine à Café /dev/mac0 qui a comme droits d'accès:
un utilisateur Toto ne peut pas l'utiliser. Normal, l'administrateur système root se réserve les droits d'utiliser la machine à café. Mais maintenant si root veut permettre à un utilisateur Delphine d'utiliser la machine à café, il peut créer un autre fichier spécial:
et qui permet à delphine d'utiliser le pilote en passant par ce fichier spécial.
Mais le plus souvent, un utilisateur va utiliser mknod pour créer un tube nommé. L'intérêt de la manipulation est quand on a un programme mal foutu qui veut absolument lire ou écrire ses données dans un fichier, si on lui donne un tube nommé à la place du fichier, on peut le brancher sur un autre processus. Encore faut il pour que ça marche que ce programme n'utilise que des accès séquentiels.
Voting Democrat or Republican is like choosing a cabin in the Titanic.
cedric
Pascal Bourguignon wrote:
Ça simplifie beaucoup de choses: tous les objets manipulables dans le système sont accessibles (ou non, selon les droits d'accès) dans la hierarchie de nommage. Enfin presque tous, il y en a qui ne comprennent rien et qui créent dans le système des objets non accessibles...
Comme les interfaces réseaux par exemple ?
Pascal Bourguignon wrote:
Ça simplifie beaucoup de choses: tous les objets manipulables dans le
système sont accessibles (ou non, selon les droits d'accès) dans la
hierarchie de nommage. Enfin presque tous, il y en a qui ne
comprennent rien et qui créent dans le système des objets non
accessibles...
Ça simplifie beaucoup de choses: tous les objets manipulables dans le système sont accessibles (ou non, selon les droits d'accès) dans la hierarchie de nommage. Enfin presque tous, il y en a qui ne comprennent rien et qui créent dans le système des objets non accessibles...
Comme les interfaces réseaux par exemple ?
Bob qui Trolle
cedric wrote:
Pascal Bourguignon wrote:
Ça simplifie beaucoup de choses: tous les objets manipulables dans le système sont accessibles (ou non, selon les droits d'accès) dans la hierarchie de nommage. Enfin presque tous, il y en a qui ne comprennent rien et qui créent dans le système des objets non accessibles...
Comme les interfaces réseaux par exemple ?
Les bus sont rarement accessibles tels quels en tant qu'objets du système, sauf s'ils sont point à point par nature (quel qu'en soit la vocation effective runtime). /proc/ide n'est généralement pas une interface, par exemple, mais /proc/ide/xxx l'est. Idem pour /proc/net/xxx. Mais rien n'empêche qui que ce soit de créer un driver pour ça, lequel peut être rendu accessible par le biais d'un pilota dédié.
La durée de vie d'un objet du noyau détermine également le coût effectif d'exporter une interface fichier à cet objet. Exporter /proc/ide/hd$N est normalement viable, si on considère qu'une partition d'un disque IDE est supposées, une fois créée, exister un certain temps : exporter par principe une interface fichier sur toute socket créée plus discutable.
cedric wrote:
Pascal Bourguignon wrote:
Ça simplifie beaucoup de choses: tous les objets manipulables dans le
système sont accessibles (ou non, selon les droits d'accès) dans la
hierarchie de nommage. Enfin presque tous, il y en a qui ne
comprennent rien et qui créent dans le système des objets non
accessibles...
Comme les interfaces réseaux par exemple ?
Les bus sont rarement accessibles tels quels en tant qu'objets du
système, sauf s'ils sont point à point par nature (quel qu'en soit la
vocation effective runtime). /proc/ide n'est généralement pas une
interface, par exemple, mais /proc/ide/xxx l'est. Idem pour
/proc/net/xxx. Mais rien n'empêche qui que ce soit de créer un driver
pour ça, lequel peut être rendu accessible par le biais d'un pilota dédié.
La durée de vie d'un objet du noyau détermine également le coût effectif
d'exporter une interface fichier à cet objet. Exporter /proc/ide/hd$N
est normalement viable, si on considère qu'une partition d'un disque IDE
est supposées, une fois créée, exister un certain temps : exporter par
principe une interface fichier sur toute socket créée plus discutable.
Ça simplifie beaucoup de choses: tous les objets manipulables dans le système sont accessibles (ou non, selon les droits d'accès) dans la hierarchie de nommage. Enfin presque tous, il y en a qui ne comprennent rien et qui créent dans le système des objets non accessibles...
Comme les interfaces réseaux par exemple ?
Les bus sont rarement accessibles tels quels en tant qu'objets du système, sauf s'ils sont point à point par nature (quel qu'en soit la vocation effective runtime). /proc/ide n'est généralement pas une interface, par exemple, mais /proc/ide/xxx l'est. Idem pour /proc/net/xxx. Mais rien n'empêche qui que ce soit de créer un driver pour ça, lequel peut être rendu accessible par le biais d'un pilota dédié.
La durée de vie d'un objet du noyau détermine également le coût effectif d'exporter une interface fichier à cet objet. Exporter /proc/ide/hd$N est normalement viable, si on considère qu'une partition d'un disque IDE est supposées, une fois créée, exister un certain temps : exporter par principe une interface fichier sur toute socket créée plus discutable.
Stephane Chazelas
2004-10-28, 22:28(+02), Pascal Bourguignon: [...]
3/ Quelle est la taille limite d'un argument que je peux passer en paramètre à un programme ?
Ça dépend du noyeau et du shell.
Ca ne depend pas du shell en principe (sauf peut-etre pour de vieilles versions de csh). Les shells alloue la place pour les arguments dynamiquement, donc la limite au niveau du shell est celle de la memoire disponible.
(est-ce que je peux lancer un programme nomprog prenant une chaine de caractères de 100000 caractères par exemple ?)
En la prenant comment? Par devant ou par derrière?
En général, en argument: non.
Sous Solaris 8, la limite est de l'ordre du mega octet. Il me semble que sous Linux, c'est de l'ordre de 130k.
Donc, au moins sur ces deux systemes, ca devrait passer (a moins que argv[0] ou l'environnement soit gros aussi).
-- Stephane
2004-10-28, 22:28(+02), Pascal Bourguignon:
[...]
3/ Quelle est la taille limite d'un argument que je peux passer en paramètre
à un programme ?
Ça dépend du noyeau et du shell.
Ca ne depend pas du shell en principe (sauf peut-etre pour de
vieilles versions de csh). Les shells alloue la place pour les
arguments dynamiquement, donc la limite au niveau du shell est
celle de la memoire disponible.
(est-ce que je peux lancer un programme nomprog prenant une chaine de
caractères de 100000 caractères par exemple ?)
En la prenant comment? Par devant ou par derrière?
En général, en argument: non.
Sous Solaris 8, la limite est de l'ordre du mega octet. Il me
semble que sous Linux, c'est de l'ordre de 130k.
Donc, au moins sur ces deux systemes, ca devrait passer (a moins
que argv[0] ou l'environnement soit gros aussi).
3/ Quelle est la taille limite d'un argument que je peux passer en paramètre à un programme ?
Ça dépend du noyeau et du shell.
Ca ne depend pas du shell en principe (sauf peut-etre pour de vieilles versions de csh). Les shells alloue la place pour les arguments dynamiquement, donc la limite au niveau du shell est celle de la memoire disponible.
(est-ce que je peux lancer un programme nomprog prenant une chaine de caractères de 100000 caractères par exemple ?)
En la prenant comment? Par devant ou par derrière?
En général, en argument: non.
Sous Solaris 8, la limite est de l'ordre du mega octet. Il me semble que sous Linux, c'est de l'ordre de 130k.
Donc, au moins sur ces deux systemes, ca devrait passer (a moins que argv[0] ou l'environnement soit gros aussi).
-- Stephane
Pascal Bourguignon
cedric writes:
Pascal Bourguignon wrote:
Ça simplifie beaucoup de choses: tous les objets manipulables dans le système sont accessibles (ou non, selon les droits d'accès) dans la hierarchie de nommage. Enfin presque tous, il y en a qui ne comprennent rien et qui créent dans le système des objets non accessibles...
Comme les interfaces réseaux par exemple ?
Heureusement bash palie à ce manque et on peut ouvrir dans bash des fichiers speciaux virtuels comme /dev/tcp/$host/$port
Voting Democrat or Republican is like choosing a cabin in the Titanic.
cedric <rixed@happyleptic.NOSPAM.org> writes:
Pascal Bourguignon wrote:
Ça simplifie beaucoup de choses: tous les objets manipulables dans le
système sont accessibles (ou non, selon les droits d'accès) dans la
hierarchie de nommage. Enfin presque tous, il y en a qui ne
comprennent rien et qui créent dans le système des objets non
accessibles...
Comme les interfaces réseaux par exemple ?
Heureusement bash palie à ce manque et on peut ouvrir dans bash des
fichiers speciaux virtuels comme /dev/tcp/$host/$port
Ça simplifie beaucoup de choses: tous les objets manipulables dans le système sont accessibles (ou non, selon les droits d'accès) dans la hierarchie de nommage. Enfin presque tous, il y en a qui ne comprennent rien et qui créent dans le système des objets non accessibles...
Comme les interfaces réseaux par exemple ?
Heureusement bash palie à ce manque et on peut ouvrir dans bash des fichiers speciaux virtuels comme /dev/tcp/$host/$port
