Bonjour,

Toujours dans mes scripts, j'aimerai tester si des fichier existe dans
un repertoire...

En gros, j'ai une tache cron qui se lance regulierement, et qui viens
déplacer les fichiers d'un dossier dans un autre sur un autre disque.

Le problème c'est que cette autre disque ne servant pas souvent, je le
met ne veille (hdparm) au bout de 20min....

Comme mon script se lance meme quand y'a pas de fichier a déplacer, et
que comme si le dossier est vide, mv me retourné une erreur, j'ai fait
la magouille suivante :

#!/bin/sh
touch /mnt/disquesource/in/notempty
mv /mnt/disquesource/in/* /mnt/disquedest/dest/
rm /mnt/disquedest/dest/notempty

ça allé très bien.... enfin, pas top tout de meme..... surtout que ça
a la facheuse tendance a sortir mon disque de l'etat de veille meme si
il n'y a pas de fichier a copier dessus....

Donc, j'aimerai faire un test pour voir si il existe ou pas des
fichier dans le dossier et quitter le script avant de faire le move.

je pense que c'est avec "test " mais je ne suis pas trop famillier
avec les script shell :-) alors si vous pouviez m'eclairer....


@+Fab

Merci

condo4 a écrit :
> Bonjour,
>
> Toujours dans mes scripts, j'aimerai tester si des fichier existe dans
> un repertoire...
>
> En gros, j'ai une tache cron qui se lance regulierement, et qui viens
> déplacer les fichiers d'un dossier dans un autre sur un autre disque.
>
> Le problème c'est que cette autre disque ne servant pas souvent, je le
> met ne veille (hdparm) au bout de 20min....
>
> Comme mon script se lance meme quand y'a pas de fichier a déplacer, et
> que comme si le dossier est vide, mv me retourné une erreur, j'ai fait
> la magouille suivante :
>
> #!/bin/sh
> touch /mnt/disquesource/in/notempty
> mv /mnt/disquesource/in/* /mnt/disquedest/dest/
> rm /mnt/disquedest/dest/notempty
>
> ça allé très bien.... enfin, pas top tout de meme..... surtout que ça
> a la facheuse tendance a sortir mon disque de l'etat de veille meme si
> il n'y a pas de fichier a copier dessus....
>
> Donc, j'aimerai faire un test pour voir si il existe ou pas des
> fichier dans le dossier et quitter le script avant de faire le move.
>
> je pense que c'est avec "test " mais je ne suis pas trop famillier
> avec les script shell :-) alors si vous pouviez m'eclairer....
>
>
> @+Fab
>
> Merci
>
Bonjour,

Il doit y avoir plus simple mais ceci fonctionne :
ls -l <chemin répertoire> | head -1 |cut -d" " -f2

condo4 wrote in message
<1188569505.480719.239850@22g2000hsm.googlegroups. com>:
> Toujours dans mes scripts, j'aimerai tester si des fichier existe dans
> un repertoire...

Tu peux faire un `find | head -n 2 | wc -l` ou équivalent.

> mv /mnt/disquesource/in/* /mnt/disquedest/dest/

Avec zsh, tu peux faire ceci:

l=(/mnt/disquesource/in/*(N))
(( $#l > 0 )) && mv $l /mnt/disquedest/dest/

julien a écrit :
> Il doit y avoir plus simple mais ceci fonctionne :
> ls -l <chemin répertoire> | head -1 |cut -d" " -f2

Ne fonctionnera pas avec des fichiers cachés.

--
Nicolas S.

Le Fri, 31 Aug 2007 07:11:45 -0700, condo4 a écrit:

> Bonjour,
>
> Toujours dans mes scripts, j'aimerai tester si des fichier existe dans
> un repertoire...
>

Est ce que ce sont des fichiers qui occupent de l'espace disque
normalement? Dans ce cas , si `du -s /mnt/disquesource/in/|cut -f1` est
supérieur à zéro, le répertoire n'est pas vide.

Ronald a écrit :
> Est ce que ce sont des fichiers qui occupent de l'espace disque
> normalement? Dans ce cas , si `du -s /mnt/disquesource/in/|cut -f1` est
> supérieur à zéro, le répertoire n'est pas vide.

Non, c'est faux. L'espace disque renvoyé par 'du' sur un répertoire vide
n'est pas zéro. Et tu ne traites pas correctement tous les cas de
figures, 'du' renvoi "0" pour les liens symboliques et les fichiers vides.

Mais surtout, tu négliges le temps nécessaire (et inutile) au parcours
de _toute_ l'arborescence du répertoire.

--
Nicolas S.

Le Fri, 31 Aug 2007 21:17:08 +0200, Nicolas S. a écrit:

> Ronald a écrit :
>> Est ce que ce sont des fichiers qui occupent de l'espace disque
>> normalement? Dans ce cas , si `du -s /mnt/disquesource/in/|cut -f1` est
>> supérieur à zéro, le répertoire n'est pas vide.
>
> Non, c'est faux. L'espace disque renvoyé par 'du' sur un répertoire vide
> n'est pas zéro.

$ ls -a test/
.. ..
$ du -s test/
0 test/

> Et tu ne traites pas correctement tous les cas de
> figures, 'du' renvoi "0" pour les liens symboliques et les fichiers vides.

Il me semblait pourtant avoir précisé.

> Mais surtout, tu négliges le temps nécessaire (et inutile) au parcours
> de _toute_ l'arborescence du répertoire.

Et donc ta solution?

Ronald wrote in message <pan.2007.08.31.19.49.22.370551@reply.to>:
> $ du -s test/
> 0 test/

Le résultat dépend du filesystem.

> Et donc ta solution?

Il n'est pas nécessaire d'avoir soi-même une solution pour dire qu'une autre
solution est mauvaise.

Le Fri, 31 Aug 2007 19:52:23 +0000, Nicolas George a écrit:

> Ronald wrote in message <pan.2007.08.31.19.49.22.370551@reply.to>:
>> $ du -s test/
>> 0 test/
>
> Le résultat dépend du filesystem.

ok.
xfs,jfs, tmpfs :0
ext2: 1

>> Et donc ta solution?
>
> Il n'est pas nécessaire d'avoir soi-même une solution pour dire qu'une autre
> solution est mauvaise.

Pour moi oui, une solution même imparfaite mais qui peut fonctionner
est toujours préférable à aucune.

Ronald wrote in message <pan.2007.08.31.20.12.10.464056@reply.to>:
> Pour moi oui, une solution même imparfaite mais qui peut fonctionner
> est toujours préférable à aucune.

Non. S'il y a un risque de perte de données ou de trou de sécurité, une
solution imparfaite est pire que rien du tout.

Le Fri, 31 Aug 2007 20:25:58 +0000, Nicolas George a écrit:

> Ronald wrote in message <pan.2007.08.31.20.12.10.464056@reply.to>:
>> Pour moi oui, une solution même imparfaite mais qui peut fonctionner
>> est toujours préférable à aucune.
>
> Non. S'il y a un risque de perte de données ou de trou de sécurité, une
> solution imparfaite est pire que rien du tout.

Sérieusement, tu en connais beaucoup des solutions parfaites, en pratique?

Le Fri, 31 Aug 2007 22:41:14 +0200, Ronald a écrit:

> Sérieusement, tu en connais beaucoup des solutions parfaites, en pratique?

Dans l'absolu ?
Non.

Dans ce cas particulier ?
Oui.

Le Fri, 31 Aug 2007 20:47:46 +0000, Arol a écrit:

> Le Fri, 31 Aug 2007 22:41:14 +0200, Ronald a écrit:
>
>> Sérieusement, tu en connais beaucoup des solutions parfaites, en pratique?
>
> Dans l'absolu ?
> Non.

Ah? Pourquoi ça m'inquiète un peu?

> Dans ce cas particulier ?
> Oui.

Et comme tu es super sympa, tu vas la garder pour toi?

Ronald a écrit :
>>> Et donc ta solution?

Ma solution est la même que Nicolas.

>> Il n'est pas nécessaire d'avoir soi-même une solution pour dire qu'une autre
>> solution est mauvaise.
>
> Pour moi oui, une solution même imparfaite mais qui peut fonctionner
> est toujours préférable à aucune.

Ta solution "imparfaite mais qui peut fonctionner" n'est pas préférable
à "aucune", puisqu'il en existe une autre.
Celle de Nicolas est meilleure et je t'ai déjà expliqué pourquoi.

L'erreur sur le type du système de fichiers m'incombe. Ceci dit, la
solution déjà donnée par Nicolas ne dépend pas du filesystem. Tu veux
vraiment compter les points?

--
Nicolas S.

Ronald a écrit :
>> Dans ce cas particulier ?
>> Oui.
>
> Et comme tu es super sympa, tu vas la garder pour toi?

La réponse qui ne dépend pas du filesystem et qui n'oblige à parcourir
toute une arborescence a déjà été donnée. Tu veux quoi de plus?

--
Nicolas S.

Le Fri, 31 Aug 2007 23:20:09 +0200, Nicolas S. a écrit:

> Ronald a écrit :
>>> Dans ce cas particulier ?
>>> Oui.
>>
>> Et comme tu es super sympa, tu vas la garder pour toi?
>
> La réponse qui ne dépend pas du filesystem et qui n'oblige à parcourir
> toute une arborescence a déjà été donnée. Tu veux quoi de plus?

msgid? Parce que je ne trouve pas.

Une solution avec find, qui parcours l'arborescence?
Une autre avec zsh, imparfaite car ne fonctionne qu'avec zsh
Encore une qui ne fonctionne pas avec les fichier cachés
Et celle que j'ai donné.

ALORS?

Ronald wrote in message <pan.2007.08.31.21.28.52.831281@reply.to>:
> Une solution avec find, qui parcours l'arborescence?

Non, elle ne parcourt pas l'arborescence.

Ronald a écrit :

> msgid? Parce que je ne trouve pas.
>
> Une solution avec find, qui parcours l'arborescence?

Perdu.

--
Nicolas S.

Le Fri, 31 Aug 2007 21:31:40 +0000, Nicolas George a écrit:

> Ronald wrote in message <pan.2007.08.31.21.28.52.831281@reply.to>:
>> Une solution avec find, qui parcours l'arborescence?
>
> Non, elle ne parcourt pas l'arborescence.

J'ai vu. C'est la solution parfaite?

Le Fri, 31 Aug 2007 23:35:28 +0200, Nicolas S. a écrit:

> Ronald a écrit :
>
>> msgid? Parce que je ne trouve pas.
>>
>> Une solution avec find, qui parcours l'arborescence?
>
> Perdu.

Mais non, gagné.

condo4 :

> Toujours dans mes scripts, j'aimerai tester si des fichier existe dans
> un repertoire...

Quelque chose comme ça:

FILE_FOUND=
for f in "$DIR"/* "$DIR"/..?* "$DIR"/.[!.]*; do
if test -e "$f"; then
FILE_FOUND=t
break
fi
done

if test -z "$FILE_FOUND"; then
# $DIR est vide
else
# $DIR n'est pas vide
fi


.. En shell sh, les motifs qui ne matchent rien s'expansent en eux même, et
non en du vide comme on pourrait le penser intuitivement, donc si le
répertoire est vide, le corps de la boucle va quand même être exécuté trois
fois, et il faut alors tester si le $f correspond vraiment à un nom de
fichier.

Les trois motifs différents, c'est parce que le premier n'attrape pas les
noms de fichiers commençant par un «.», et les deux suivants servent à
attraper tous ceux qui commencent par un «.», sauf «.» et «..». (En
shell, dans un motif en «[]», la négation est un «!» et non un «^»
comme dans les expressions régulières, la plupart des shells supportent
aussi le «^», mais pas tous, je l'ai appris à mes dépens il y a quelques
mois, et c'est justement à cette occasion que j'ai découvert cette
grotesquerie.)

Ronald :

> Pour moi oui, une solution même imparfaite mais qui peut fonctionner
> est toujours préférable à aucune.

C'est vrai, à condition:
- d'être conscient des limitations de la méthode
- de bien les préciser quand on la propose à d'autres
- de vérifier qu'on est dans un cas où elle marche quand on veut la mettre
en pratique.

Comme le message où tu proposais la méthode ne vérifiait pas ces
condition, il est parfaitement normal et souhaitable qu'on te corrige.

Le Fri, 31 Aug 2007 23:31:05 +0000, Luc Habert a écrit:

> Ronald :
>
>> Pour moi oui, une solution même imparfaite mais qui peut fonctionner
>> est toujours préférable à aucune.
>
> C'est vrai, à condition:
> - d'être conscient des limitations de la méthode
> - de bien les préciser quand on la propose à d'autres
> - de vérifier qu'on est dans un cas où elle marche quand on veut la mettre
> en pratique.
>
> Comme le message où tu proposais la méthode ne vérifiait pas ces
> condition, il est parfaitement normal et souhaitable qu'on te corrige.

Oui, c'est souhaitable, mais pas normal de se voir assené des réponses
de toute autorité sans réelle explication et/ou une partie de la
contribution initiale complètement négligée, c'est dommage.

--{ Ronald a plopé ceci: }--

> Pour moi oui, une solution même imparfaite mais qui peut fonctionner
> est toujours préférable à aucune.

Une solution qui peut fonctionner est une solution
qui ne fonctionnera pas un jour ou l'autre.


--
http://tontonth.free.fr/ecoute.html (goret-coding inside)

--{ Ronald a plopé ceci: }--

> Pour moi oui, une solution même imparfaite mais qui peut fonctionner
> est toujours préférable à aucune.

Une solution qui peut fonctionner est une solution
qui ne fonctionnera pas un jour ou l'autre.


--
http://tontonth.free.fr/ecoute.html (goret-coding inside)