j'ai un script qui déplace tous les fichiers d'un repA vers un repB.
Mon problème est que je ne veux pas déplacer les fichiers qui sont dans repA si leur taille est égale à zéro (en fait, j'aimerai pouvoir les supprimer ceux-la).
Donc actuellement, je fais:
#!/bin/bash
mv /repA/* /repB
exit 0
Je suppose qu'il faut que je fasse une boucle style "for each file" mais je ne sais pas du tout comment détecter la taille des fichiers.
Merci beaucoup d'avance.
Ma config:
Linux Debian Sarge
# find est ton ami
Posté par Babelouest (site web personnel) . Évalué à 3.
ton fichier ressemblera à ca:
[^] # Re: find est ton ami
Posté par Christophe Chailloleau-Leclerc . Évalué à 5.
On peut remplacer la boucle for par :
find /repA/ -size 0 -exec rm -f {} \;
# File
Posté par Volnai . Évalué à 1.
!/bin/bash
FILE=`echo \`file test\`| awk '{print \$2}'`
if [ "x$FILE" = "xempty" ]; then
echo "vide"
else
echo "pas vide";
fi
Bon y'a surement beaucoup mieux, mais ca doit marcher.
[^] # Re: File
Posté par Christophe Chailloleau-Leclerc . Évalué à 1.
Je profite de ce post pour poser une question à mon tour, suite à cette réponse...
Ca fait longtemps que je me demande l'intérêt du "x$toto" = "xmachin" (le x ajouté dans les deux chaînes).
Ca fait des siècles (bon, des années) que je le vois partout, et je cherche encore (pas très activement j'avoue) le problème que cela permet sans aucun doute de contourner ?
Merci d'avance !
[^] # Re: File
Posté par Obsidian . Évalué à 4.
[ = machin ]
ce qui n'est pas correct au niveau de la syntaxe. Les guillemets ne changent pas grand chose, puisqu'ils ne servent que de « directive de développement » pour indiquer au shell comment il doit interpréter les différents caractères lorsqu'il développe une expression. Ils sont également supprimés avant l'exécution.
On colle donc un "x" de chaque coté, un peu comme dans une équation algébrique :-) , pour être sûr d'avoir toujours un minimum syndical que à évaluer.
[^] # Re: File
Posté par Christophe Chailloleau-Leclerc . Évalué à 1.
J'étais persuadé que les quotes étaient conservés, et qu'une chaîne vide "" était significative, d'où mon incompréhension... Est-ce valable pour tous les shells, ou est-ce un problème relativement spécifique, mais traité systématiquement "au cas où" ?
Et dire que j'ai écrit des 100aines de lignes de shell script sans savoir ça... !
(Après, j'arrête les questions, et peut-être même que je finirais par RTFM, mais là, j'ai vraiment pas le temps (une livraison à faire ce soir, et je suis encore loin du compte :-( )
[^] # Re: File
Posté par Calim' Héros (site web personnel) . Évalué à 2.
[ "$toto" = "machin" ]
alors pourquoi le x? <ma vie> L'execution de script suivant marche tres bien chez moi au passage </ma vie> Alors je me demande, sur les shell recent ce bug n'est il pas déja corrigé?[^] # Re: File
Posté par Calim' Héros (site web personnel) . Évalué à 2.
- pkoi chez moi ca marche
- pkoi chez les autre ca marche pas
au passage, c'est une install sous gentoo (mais il me semble avoir fait la meme chose sous debian woody). Alors ne serait se pas un viel héritage dépassé?
[^] # Re: File
Posté par totof2000 . Évalué à 5.
http://groups.google.com/groups?q=+if+OR+%5B+OR+x%24+OR+%5D*+group:(...)
- utiliser [ "x$A" = "x$B" ]. Ce n'est pas necessaire pour les
shells POSIX, mais meme des shells censés etre POSIX echouent
dans certaines situation.
Au passage, je recommande fortement la lecture de ce forum (fr.comp.os.unix) à tous ceux qui veulent aprendre leshell ou progresser.
[^] # Re: File
Posté par Calim' Héros (site web personnel) . Évalué à 2.
[^] # Re: File
Posté par Christophe Chailloleau-Leclerc . Évalué à 3.
Alors, voilà le résultat de mes investigations, au taf, sur un solaris 8 (SunOS 5.8, sparc) :
Test utilise 3 fois :
if [ "$toto" = "test" ]
then
echo "1"
else
echo "0"
fi
1er cas : toto non défini
2e cas : toto=tata
3e cas : toto=test
bash : 0, 0, 1
ksh : 0, 0, 1
sh : 0,0,1
zsh : 0,0,1
csh : Le seul a râler, en effet, sur le premier test, il me dit "toto: Undefined variable", mais c'est indépendant du x ou non. De plus, même si je fais un set toto=tata, il râle sur mon script ("] Missing").
Bref, le csh, connais pas, je toucherais plus ;-)
Voila voila. Il semblerait donc que ce ne soit plus, usuellement du moins, un problème (même avec un KSH qui si j'en crois la version (cf. ci-dessous) date de 1988).
Ceci dit, ça n'empêche nullement par prudence (vieux shell chez un client, ...) de le faire.
Pour info :
bash : GNU bash, version 2.03.0(1)-release (sparc-sun-solaris)
ksh : Version M-11/16/88i ( ? obtenu avec set -o emacs puis ^V)
sh : Pas d'info
zsh : 3.0.6 (variable ZSH_VERSION)
csh : Pas d'info
[^] # Re: File
Posté par daggett . Évalué à 2.
Je connais pas non plus, mais j'en n'ai pas entendu que du bien effectivement: http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/(...) (csh programming considered harmful)
[^] # Re: File
Posté par Volnai . Évalué à 5.
# = as a test operator
if [ "$string1" = "$string2" ]
# if [ "X$string1" = "X$string2" ] is safer,
# to prevent an error message should one of the variables be empty.
# (The prepended "X" characters cancel out.)
then
command
fi
http://www.tldp.org/LDP/abs/html/ops.html(...)
[^] # Re: plus simple:
Posté par totof2000 . Évalué à 3.
for i in test1/*
do
[ -s $i ] && cp $i test2
done
Remplacer test1, test2 par des variables ...
# man bash ....
Posté par totof2000 . Évalué à 6.
Conditional expressions are used by the [[ compound command and the
test and [ builtin commands to test file attributes and perform string
and arithmetic comparisons. Expressions are formed from the following
unary or binary primaries. If any file argument to one of the pri-
maries is of the form /dev/fd/n, then file descriptor n is checked. If
the file argument to one of the primaries is one of /dev/stdin,
/dev/stdout, or /dev/stderr, file descriptor 0, 1, or 2, respectively,
is checked.
[....]
-s file
True if file exists and has a size greater than zero.
# Remerciements
Posté par Paddle . Évalué à 1.
Il ne me reste plus qu'a tester tout ça.
Merci encore,
Cordialement
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.