La commande time

Je suis sous sous Ubuntu 10.04 et mon shell est le bash.

1) Je souhaite mesurer le temps d'exécution d'une commande avec :
~$ time maCommande

Au lieu d'avoir en sortie les 3 lignes real+user+sys, je ne voudrais
avoir en sortie que la ligne real. Comment faut-il faire ?

J'avais pensé d'abord au naïf :
~$ time maCommande | grep real
mais ça ne marche pas car, si je comprends bien, dans ce cas time mesure
le temps d'exécution de la commande "maCommande | grep real" et ensuite
fait son travail, c'est-à-dire affiche les 3 lignes et non une seule.

2) Du coup, j'ai voulu chercher des infos sur time avec 'man time'. J'ai
vu plein d'options avec cette commande mais aucune ne marchaient. J'ai
fini par comprendre que le time que j'utilise dans 1) est une commande
interne de mon shell et que le time de 'man time' est /usr/bin/time, une
commande externe à mon shell.

Y a-t-il un moyen, via le shell, de savoir qui exactement (le time
interne ou /usr/bin/time) est utilisé lorsque je tape 'time XXX' ? Je

pensais au départ que 'which time' le faisait mais justement il
m'indique /usr/bin/time et j'ai pu lire que which ne s'occupait pas des
commandes interne au shell (which cd n'affiche rien). Je sais bien que
ce sont les commandes internes qui priment, mais je ne les connais pas
toutes. Est-ce que ça existe une commande du genre ci-dessous ?

~$ whichPourDeVrai time
commande interne time
~$ whichPourDeVrai
/usr/bin/pdflatex

Francois Lafont<francois.lafont@nospam.invalid> wrote:

C'est juste, si which ne trouve rien, c'est une commande interne. Mais
la réciproque n'est pas forcément vraie, en particulier avec time
justement. J'ai ça :

~$ which time
/usr/bin/time

Et moi, j'ai ça avec la commande type :

[xavier@enterprise ~]$ type time
time is a shell keyword
[xavier@enterprise ~]$ which time
...rien...

C'est que tu n'as toujours pas compris ce que je tente de t'expliquer :

C'est possible, mais ce n'est pas de la mauvaise volonté de ma part, je
t'assure. Par ailleurs, j'ai pourtant vraiment l'impression d'avoir
compris ton exemple avec cd (on est dans /, on crée un "sous-shell", on
bouge avec cd, on quitte le "sous-shell" avec exit et là hop est
toujours à la case départ dans /), mais je n'ai pas compris pourquoi tu
m'as montré cet exemple (je ne vois pas le lien avec ce que je voulais
faire remarquer).

Je fais un petit rappel. À un moment, tu as écrit ceci (message à 22h26) :

« Les primitives (builtin) sont des commandes classiques *que l'on
trouve dans le $PATH* »
[...]
J'en ai conclu que cd n'était pas dans le $PATH et que donc les
primitives (builtin) ne sont *pas toutes* dans le $PATH

Où est mon erreur ci-dessus ?

type man
man est haché (/usr/bin/man)

C'est quoi une commande "haché" ?

Le 24/08/2010 22:26, Benoit Izac a écrit :

C'est quoi la nuance entre 'mot-clé' et 'primitive' ?

Les mots clés c'est « if », « while », « ! », « done », etc. Ce sont des
mots qui change le comportement du shell lorsqu'ils sont les premiers
mots d'une commande.

if true
then
while false
do
time sleep 10
done
else
{ echo "hello" }
fi
Ici, tous les premiers mots sont des mots clés (reserved words selon
POSIX).

Ok.

Les primitives (builtin) sont des commandes classiques que l'on trouve
dans le $PATH qui ont été implémentées au niveau du shell. Ça permet
d'éviter un fork à chaque appel.

Mais pourtant, chez moi, les commandes "builtin" ne sont pas toutes dans
le $PATH.

~$ type cd
cd est une primitive du shell
~/Bureau$ sudo find / -type f -name "cd"
/usr/share/X11/xkb/symbols/cd
/usr/share/screen/utf8encodings/cd
/usr/share/zsh/help/cd

~$ type read
read est une primitive du shell
~/Bureau$ sudo find / -type f -name "read"
/usr/share/zsh/help/read

~$ type printf
printf est une primitive du shell
~$ sudo find / -type f -name "printf"
/usr/share/zsh/help/printf

/usr/bin/printf # la c'est dans le $PATH

~$ echo hello | read a
~$ echo $a

Le 25/08/2010 14:49, Erwan David a écrit :

un -exceutable dans le find aurait déjà restreint...

Oui en effet et d'ailleurs, quitte à chercher une commande dans le
$PATH, autant faire "which ma_commande" il me semble.

Ce cher Francois Lafont <francois.lafont@nospam.invalid> a posté :

Le 25/08/2010 14:49, Erwan David a écrit :

un -exceutable dans le find aurait déjà restreint...

Oui en effet et d'ailleurs, quitte à chercher une commande dans le
$PATH, autant faire "which ma_commande" il me semble.

+1

et l'option -p du which de zsh est du pain bénit :

$ which which
which: shell built-in command
$ which -p which
/usr/bin/which
$

Très pratique dans mes shellscripts, lorsque je veux, par exemple, faire
un wrapper pour une commande donnée :

$ ls () { echo "Listing $@" ; $(which -p ls) $@ }

Cela permet d'éviter d'appeller de façon récursive la fonction.. :o)

tu as sûrement dû tester, non pas sur bash, mais sur un shell qui
n'utilise pas de sous-shell dans un pipe lorsque la commande de droite
est builtin ou un truc comme ça.

Ai-je bien compris l'exemple que tu m'as donné ? (j'espère que oui cette
fois ;-))

À propos de zsh, je n'ai pas réussi à trouver dans 'man zshall'
l'endroit il était dit que le pipe de ne créait pas de sous-shell. Avec
le bash, j'ai pu trouver l'info sur ce point assez facilement.

1. ~$ echo toto
2. ~$ /bin/echo toto

c'est bien deux versions différentes de echo qui sont appelées ?

- dans la première instruction, c'est la commande builtin (dont le code
est encapsulé dans /bin/bash), pas de processus enfant créé.
- dans la deuxième, c'est la commande externe /bin/echo et un processus
enfant est créé.

C'est bien cela ?

D'une manière générale, quand une commande du $PATH est appelée par son
chemin absolu (pour éviter que le bash y voit une éventuelle commande
builtin), y a-t-il toujours un processus enfant qui est créé ?