j'ai un script qui fait:
 

 
ca ca marche
mais le but etant de compresser le fichier plutot que de l'envoyer dans /tmp pour libere de l'espace sur le disque /var
 
je pensais faire  

 
dans l'idee mais j'obtient un fichier nome {}.tar d'ou probleme
 
si vous avez une idee...

 
je viens de passer mon aprem a ca au boulot....pas trouve de solutions...
 
pour etre + clair ce dont j'ai besoin c'est de savoir comment faire pour garder le {} du find pour m'en servir pour generer le nom de fichier.

T'as essayé un truc dans ce genre là :

à tout hasard ?

Essaie de mettre un nom de fichier générique (var_file) suivi de  
la date, voir date et heure si tu lances plusieurs fois par jours
pour certains serveurs ce script (var_file_200310211724 par
exemple).
 
Je sais comment ça peut être possible en utilisant awk, sinon ça  
doit bien être possible tout simplement avec un script shell.

 
le nomde fichier est le resultat du find obligatoirement...donc pas possible de passer dans une variable.

 
N'y a-t-il pas moyen de faire un export blabla={}.tar et ensuite
un mv {}.tar $blabla.tar ? Ou alors, si le {} marche sans le .tar  
et qu'il ne marche pas avec .tar, je pense qu'il faut qq chose
pour délimiter le {}, en tcl c justement {} autour de l'expression,
peut-être est-ce [] en shell script...

 
en script normal c'est simple mais la je peux pas scripter je suis dans un RSH !!!
c'est dingue je trouve pas moyen de le faire...
 tar a besoin de faire interpreter  le {} comme tel et pas comme caracteres { & } ce qui provoque le fichier {}.tar

 
non si tu integre des "" dans une commande find il va retourner une erreur style bad statement...

je me suis dit que je pouvait tenter gzip....

mais a cause du > find ne reconnait plus le caractere \;
 
 
 

Mes collegues et moi continuons a chercher mais on trouve pas...

c'est dans ces moments là que je suis en colère contre linux et ça Ô combien fameuse ligne de commande qui permet de tout faire ... en attendant, dès que c'est une peu "spécial", y-a plus personne pour répondre

Tux Le Penguin a écrit a écrit : c'est dans ces moments là que je suis en colère contre linux et ça Ô combien fameuse ligne de commande qui permet de tout faire ... en attendant, dès que c'est une peu "spécial", y-a plus personne pour répondre

 
en fait c'est tout a fait normal que ca puisse pas marcher puisque  
tar option PARAMETTRES liste de fichier
et {} retour du find est une liste et non un fichier (liste de longueur 1 si il y a qu'un fichier). Gzip pose aussi probleme
 
la solution est en fait simple
utiliser le compresseur standard unix  
compress qui nome de lui meme le fichier en .Z
 
rsh $SERVEUR "find /var/spool/mail -size +8196k -exec compress {} \;"
 

mais kess tu raconte ?  
 
tes { } ne sont pas escapées c donc le shell qui les interprète avant find, c'est tout ! mets les dans des " ou des ' ou escape les avec \ et ça fonctionne !

C'est marrant, mais en partant de ce que j'ai écrit plus haut, ça a l'air de marcher (à 2 ou 3 corrections près, mais c'était l'idée). Tiens, un truc qui marche comme tu as expliqué (à savoir transforme le fichier "trucmuche.bid" en "trucmuche.bid.tar" avec le find :
 

 
Pas besoin du pwd, j'y avais pas pensé. Le tar râle un peu, mais man tar devrait arranger les choses, parce qu'il met des répertoires au début. Voir du côté de l'option -P peut-être.
 

Tux Le Penguin a écrit a écrit : c'est dans ces moments là que je suis en colère contre linux et ça Ô combien fameuse ligne de commande qui permet de tout faire ... en attendant, dès que c'est une peu "spécial", y-a plus personne pour répondre

Et pourtant, la solution que j'ai donnée hier vers 17H fonctionnait presque. Tout simplement. Qu'est-ce qu'il te faut de plus que la réponse, toi ? (Admettons, ça marchait pas, il y avait juste un `pwd {}` en trop, mais à partir de là, c'était pas compliqué de trouver la solution, si ?)

Tux Le Penguin a écrit a écrit : c'est dans ces moments là que je suis en colère contre linux et ça Ô combien fameuse ligne de commande qui permet de tout faire ... en attendant, dès que c'est une peu "spécial", y-a plus personne pour répondre

Alors là vous me faites crever de rire ! vous gueulez sur la ligne de commande sans avoir eu la plus petite délicatesse de lire la man bash !
 
Vous connaissez le principe de "caractères spéciaux" ? et celui d'"échappement" de ces caractères spéciaux ?

minusplus a écrit a écrit : Alors là vous me faites crever de rire ! vous gueulez sur la ligne de commande sans avoir eu la plus petite délicatesse de lire la man bash !   Vous connaissez le principe de "caractères spéciaux" ? et celui d'"échappement" de ces caractères spéciaux ?

Ahlalala, ces jeunes ... Trop impulsifs, mais tellement plein de bonne volonté. 'faut pas que tu leur en veuilles, tu vas leur faire peur.
 
Note, j'ai jamais lu le man bash en entier, moi non plus.

non ca marche pas enfin pas assez stable un coup ca marchait un coup ca marchait pas...le test avait selectionne certain fichiers mais pas tous parmis les fichiers recquis.

minusplus a écrit a écrit : Alors là vous me faites crever de rire ! vous gueulez sur la ligne de commande sans avoir eu la plus petite délicatesse de lire la man bash !   Vous connaissez le principe de "caractères spéciaux" ? et celui d'"échappement" de ces caractères spéciaux ?

 
oui on les connait et oui on a tous (enfin dans mon equipe de boulot relu le bash et le ksh pour voir comment ca allait pouvoir passer) et toute notre equipe de'IT n'a pas trouve de solution 100% parfaite pour ce cas precis et donc pour pas perdre plus de temps on a dit stop on laisse tomber tar et on fait ca avec compress comme ca plus de probleme de selection du nom ou creer nomidentique+extention_du_compress
 
avantages syntaxique evident
compress -f truc
donne
truc.Z et non pas turc + truc.Z comme deuxieme fichier
ce qui facilitera les lectures & maintenances futures du script

Je vois pas trop le rapport entre le test et la commande, là ...

 
on a teste ta commande sur un groupe de fichier bidons
et selon leurs structures (dans le nom de fichier) ta commande fonctionne ou ne fonctionne pas.
 
en renomant les fichiers qui merdaient ca passait.
 
conclusion : le resultat de ta commande est directement depandant de la forme du nom du fichier.
 
un fichier contenant plusieurs "." & " " ne passent pas a coup sur le retour du find est > 1
donc errone en bash ca march mieux qu'en ksh mais tjrs pas a 100%
precision :
test en condition reel :
donc sous RSH $SERVEUR "......"
sur les 2 shells du reseau
bash
ksh
le probleme est surement lie a l'interpretation des '' et de {} a l'interieur de ""