je voudrai réaliser l'opération suivante : j'ai une commande que je nommerai
ma_commande qui me retourne un chemin absolu (/home/user/fred par exemple). Je
voudrai copier le contenu de ce répertoire dans le répertoire "toto". Mon idée
est quelque chose comme ça :
ma_commande | cp $1 toto
mais ce système avec $1 ne fonctionne pas. Comment faire pour appeler le
résultat de "ma_commande" avec cp ?
Voilà, en espérant avoir été clair
Fred.
--
Ce message a été posté via la plateforme Web club-Internet.fr
This message has been posted by the Web platform club-Internet.fr
Ça ne fait que déporter le problème, sur certains shells, "command" n'est pas l'utilitaire POSIX attendu.
Sur les systèmes POSIX avec l'option "User Portability Utilities", on peut avoir le résultat à la sortie de "command -p -v sh".
Jean-Marc Bourguet
Stephane CHAZELAS writes:
On peut se contenter d'un header comme wrapper:
: if test "x$0-$$" != "x$SKIP_WRAP"; then SKIP_WRAP=$0-$$ export SKIP_WRAP for sh in /usr/xpg4/bin /usr/posix/bin /bin /usr/bin; do test -x "$sh/sh" && exec "$sh/sh" "$0" ${1+"$@"} done fi
Nos messages ont du se croiser. En combinant les deux,
if [ "X$1" = "X-inPosixShell" ] ; then shift else Sifs=$IFS IFS=: for i in `command -p getconf PATH` ; do if [ -x "${i}/sh" ] ; then IFS=$Sifs unset -v Sifs Pshell exec "${i}/sh" -- "$0" -inPosixShell "$@" fi done IFS=$Sifs unset -v Sifs Pshell fi
Quelle est la difference entre "$@" et ${1+"$@"} ? A priori ca fait la meme chose a moins qu'il y ait des shells qui ne suppriment pas completement "$@" quand il n'y a pas d'arguments?
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
:
if test "x$0-$$" != "x$SKIP_WRAP"; then
SKIP_WRAP=$0-$$ export SKIP_WRAP
for sh in /usr/xpg4/bin /usr/posix/bin /bin /usr/bin; do
test -x "$sh/sh" && exec "$sh/sh" "$0" ${1+"$@"}
done
fi
Nos messages ont du se croiser. En combinant les deux,
if [ "X$1" = "X-inPosixShell" ] ; then
shift
else
Sifs=$IFS
IFS=:
for i in `command -p getconf PATH` ; do
if [ -x "${i}/sh" ] ; then
IFS=$Sifs
unset -v Sifs Pshell
exec "${i}/sh" -- "$0" -inPosixShell "$@"
fi
done
IFS=$Sifs
unset -v Sifs Pshell
fi
Quelle est la difference entre "$@" et ${1+"$@"} ? A priori ca fait
la meme chose a moins qu'il y ait des shells qui ne suppriment pas
completement "$@" quand il n'y a pas d'arguments?
A+
--
Jean-Marc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
: if test "x$0-$$" != "x$SKIP_WRAP"; then SKIP_WRAP=$0-$$ export SKIP_WRAP for sh in /usr/xpg4/bin /usr/posix/bin /bin /usr/bin; do test -x "$sh/sh" && exec "$sh/sh" "$0" ${1+"$@"} done fi
Nos messages ont du se croiser. En combinant les deux,
if [ "X$1" = "X-inPosixShell" ] ; then shift else Sifs=$IFS IFS=: for i in `command -p getconf PATH` ; do if [ -x "${i}/sh" ] ; then IFS=$Sifs unset -v Sifs Pshell exec "${i}/sh" -- "$0" -inPosixShell "$@" fi done IFS=$Sifs unset -v Sifs Pshell fi
Quelle est la difference entre "$@" et ${1+"$@"} ? A priori ca fait la meme chose a moins qu'il y ait des shells qui ne suppriment pas completement "$@" quand il n'y a pas d'arguments?
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Stephane CHAZELAS
Le Tue, 14 Oct 2003 14:25:37 +0000 (UTC), Laurent Wacrenier écrivait : [...]
??? Ça retourne le dernier "sh" dans le PATH au lieu du premier.
Et alors ? S'il y a plusieurs shells POSIX, on peut prendre celui qu'on veut.
POSIX dit que "command -v sh" avec PATH=`getconf PATH` retourne le chemin d'un shell standard, pas que tous les "sh" du `getconf PATH` sont nécessairement POSIX.
[ -x "$Pshell" ] && break
Ça ne marche pas si un répertoire "sh" traine dans le PATH avant le shell lui même.
Oui, ou encore s'il y a des "*" ou des sauts de lignes dans PATH, tout ça reste unlikely.
[ -x "$Pshell" ] && [ ! -d "$Pshell" ] alors.
-- Stéphane
Le Tue, 14 Oct 2003 14:25:37 +0000 (UTC), Laurent Wacrenier <lwa@teaser> écrivait :
[...]
??? Ça retourne le dernier "sh" dans le PATH au lieu du
premier.
Et alors ? S'il y a plusieurs shells POSIX, on peut prendre celui
qu'on veut.
POSIX dit que "command -v sh" avec PATH=`getconf PATH` retourne
le chemin d'un shell standard, pas que tous les "sh" du `getconf
PATH` sont nécessairement POSIX.
[ -x "$Pshell" ] && break
Ça ne marche pas si un répertoire "sh" traine dans le PATH avant
le shell lui même.
Oui, ou encore s'il y a des "*" ou des sauts de lignes dans
PATH, tout ça reste unlikely.
Le Tue, 14 Oct 2003 14:25:37 +0000 (UTC), Laurent Wacrenier écrivait : [...]
??? Ça retourne le dernier "sh" dans le PATH au lieu du premier.
Et alors ? S'il y a plusieurs shells POSIX, on peut prendre celui qu'on veut.
POSIX dit que "command -v sh" avec PATH=`getconf PATH` retourne le chemin d'un shell standard, pas que tous les "sh" du `getconf PATH` sont nécessairement POSIX.
[ -x "$Pshell" ] && break
Ça ne marche pas si un répertoire "sh" traine dans le PATH avant le shell lui même.
Oui, ou encore s'il y a des "*" ou des sauts de lignes dans PATH, tout ça reste unlikely.
[ -x "$Pshell" ] && [ ! -d "$Pshell" ] alors.
-- Stéphane
Stephane CHAZELAS
Le 14 Oct 2003 16:36:52 +0200, Jean-Marc Bourguet écrivait : [...]
if test "x$0-$$" != "x$SKIP_WRAP"; then SKIP_WRAP=$0-$$ export SKIP_WRAP for sh in /usr/xpg4/bin /usr/posix/bin /bin /usr/bin; do test -x "$sh/sh" && exec "$sh/sh" "$0" ${1+"$@"} done fi
Nos messages ont du se croiser. En combinant les deux,
if [ "X$1" = "X-inPosixShell" ] ; then
Utiliser $1 plutot qu'une variable d'environnement limite l'utilisation du script.
shift else Sifs=$IFS IFS=: for i in `command -p getconf PATH` ; do
command n'est pas dans les shell Bourne, tout ça ne sert à rien si on suppose déjà qu'on a un shell POSIX.
De plus, si tu supposes l'existense de "command" tu peux utiliser "command -v" pour déterminer le chemin de "sh"
Pas d'unset -v dans le Bourne shell, surtout que le "-v" sert pas à grand chose ici.
Si IFS était indéfini au départ, il se retrouve vide maintenant, ce qui est complètement différent.
Enfin, en principe, ces deux lignes de restauration d'IFS ne sont jamais exécutées, vu qu'on est censé avoir fait un "exec sh" avant (pas besoin de conserver IFS non plus du coup).
fi
Quelle est la difference entre "$@" et ${1+"$@"} ? A priori ca fait la meme chose a moins qu'il y ait des shells qui ne suppriment pas completement "$@" quand il n'y a pas d'arguments?
C'est ça, le Bourne shell, précisément. L'ennui, c'est que ça ne marche pas bien avec zsh, tu peux rajouter avant:
case $ZSH_VERSION in ?*) alias -g '${1+"$@"}="$@"';; esac
-- Stéphane
Le 14 Oct 2003 16:36:52 +0200, Jean-Marc Bourguet <jm@bourguet.org> écrivait :
[...]
if test "x$0-$$" != "x$SKIP_WRAP"; then
SKIP_WRAP=$0-$$ export SKIP_WRAP
for sh in /usr/xpg4/bin /usr/posix/bin /bin /usr/bin; do
test -x "$sh/sh" && exec "$sh/sh" "$0" ${1+"$@"}
done
fi
Nos messages ont du se croiser. En combinant les deux,
if [ "X$1" = "X-inPosixShell" ] ; then
Utiliser $1 plutot qu'une variable d'environnement limite
l'utilisation du script.
shift
else
Sifs=$IFS
IFS=:
for i in `command -p getconf PATH` ; do
command n'est pas dans les shell Bourne, tout ça ne sert à rien
si on suppose déjà qu'on a un shell POSIX.
De plus, si tu supposes l'existense de "command" tu peux
utiliser "command -v" pour déterminer le chemin de "sh"
Pas d'unset -v dans le Bourne shell, surtout que le "-v" sert
pas à grand chose ici.
Si IFS était indéfini au départ, il se retrouve vide maintenant,
ce qui est complètement différent.
Enfin, en principe, ces deux lignes de restauration d'IFS ne
sont jamais exécutées, vu qu'on est censé avoir fait un "exec
sh" avant (pas besoin de conserver IFS non plus du coup).
fi
Quelle est la difference entre "$@" et ${1+"$@"} ? A priori ca fait
la meme chose a moins qu'il y ait des shells qui ne suppriment pas
completement "$@" quand il n'y a pas d'arguments?
C'est ça, le Bourne shell, précisément.
L'ennui, c'est que ça ne marche pas bien avec zsh, tu peux
rajouter avant:
case $ZSH_VERSION in ?*) alias -g '${1+"$@"}="$@"';; esac
Le 14 Oct 2003 16:36:52 +0200, Jean-Marc Bourguet écrivait : [...]
if test "x$0-$$" != "x$SKIP_WRAP"; then SKIP_WRAP=$0-$$ export SKIP_WRAP for sh in /usr/xpg4/bin /usr/posix/bin /bin /usr/bin; do test -x "$sh/sh" && exec "$sh/sh" "$0" ${1+"$@"} done fi
Nos messages ont du se croiser. En combinant les deux,
if [ "X$1" = "X-inPosixShell" ] ; then
Utiliser $1 plutot qu'une variable d'environnement limite l'utilisation du script.
shift else Sifs=$IFS IFS=: for i in `command -p getconf PATH` ; do
command n'est pas dans les shell Bourne, tout ça ne sert à rien si on suppose déjà qu'on a un shell POSIX.
De plus, si tu supposes l'existense de "command" tu peux utiliser "command -v" pour déterminer le chemin de "sh"
Pas d'unset -v dans le Bourne shell, surtout que le "-v" sert pas à grand chose ici.
Si IFS était indéfini au départ, il se retrouve vide maintenant, ce qui est complètement différent.
Enfin, en principe, ces deux lignes de restauration d'IFS ne sont jamais exécutées, vu qu'on est censé avoir fait un "exec sh" avant (pas besoin de conserver IFS non plus du coup).
fi
Quelle est la difference entre "$@" et ${1+"$@"} ? A priori ca fait la meme chose a moins qu'il y ait des shells qui ne suppriment pas completement "$@" quand il n'y a pas d'arguments?
C'est ça, le Bourne shell, précisément. L'ennui, c'est que ça ne marche pas bien avec zsh, tu peux rajouter avant:
case $ZSH_VERSION in ?*) alias -g '${1+"$@"}="$@"';; esac
-- Stéphane
Laurent Wacrenier
Stephane CHAZELAS écrit:
[ -x "$Pshell" ] && break
Ça ne marche pas si un répertoire "sh" traine dans le PATH avant le shell lui même.
Oui, ou encore s'il y a des "*" ou des sauts de lignes dans PATH, tout ça reste unlikely.
Comment celà ?
[ -x "$Pshell" ] && [ ! -d "$Pshell" ] alors.
Ça peut être une socket ou un pipe avec le bit 'x'.
Ça ne marche pas si un répertoire "sh" traine dans le PATH avant le shell lui même.
Oui, ou encore s'il y a des "*" ou des sauts de lignes dans PATH, tout ça reste unlikely.
Comment celà ?
[ -x "$Pshell" ] && [ ! -d "$Pshell" ] alors.
Ça peut être une socket ou un pipe avec le bit 'x'.
test -f "$Pshell" -a -x "$Pshell"
noa
Frederic a écrit:
Bonjour,
je voudrai réaliser l'opération suivante : j'ai une commande que je nommerai ma_commande qui me retourne un chemin absolu (/home/user/fred par exemple). Je voudrai copier le contenu de ce répertoire dans le répertoire "toto". Mon idée est quelque chose comme ça :
ma_commande | cp $1 toto
mais ce système avec $1 ne fonctionne pas. Comment faire pour appeler le résultat de "ma_commande" avec cp ?
Voilà, en espérant avoir été clair
Fred. peut-être que tu pourrais essayer avec:
mkfifo tube;ls>tube& cp `cat tube` tmp;rm tube tu remplaces ls par ta commande
-- noa ouv a s à cdm, g
Frederic a écrit:
Bonjour,
je voudrai réaliser l'opération suivante : j'ai une commande que je
nommerai ma_commande qui me retourne un chemin absolu (/home/user/fred par
exemple). Je voudrai copier le contenu de ce répertoire dans le répertoire
"toto". Mon idée est quelque chose comme ça :
ma_commande | cp $1 toto
mais ce système avec $1 ne fonctionne pas. Comment faire pour appeler le
résultat de "ma_commande" avec cp ?
Voilà, en espérant avoir été clair
Fred.
peut-être que tu pourrais essayer avec:
mkfifo tube;ls>tube& cp `cat tube` tmp;rm tube
tu remplaces ls par ta commande
je voudrai réaliser l'opération suivante : j'ai une commande que je nommerai ma_commande qui me retourne un chemin absolu (/home/user/fred par exemple). Je voudrai copier le contenu de ce répertoire dans le répertoire "toto". Mon idée est quelque chose comme ça :
ma_commande | cp $1 toto
mais ce système avec $1 ne fonctionne pas. Comment faire pour appeler le résultat de "ma_commande" avec cp ?
Voilà, en espérant avoir été clair
Fred. peut-être que tu pourrais essayer avec:
mkfifo tube;ls>tube& cp `cat tube` tmp;rm tube tu remplaces ls par ta commande
-- noa ouv a s à cdm, g
Stephane CHAZELAS
Le Tue, 14 Oct 2003 16:04:38 +0000 (UTC), Laurent Wacrenier écrivait :
Stephane CHAZELAS écrit:
[ -x "$Pshell" ] && break
Ça ne marche pas si un répertoire "sh" traine dans le PATH avant le shell lui même.
Oui, ou encore s'il y a des "*" ou des sauts de lignes dans PATH, tout ça reste unlikely.
Comment celà ?
Qu'il y ait un répertoire "sh" dans /usr/bin où /usr/* dans $PATH serait pas la preuve d'un système super bien pensé.
[ -x "$Pshell" ] && [ ! -d "$Pshell" ] alors.
Ça peut être une socket ou un pipe avec le bit 'x'.
Oui, et au moins pour ksh93 et bash, une fifo avec les droits d'exécution dans le PATH est candidat à l'exécution et est retourné par "command -v", il n'est pas dit qu'un jour ne soit pas créé un nouveau type de fichier qui soit aussi exécutable...
-- Stéphane
Le Tue, 14 Oct 2003 16:04:38 +0000 (UTC), Laurent Wacrenier <lwa@teaser> écrivait :
Ça ne marche pas si un répertoire "sh" traine dans le PATH avant
le shell lui même.
Oui, ou encore s'il y a des "*" ou des sauts de lignes dans
PATH, tout ça reste unlikely.
Comment celà ?
Qu'il y ait un répertoire "sh" dans /usr/bin où /usr/* dans
$PATH serait pas la preuve d'un système super bien pensé.
[ -x "$Pshell" ] && [ ! -d "$Pshell" ]
alors.
Ça peut être une socket ou un pipe avec le bit 'x'.
Oui, et au moins pour ksh93 et bash, une fifo avec les droits
d'exécution dans le PATH est candidat à l'exécution et est
retourné par "command -v", il n'est pas dit qu'un jour ne soit
pas créé un nouveau type de fichier qui soit aussi exécutable...
Le Tue, 14 Oct 2003 16:04:38 +0000 (UTC), Laurent Wacrenier écrivait :
Stephane CHAZELAS écrit:
[ -x "$Pshell" ] && break
Ça ne marche pas si un répertoire "sh" traine dans le PATH avant le shell lui même.
Oui, ou encore s'il y a des "*" ou des sauts de lignes dans PATH, tout ça reste unlikely.
Comment celà ?
Qu'il y ait un répertoire "sh" dans /usr/bin où /usr/* dans $PATH serait pas la preuve d'un système super bien pensé.
[ -x "$Pshell" ] && [ ! -d "$Pshell" ] alors.
Ça peut être une socket ou un pipe avec le bit 'x'.
Oui, et au moins pour ksh93 et bash, une fifo avec les droits d'exécution dans le PATH est candidat à l'exécution et est retourné par "command -v", il n'est pas dit qu'un jour ne soit pas créé un nouveau type de fichier qui soit aussi exécutable...
-- Stéphane
Pascal Bourguignon
noa writes:
Frederic a écrit:
Bonjour,
je voudrai réaliser l'opération suivante : j'ai une commande que je nommerai ma_commande qui me retourne un chemin absolu (/home/user/fred par exemple). Je voudrai copier le contenu de ce répertoire dans le répertoire "toto". Mon idée est quelque chose comme ça :
ma_commande | cp $1 toto
mais ce système avec $1 ne fonctionne pas. Comment faire pour appeler le résultat de "ma_commande" avec cp ?
Voilà, en espérant avoir été clair
Fred. peut-être que tu pourrais essayer avec:
mkfifo tube;ls>tube& cp `cat tube` tmp;rm tube tu remplaces ls par ta commande
Bin oui, pourquoi ne pas faire des usines à gas, autant en profiter, c'est gratuit tout ces tubes!
cp ` ma_commande ` toto # C'est des back-quotes. cp $( ma_commande ) toto
-- __Pascal_Bourguignon__ http://www.informatimago.com/ Do not adjust your mind, there is a fault in reality. Lying for having sex or lying for making war? Trust US presidents :-(
noa <a@a.fr> writes:
Frederic a écrit:
Bonjour,
je voudrai réaliser l'opération suivante : j'ai une commande que je
nommerai ma_commande qui me retourne un chemin absolu (/home/user/fred par
exemple). Je voudrai copier le contenu de ce répertoire dans le répertoire
"toto". Mon idée est quelque chose comme ça :
ma_commande | cp $1 toto
mais ce système avec $1 ne fonctionne pas. Comment faire pour appeler le
résultat de "ma_commande" avec cp ?
Voilà, en espérant avoir été clair
Fred.
peut-être que tu pourrais essayer avec:
mkfifo tube;ls>tube& cp `cat tube` tmp;rm tube
tu remplaces ls par ta commande
Bin oui, pourquoi ne pas faire des usines à gas, autant en profiter,
c'est gratuit tout ces tubes!
cp ` ma_commande ` toto # C'est des back-quotes.
cp $( ma_commande ) toto
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.
Lying for having sex or lying for making war? Trust US presidents :-(
je voudrai réaliser l'opération suivante : j'ai une commande que je nommerai ma_commande qui me retourne un chemin absolu (/home/user/fred par exemple). Je voudrai copier le contenu de ce répertoire dans le répertoire "toto". Mon idée est quelque chose comme ça :
ma_commande | cp $1 toto
mais ce système avec $1 ne fonctionne pas. Comment faire pour appeler le résultat de "ma_commande" avec cp ?
Voilà, en espérant avoir été clair
Fred. peut-être que tu pourrais essayer avec:
mkfifo tube;ls>tube& cp `cat tube` tmp;rm tube tu remplaces ls par ta commande
Bin oui, pourquoi ne pas faire des usines à gas, autant en profiter, c'est gratuit tout ces tubes!
cp ` ma_commande ` toto # C'est des back-quotes. cp $( ma_commande ) toto
-- __Pascal_Bourguignon__ http://www.informatimago.com/ Do not adjust your mind, there is a fault in reality. Lying for having sex or lying for making war? Trust US presidents :-(
noa
Pascal Bourguignon a écrit:
noa writes:
Frederic a écrit:
Bonjour,
je voudrai réaliser l'opération suivante : j'ai une commande que je nommerai ma_commande qui me retourne un chemin absolu (/home/user/fred par exemple). Je voudrai copier le contenu de ce répertoire dans le répertoire "toto". Mon idée est quelque chose comme ça :
ma_commande | cp $1 toto
mais ce système avec $1 ne fonctionne pas. Comment faire pour appeler le résultat de "ma_commande" avec cp ?
Voilà, en espérant avoir été clair
Fred. peut-être que tu pourrais essayer avec:
mkfifo tube;ls>tube& cp `cat tube` tmp;rm tube tu remplaces ls par ta commande
Bin oui, pourquoi ne pas faire des usines à gas, autant en profiter, C'est une alternative qui marche aussi (heureusement) :-)
J'ai repris la forme qu'il veut sans savoir s'il y avait une application
ma_commande | cp $1 toto Je conteste pas la solution que je ferais, je vais pas me casser la tête à
faire ce truc. Pourrais-tu en dire plus sur les implications précises des 2 méthodes? Et pourquoi il ne peut y avoir d'application de l'utilisation d'un tube nommé, ça m'aiderai pour mieux comprendre le fonctionnement des flux. J'ai fait un essai de transfert d'un gros volume d'informations avec find/cp avec les 2 commandes
c'est gratuit tout ces tubes! Comment on peut évaluer le coût du tube?
le test que j'ai effectué, sans garantie de précision puisque d'autres processus tournent
## avec tube nommé 1 (ordre des tests 0.68user 23.96system 2:07.32elapsed 19%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (187major+72minor)pagefaults 0swaps [1]+ Done find 14/rdf/ >tube
les tests ont été effectués 2 par 2 en alternance avec des temps de pause entre 2 essais pour limiter l'interaction des autres processus qui tournent on constate que la charge CPU est plus élevée sans tube nommé, le temps d'exécution aussi dans une moindre mesure... ce qui n'est pas une preuve d'économie de ressources...
Autre chose: Est-ce que le coût entre un flux de commandes et une fonction qui restitue le flux est le même? EXEMPLE flux de commande ou {fonction qui envoie ce flux} ou {fichier exécuté qui envoie ce flux}
merci d'avoir tout lu :-)
-- noa ouv a s à cdm, g
Pascal Bourguignon a écrit:
noa <a@a.fr> writes:
Frederic a écrit:
Bonjour,
je voudrai réaliser l'opération suivante : j'ai une commande que je
nommerai ma_commande qui me retourne un chemin absolu (/home/user/fred
par exemple). Je voudrai copier le contenu de ce répertoire dans le
répertoire "toto". Mon idée est quelque chose comme ça :
ma_commande | cp $1 toto
mais ce système avec $1 ne fonctionne pas. Comment faire pour appeler
le résultat de "ma_commande" avec cp ?
Voilà, en espérant avoir été clair
Fred.
peut-être que tu pourrais essayer avec:
mkfifo tube;ls>tube& cp `cat tube` tmp;rm tube
tu remplaces ls par ta commande
Bin oui, pourquoi ne pas faire des usines à gas, autant en profiter,
C'est une alternative qui marche aussi (heureusement) :-)
J'ai repris la forme qu'il veut sans savoir s'il y avait une application
ma_commande | cp $1 toto
Je conteste pas la solution que je ferais, je vais pas me casser la tête à
faire ce truc.
Pourrais-tu en dire plus sur les implications précises des 2 méthodes? Et
pourquoi il ne peut y avoir d'application de l'utilisation d'un tube nommé,
ça m'aiderai pour mieux comprendre le fonctionnement des flux.
J'ai fait un essai de transfert d'un gros volume d'informations avec find/cp
avec les 2 commandes
c'est gratuit tout ces tubes!
Comment on peut évaluer le coût du tube?
le test que j'ai effectué, sans garantie de précision puisque d'autres
processus tournent
## avec tube nommé
1 (ordre des tests
0.68user 23.96system 2:07.32elapsed 19%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (187major+72minor)pagefaults 0swaps
[1]+ Done find 14/rdf/ >tube
les tests ont été effectués 2 par 2 en alternance avec des temps de pause
entre 2 essais pour limiter l'interaction des autres processus qui tournent
on constate que la charge CPU est plus élevée sans tube nommé, le temps
d'exécution aussi dans une moindre mesure... ce qui n'est pas une preuve
d'économie de ressources...
Autre chose:
Est-ce que le coût entre un flux de commandes et une fonction qui restitue
le flux est le même?
EXEMPLE
flux de commande ou {fonction qui envoie ce flux} ou {fichier exécuté qui
envoie ce flux}
je voudrai réaliser l'opération suivante : j'ai une commande que je nommerai ma_commande qui me retourne un chemin absolu (/home/user/fred par exemple). Je voudrai copier le contenu de ce répertoire dans le répertoire "toto". Mon idée est quelque chose comme ça :
ma_commande | cp $1 toto
mais ce système avec $1 ne fonctionne pas. Comment faire pour appeler le résultat de "ma_commande" avec cp ?
Voilà, en espérant avoir été clair
Fred. peut-être que tu pourrais essayer avec:
mkfifo tube;ls>tube& cp `cat tube` tmp;rm tube tu remplaces ls par ta commande
Bin oui, pourquoi ne pas faire des usines à gas, autant en profiter, C'est une alternative qui marche aussi (heureusement) :-)
J'ai repris la forme qu'il veut sans savoir s'il y avait une application
ma_commande | cp $1 toto Je conteste pas la solution que je ferais, je vais pas me casser la tête à
faire ce truc. Pourrais-tu en dire plus sur les implications précises des 2 méthodes? Et pourquoi il ne peut y avoir d'application de l'utilisation d'un tube nommé, ça m'aiderai pour mieux comprendre le fonctionnement des flux. J'ai fait un essai de transfert d'un gros volume d'informations avec find/cp avec les 2 commandes
c'est gratuit tout ces tubes! Comment on peut évaluer le coût du tube?
le test que j'ai effectué, sans garantie de précision puisque d'autres processus tournent
## avec tube nommé 1 (ordre des tests 0.68user 23.96system 2:07.32elapsed 19%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (187major+72minor)pagefaults 0swaps [1]+ Done find 14/rdf/ >tube
les tests ont été effectués 2 par 2 en alternance avec des temps de pause entre 2 essais pour limiter l'interaction des autres processus qui tournent on constate que la charge CPU est plus élevée sans tube nommé, le temps d'exécution aussi dans une moindre mesure... ce qui n'est pas une preuve d'économie de ressources...
Autre chose: Est-ce que le coût entre un flux de commandes et une fonction qui restitue le flux est le même? EXEMPLE flux de commande ou {fonction qui envoie ce flux} ou {fichier exécuté qui envoie ce flux}
