[AIX] Palliatif à ls sur répertoire bien rempli

[Bahan]

Bonjour à toutes et à tous.

J'ai un petit problème sous la forme d'un répertoire trop rempli qui a pour conséquence que la commande ls ne passe plus.

Existe-t-il une autre façon dans ce genre de cas de lister le contenu d'un répertoire contenant autant de fichiers ?

Merci d'avance.

Cdt.

Bahan

[jlliagre]

Peut-être:

Code :

echo *

[f-k-z]

Yop,
avec la commande:

Code :

cat tonrep

@++

F-k-z

[BlaireauOne]

Dans ce cas, tu dois passer par la commande find

Equivalent ls :

find . -print
ou
find .

Equivalent ls -l :

find . -ls

[frp31]

Envoyé par Bahan

Bonjour à toutes et à tous.

J'ai un petit problème sous la forme d'un répertoire trop rempli qui a pour conséquence que la commande ls ne passe plus.

Existe-t-il une autre façon dans ce genre de cas de lister le contenu d'un répertoire contenant autant de fichiers ?

Merci d'avance.

Cdt.

Bahan

find . -ls est la methode la plus propre
mais ça ne devrai jamais arrivé....un grand menage d'été s'impose donc.

[jlliagre]

As-tu un message d'erreur avec ls ?

[frp31]

Envoyé par jlliagre

As-tu un message d'erreur avec ls ?

je suppose qu'il a le message "arg list too long"

[jlliagre]

Sans lui passer d'arguments ?

[frp31]

Envoyé par jlliagre

Sans lui passer d'arguments ?

apres avoir tester un volume volontairement saturé de fichiers bidons
une boucle de

Code :

dd if=/dev/full of=/tmp/lv02/test/$(date +"%Y%m%d%H%M") count=1

que ce soit ls ou ls -lrth c'est "arg list too long" qui remontra
donc à se souvenir :

ne pas confondre arguments de ligne de commande et arguments remontés/analysés par une commande.

[jlliagre]

Envoyé par frp31

apres avoir tester un volume volontairement saturé de fichiers bidons
une boucle de

Code :

dd if=/dev/full of=/tmp/lv02/test/$(date +"%Y%m%d%H%M") count=1

Hmmm, tu es sûr ?
J'ai du mal à y croire. Je viens de créer pour voir 192000 fichiers dans un répertoire et "ls" s'en sort bien. "ls *" prends pas mal de temps puis me sort le "arg list too long" attendu.

Code :

1
2
3
4
m3:/t/bigdir $ ls | wc -l    
  192000
m3:/t/bigdir $ ls * >/dev/null
ksh93: ls: /usr/bin/ls: cannot execute[Liste d'arguments trop longue]

que ce soit ls ou ls -lrth c'est "arg list too long" qui remontra

Pas chez moi, mais je n'utilise pas AIX. C'est un bug spécifique à AIX ?

donc à se souvenir :

ne pas confondre arguments de ligne de commande et arguments remontés/analysés par une commande.

Analysés, je veux bien mais les valeurs retournées par une commande ne sont pas des arguments, sauf imbrication de commandes.
Le message d'erreur est donc pour moi lui-même erroné s'il apparait avec la commande simple "ls".
"arg list" a toujours représenté sous Unix les arguments passés à une commande et "arg list too long" est le message remonté par le shell quand l'expansion des arguments sature la pile dans laquelle est stockée l'environnement (argv, envp) ce qui provoque une erreur "E2BIG". L'exécution de la commande ls sans arguments n'a donc pour moi aucune raison de remonter ce message.

[frp31]

Code :

J'ai du mal à y croire. Je viens de créer pour voir 192000 fichiers dans un répertoire et "ls" s'en sort bien. "ls *" prends pas mal de temps puis me sort le "arg list too long" attendu.

du mal a y croire ? pourtant comme tu viens de le prouver toi meme avec ton essai tu es dans le meme cas !


non c'est pas un bug c'est la limitation normale
et ceci n'est pas spécifique à AIX c'est aussi le cas pour n'importe quel unix mais à des niveaux differents

tru64 par exemple y est très sensible...

[jlliagre]

Envoyé par frp31

Code :

J'ai du mal à y croire. Je viens de créer pour voir 192000 fichiers dans un répertoire et "ls" s'en sort bien. "ls *" prends pas mal de temps puis me sort le "arg list too long" attendu.

du mal a y croire ? pourtant comme tu viens de le prouver toi meme avec ton essai tu es dans le meme cas !

Tu as mal lu ma réponse. Tu as écrit que "ls" sans arguments peut générer un "arg list too long".

Quand je ne passe pas d'arguments à ls, je n'ai pas ce message. Quand je passe l'argument "*" que le shell tente d'étendre oui.

Je pense qu'on est d'accord la dessus.

[frp31]

ah oui bien sur

pas reveillé moi ....