Sur une woody, sarge:
$ ls -l README | cut -d ' ' -f 6
2973
$ ls -l README | cut -d ' ' -f 5
francois
$
Sur une sid, une etch
$ ls -l README | cut -d ' ' -f 6
2007-03-08
$ ls -l README | cut -d ' ' -f 5
2973
$
En fait il y a un blanc qui a disparu dans le ls… et voilà comment apparait un bug 
Oui, mais à mon avis, c’est pas ls qui est en cause, c’est cut.
J’ai remarqué ce genre de comportement, mais pas de la même façon. En fait, cut sélectionne n ou n*x octets et non des colonnes à la façon de awk, j’ai cru comprendre. si bien que ls -l cut -d ’ ’ -f5 ne donnera pas toujours la cinquième colonne de la sortie de ls -l, ça dépendra de la valeur en octets des “4 premières colonnes” …
Enfin je pensais ça, mais sur le même fichier, là, ça laisse perplexe.
De toutes façons, j’évite d’utiliser cut depuis (à défaut de comprendre).
Ici en l’occurrence, je m’en suis sorti en rajoutant un | sed -e ‘s/ / /g’ qui a réglé la question.
En fait qu’est ce que tu voulais faire ?
ps: parce que je viens de capter un truc et je suis justement sur un truc de similaire … si je peux te suggérer mon idée ? 
Paquet fricorder, adaptation à sid. Relance du flux video lorsque celui ci s’arrete, ça permet d’avoir un enregistrement video valable malgré une ligne pourrie. Je teste régulièrement la longueur de fuchier produit.
Mais … ah oui, super.
ben dans ce cas là, je préfèrerai ça moi :
Oui, usuellement c’est ce que je faisais, mais il y a eu un souci avec une Ubuntu (breezy?) avec ça, je ne me souviens plus pourquoi et j’ai utilisé cut à cause de ça.