Je suis =E0 la recherche d'une feature un peu sp=E9ciale : sous n'importe
quel Linux, je pouvais mettre les arguments des commandes du terminal
dans n'importe quelle position et elles =E9taient prises en compte.
Ex : cp toto tata -rf
Lorsque j'essaye sous Mac, dans le terminal, je n'arrive pas =E0
reproduire cette fonction.
Il consid=E8re "-rf" comme un fichier :/
Y a-t-il un moyen ?
Je suis à la recherche d'une feature un peu spéciale : sous n'importe quel Linux, je pouvais mettre les arguments des commandes du terminal dans n'importe quelle position et elles étaient prises en compte. Ex : cp toto tata -rf Lorsque j'essaye sous Mac, dans le terminal, je n'arrive pas à reproduire cette fonction. Il considère "-rf" comme un fichier :/ Y a-t-il un moyen ?
Un moyen simple ? Non. Bienvenue dans le monde *BSD.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Je suis à la recherche d'une feature un peu spéciale : sous n'importe
quel Linux, je pouvais mettre les arguments des commandes du terminal
dans n'importe quelle position et elles étaient prises en compte.
Ex : cp toto tata -rf
Lorsque j'essaye sous Mac, dans le terminal, je n'arrive pas à
reproduire cette fonction.
Il considère "-rf" comme un fichier :/
Y a-t-il un moyen ?
Un moyen simple ? Non.
Bienvenue dans le monde *BSD.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Je suis à la recherche d'une feature un peu spéciale : sous n'importe quel Linux, je pouvais mettre les arguments des commandes du terminal dans n'importe quelle position et elles étaient prises en compte. Ex : cp toto tata -rf Lorsque j'essaye sous Mac, dans le terminal, je n'arrive pas à reproduire cette fonction. Il considère "-rf" comme un fichier :/ Y a-t-il un moyen ?
Un moyen simple ? Non. Bienvenue dans le monde *BSD.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
blanc
Tipoun wrote:
Je suis à la recherche d'une feature un peu spéciale : sous n'importe quel Linux, je pouvais mettre les arguments des commandes du terminal dans n'importe quelle position et elles étaient prises en compte. Ex : cp toto tata -rf
Les arguments de chaque appli sont gérées par l'appli elle-même. La recommendation pour Unix est de mettre les options (-rf dans ton exemple) en premier. Mis à part quelques exceptions (qui sont en général documentées dans le man des applis concernées) , c'est àmha universellement vérifié.
En ce qui concerne cp (par exemple) je n'est jamais vu d'implantation ou les options seraient n'importe où. Ce qui veut dire que c'est l'implantation de cp dans ton linux qui est une exception. Pas celle de Mac OS X. J'ajouterais même que ton exemple me surprend, car lorsqu'on connait la syntaxe de cp (voir le man) cela parait difficile (bien que pas impossible) d'analyser une ligne de commande où les options seraient n'importe où. Je veux dire par exemple que si je fais la commande : cp * toto -rf dans un répertoire qui contient 10000 fichiers, le système (car c'est lui qui le fait sous Unix) va remplacer l'étoile par la liste des 10000 fichiers. Ce qui fait que la commande cp devrait lire les 10002 arguments qu'elle reçoit avant de voir que le dernier est une option, prendre en compte cette option, puis relire les 10001 premiers arguments pour faire la copie. Cela me paraît une perte de temps (et c'est ce qui explique la recommendation : les options en premier) -- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
Tipoun <giraud.romain@gmail.com> wrote:
Je suis à la recherche d'une feature un peu spéciale : sous n'importe
quel Linux, je pouvais mettre les arguments des commandes du terminal
dans n'importe quelle position et elles étaient prises en compte.
Ex : cp toto tata -rf
Les arguments de chaque appli sont gérées par l'appli elle-même. La
recommendation pour Unix est de mettre les options (-rf dans ton
exemple) en premier. Mis à part quelques exceptions (qui sont en général
documentées dans le man des applis concernées) , c'est àmha
universellement vérifié.
En ce qui concerne cp (par exemple) je n'est jamais vu d'implantation ou
les options seraient n'importe où. Ce qui veut dire que c'est
l'implantation de cp dans ton linux qui est une exception. Pas celle de
Mac OS X.
J'ajouterais même que ton exemple me surprend, car lorsqu'on connait la
syntaxe de cp (voir le man) cela parait difficile (bien que pas
impossible) d'analyser une ligne de commande où les options seraient
n'importe où.
Je veux dire par exemple que si je fais la commande :
cp * toto -rf
dans un répertoire qui contient 10000 fichiers, le système (car c'est
lui qui le fait sous Unix) va remplacer l'étoile par la liste des 10000
fichiers. Ce qui fait que la commande cp devrait lire les 10002
arguments qu'elle reçoit avant de voir que le dernier est une option,
prendre en compte cette option, puis relire les 10001 premiers arguments
pour faire la copie. Cela me paraît une perte de temps (et c'est ce qui
explique la recommendation : les options en premier)
--
JiPaul.
/ /--/--//\ Jean-Paul Blanc
|/| L |\ quelquepart en (somewhere in)
/|| = |||\ FRANCE
Je suis à la recherche d'une feature un peu spéciale : sous n'importe quel Linux, je pouvais mettre les arguments des commandes du terminal dans n'importe quelle position et elles étaient prises en compte. Ex : cp toto tata -rf
Les arguments de chaque appli sont gérées par l'appli elle-même. La recommendation pour Unix est de mettre les options (-rf dans ton exemple) en premier. Mis à part quelques exceptions (qui sont en général documentées dans le man des applis concernées) , c'est àmha universellement vérifié.
En ce qui concerne cp (par exemple) je n'est jamais vu d'implantation ou les options seraient n'importe où. Ce qui veut dire que c'est l'implantation de cp dans ton linux qui est une exception. Pas celle de Mac OS X. J'ajouterais même que ton exemple me surprend, car lorsqu'on connait la syntaxe de cp (voir le man) cela parait difficile (bien que pas impossible) d'analyser une ligne de commande où les options seraient n'importe où. Je veux dire par exemple que si je fais la commande : cp * toto -rf dans un répertoire qui contient 10000 fichiers, le système (car c'est lui qui le fait sous Unix) va remplacer l'étoile par la liste des 10000 fichiers. Ce qui fait que la commande cp devrait lire les 10002 arguments qu'elle reçoit avant de voir que le dernier est une option, prendre en compte cette option, puis relire les 10001 premiers arguments pour faire la copie. Cela me paraît une perte de temps (et c'est ce qui explique la recommendation : les options en premier) -- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
Franck
JiPaul wrote:
dans un répertoire qui contient 10000 fichiers, le système (car c'e st lui qui le fait sous Unix) va remplacer l'étoile par la liste des 100 00 fichiers.
Soyons précis, ce n'est pas le "système" qui remplace l'étoile par la liste des fichiers, mais le shell.
JiPaul wrote:
dans un répertoire qui contient 10000 fichiers, le système (car c'e st
lui qui le fait sous Unix) va remplacer l'étoile par la liste des 100 00
fichiers.
Soyons précis, ce n'est pas le "système" qui remplace l'étoile par la
liste des fichiers, mais le shell.
dans un répertoire qui contient 10000 fichiers, le système (car c'e st lui qui le fait sous Unix) va remplacer l'étoile par la liste des 100 00 fichiers.
Soyons précis, ce n'est pas le "système" qui remplace l'étoile par la liste des fichiers, mais le shell.
blanc
Franck <franck+ wrote:
Soyons précis, ce n'est pas le "système" qui remplace l'étoile par la liste des fichiers, mais le shell.
Exact. J'ai dit "système" car pour moi le shell fait partie du système :
Système = noyau + coquille
même si le shell est interchangeable. -- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
Franck <franck+news@_remove_apoal.com> wrote:
Soyons précis, ce n'est pas le "système" qui remplace l'étoile par la
liste des fichiers, mais le shell.
Exact. J'ai dit "système" car pour moi le shell fait partie du système :
Système = noyau + coquille
même si le shell est interchangeable.
--
JiPaul.
/ /--/--//\ Jean-Paul Blanc
|/| L |\ quelquepart en (somewhere in)
/|| = |||\ FRANCE
Soyons précis, ce n'est pas le "système" qui remplace l'étoile par la liste des fichiers, mais le shell.
Exact. J'ai dit "système" car pour moi le shell fait partie du système :
Système = noyau + coquille
même si le shell est interchangeable. -- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
Tipoun
On Sep 15, 9:42 am, (JiPaul) wrote:
Franck <franck+ wrote: > Soyons précis, ce n'est pas le "système" qui remplace l'étoile pa r la > liste des fichiers, mais le shell.
Exact. J'ai dit "système" car pour moi le shell fait partie du systèm e :
Système = noyau + coquille
même si le shell est interchangeable. -- JiPaul. / /--/--// Jean-Paul Bl anc |/| L | quelquepart en (somewhe re in) /|| = ||| F RANCE
Un moyen simple ? Non. Bienvenue dans le monde *BSD.
Arf, dommage :/
En ce qui concerne cp (par exemple) je n'est jamais vu d'implantation ou les options seraient n'importe où. Ce qui veut dire que c'est l'implantation de cp dans ton linux qui est une exception. Pas celle de Mac OS X.
C'est le cas sous Debian et Archlinux (et je pense sous tous les Linux, bien que je n'ai pas vérifié).
le système (car c'est lui qui le fait sous Unix) va remplacer l'étoil e par la liste des 10000 fichiers. Ce qui fait que la commande cp devrait lire les 10002 arguments qu'elle reçoit avant de voir que le dernier est une option, prendre en compte cette option, puis relire les 10001 premiers arguments pour faire la copie. Cela me paraît une perte de temps (et c'est ce qui explique la recommendation : les options en premier)
Pour avoir déjà travailler avec des options dans un programme, ce n'est pas exactement de cette façon que cela fonctionne. La fonction utilisée pour analyser les options est getopt() (http:// www.gnu.org/s/libc/manual/html_node/Example-of-Getopt.html#Example-of-Getop t). Dans tous les cas, les arguments de la commande seront tous lu une seule fois. Dès que la fonction trouve un "-", elle considère que c'est une option et ensuite exécute différents tests pour déterminer précisément l'option. L'exécution à proprement parler de la commande (dans notre cas cp), ne sera faite qu'après cette analyse.
C'est pour cette raison que je m'étonnais de l'ordre obligatoire à respecter sous Mac OS X.
Merci pour vos réponses. Cordialement
On Sep 15, 9:42 am, bl...@empty.org (JiPaul) wrote:
Franck <franck+news@_remove_apoal.com> wrote:
> Soyons précis, ce n'est pas le "système" qui remplace l'étoile pa r la
> liste des fichiers, mais le shell.
Exact. J'ai dit "système" car pour moi le shell fait partie du systèm e :
Système = noyau + coquille
même si le shell est interchangeable.
--
JiPaul.
/ /--/--//\ Jean-Paul Bl anc
|/| L |\ quelquepart en (somewhe re in)
/|| = |||\ F RANCE
Un moyen simple ? Non.
Bienvenue dans le monde *BSD.
Arf, dommage :/
En ce qui concerne cp (par exemple) je n'est jamais vu d'implantation ou
les options seraient n'importe où. Ce qui veut dire que c'est
l'implantation de cp dans ton linux qui est une exception. Pas celle de
Mac OS X.
C'est le cas sous Debian et Archlinux (et je pense sous tous les
Linux, bien que je n'ai pas vérifié).
le système (car c'est lui qui le fait sous Unix) va remplacer l'étoil e par la liste des 10000
fichiers. Ce qui fait que la commande cp devrait lire les 10002
arguments qu'elle reçoit avant de voir que le dernier est une option,
prendre en compte cette option, puis relire les 10001 premiers arguments
pour faire la copie. Cela me paraît une perte de temps (et c'est ce qui
explique la recommendation : les options en premier)
Pour avoir déjà travailler avec des options dans un programme, ce
n'est pas exactement de cette façon que cela fonctionne.
La fonction utilisée pour analyser les options est getopt() (http://
www.gnu.org/s/libc/manual/html_node/Example-of-Getopt.html#Example-of-Getop t).
Dans tous les cas, les arguments de la commande seront tous lu une
seule fois. Dès que la fonction trouve un "-", elle considère que
c'est une option et ensuite exécute différents tests pour déterminer
précisément l'option.
L'exécution à proprement parler de la commande (dans notre cas cp), ne
sera faite qu'après cette analyse.
C'est pour cette raison que je m'étonnais de l'ordre obligatoire à
respecter sous Mac OS X.
Franck <franck+ wrote: > Soyons précis, ce n'est pas le "système" qui remplace l'étoile pa r la > liste des fichiers, mais le shell.
Exact. J'ai dit "système" car pour moi le shell fait partie du systèm e :
Système = noyau + coquille
même si le shell est interchangeable. -- JiPaul. / /--/--// Jean-Paul Bl anc |/| L | quelquepart en (somewhe re in) /|| = ||| F RANCE
Un moyen simple ? Non. Bienvenue dans le monde *BSD.
Arf, dommage :/
En ce qui concerne cp (par exemple) je n'est jamais vu d'implantation ou les options seraient n'importe où. Ce qui veut dire que c'est l'implantation de cp dans ton linux qui est une exception. Pas celle de Mac OS X.
C'est le cas sous Debian et Archlinux (et je pense sous tous les Linux, bien que je n'ai pas vérifié).
le système (car c'est lui qui le fait sous Unix) va remplacer l'étoil e par la liste des 10000 fichiers. Ce qui fait que la commande cp devrait lire les 10002 arguments qu'elle reçoit avant de voir que le dernier est une option, prendre en compte cette option, puis relire les 10001 premiers arguments pour faire la copie. Cela me paraît une perte de temps (et c'est ce qui explique la recommendation : les options en premier)
Pour avoir déjà travailler avec des options dans un programme, ce n'est pas exactement de cette façon que cela fonctionne. La fonction utilisée pour analyser les options est getopt() (http:// www.gnu.org/s/libc/manual/html_node/Example-of-Getopt.html#Example-of-Getop t). Dans tous les cas, les arguments de la commande seront tous lu une seule fois. Dès que la fonction trouve un "-", elle considère que c'est une option et ensuite exécute différents tests pour déterminer précisément l'option. L'exécution à proprement parler de la commande (dans notre cas cp), ne sera faite qu'après cette analyse.
C'est pour cette raison que je m'étonnais de l'ordre obligatoire à respecter sous Mac OS X.
Merci pour vos réponses. Cordialement
Patrick Stadelmann
In article <1j62uuz.1hsgnxk1gk2fm6N%, (JiPaul) wrote:
J'ajouterais même que ton exemple me surprend, car lorsqu'on connait la syntaxe de cp (voir le man) cela parait difficile (bien que pas impossible) d'analyser une ligne de commande où les options seraient n'importe où.
Je confirme qu'à mon grand étonnement, la commande citée plus haut fonctionne sous Fedora, même si le man indique que les options viennent au début.
Patrick -- Patrick Stadelmann
In article <1j62uuz.1hsgnxk1gk2fm6N%blanc@empty.org>,
blanc@empty.org (JiPaul) wrote:
J'ajouterais même que ton exemple me surprend, car lorsqu'on connait la
syntaxe de cp (voir le man) cela parait difficile (bien que pas
impossible) d'analyser une ligne de commande où les options seraient
n'importe où.
Je confirme qu'à mon grand étonnement, la commande citée plus haut
fonctionne sous Fedora, même si le man indique que les options viennent
au début.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1j62uuz.1hsgnxk1gk2fm6N%, (JiPaul) wrote:
J'ajouterais même que ton exemple me surprend, car lorsqu'on connait la syntaxe de cp (voir le man) cela parait difficile (bien que pas impossible) d'analyser une ligne de commande où les options seraient n'importe où.
Je confirme qu'à mon grand étonnement, la commande citée plus haut fonctionne sous Fedora, même si le man indique que les options viennent au début.
Patrick -- Patrick Stadelmann
Franck
Tipoun wrote:
La fonction utilisée pour analyser les options est getopt() (http:// www.gnu.org/s/libc/manual/html_node/Example-of-Getopt.html#Example-of-G etopt). Dans tous les cas, les arguments de la commande seront tous lu une seule fois. Dès que la fonction trouve un "-", elle considère que c'est une option et ensuite exécute différents tests pour détermi ner précisément l'option.
Justement, c'est ce comportement, qui sous Linux, n'est pas conforme à la norme POSIX.
La "manpage" de getopt (man 3 getopt) indique d'ailleurs que l'on peut obtenir sous Linux un comportement POSIX en positionnant la variable d'environnement POSIXLY_CORRECT à 1. Dans ce cas le cp de Linux retrouv e un comportement identique à toutes les autres plateformes *nix.
Tipoun wrote:
La fonction utilisée pour analyser les options est getopt() (http://
www.gnu.org/s/libc/manual/html_node/Example-of-Getopt.html#Example-of-G etopt).
Dans tous les cas, les arguments de la commande seront tous lu une
seule fois. Dès que la fonction trouve un "-", elle considère que
c'est une option et ensuite exécute différents tests pour détermi ner
précisément l'option.
Justement, c'est ce comportement, qui sous Linux, n'est pas conforme à
la norme POSIX.
La "manpage" de getopt (man 3 getopt) indique d'ailleurs que l'on peut
obtenir sous Linux un comportement POSIX en positionnant la variable
d'environnement POSIXLY_CORRECT à 1. Dans ce cas le cp de Linux retrouv e
un comportement identique à toutes les autres plateformes *nix.
La fonction utilisée pour analyser les options est getopt() (http:// www.gnu.org/s/libc/manual/html_node/Example-of-Getopt.html#Example-of-G etopt). Dans tous les cas, les arguments de la commande seront tous lu une seule fois. Dès que la fonction trouve un "-", elle considère que c'est une option et ensuite exécute différents tests pour détermi ner précisément l'option.
Justement, c'est ce comportement, qui sous Linux, n'est pas conforme à la norme POSIX.
La "manpage" de getopt (man 3 getopt) indique d'ailleurs que l'on peut obtenir sous Linux un comportement POSIX en positionnant la variable d'environnement POSIXLY_CORRECT à 1. Dans ce cas le cp de Linux retrouv e un comportement identique à toutes les autres plateformes *nix.
TK
Tipoun a écrit :
Je suis à la recherche d'une feature un peu spéciale : sous n'importe quel Linux, je pouvais mettre les arguments des commandes du terminal dans n'importe quelle position et elles étaient prises en compte. Ex : cp toto tata -rf Lorsque j'essaye sous Mac, dans le terminal, je n'arrive pas à reproduire cette fonction. Il considère "-rf" comme un fichier :/ Y a-t-il un moyen ?
Pas trop top les arguments à la fin (c'est avec ce genre de détails qu'on réalise vraiment que GNU is not UNIX), mais enfin chacun ses goûts.
Le moyen le plus "simple" reste de compiler les GNU coreutils. Ensuite faire un alias de cp vers le répertoire ou ils sont installés (genre /usr/gnu/bin/cp). On peut aussi changer le PATH mais attention aux effets de bord.
Thomas
Tipoun a écrit :
Je suis à la recherche d'une feature un peu spéciale : sous n'importe
quel Linux, je pouvais mettre les arguments des commandes du terminal
dans n'importe quelle position et elles étaient prises en compte.
Ex : cp toto tata -rf
Lorsque j'essaye sous Mac, dans le terminal, je n'arrive pas à
reproduire cette fonction.
Il considère "-rf" comme un fichier :/
Y a-t-il un moyen ?
Pas trop top les arguments à la fin (c'est avec ce genre de détails
qu'on réalise vraiment que GNU is not UNIX), mais enfin chacun ses goûts.
Le moyen le plus "simple" reste de compiler les GNU coreutils. Ensuite
faire un alias de cp vers le répertoire ou ils sont installés (genre
/usr/gnu/bin/cp). On peut aussi changer le PATH mais attention aux
effets de bord.
Je suis à la recherche d'une feature un peu spéciale : sous n'importe quel Linux, je pouvais mettre les arguments des commandes du terminal dans n'importe quelle position et elles étaient prises en compte. Ex : cp toto tata -rf Lorsque j'essaye sous Mac, dans le terminal, je n'arrive pas à reproduire cette fonction. Il considère "-rf" comme un fichier :/ Y a-t-il un moyen ?
Pas trop top les arguments à la fin (c'est avec ce genre de détails qu'on réalise vraiment que GNU is not UNIX), mais enfin chacun ses goûts.
Le moyen le plus "simple" reste de compiler les GNU coreutils. Ensuite faire un alias de cp vers le répertoire ou ils sont installés (genre /usr/gnu/bin/cp). On peut aussi changer le PATH mais attention aux effets de bord.
