script de sauvegarde - Page 1

voilà, je suis en train de dev un projet assez long, et je voudrai faire un petit script qui permet quand je l'execute de faire un tar.gz d'un repertoire en le nommant: nom_du_rep_date_heure.
en gros: j'ai un repertoire projet:
$ ls
>projet/
$ sauvegarde projet
>sauvegarde effectuée
$ ls
>projet/ projet_17/05/04_23h21.tar.gz

c'est possible facilement? je connais aucun langage de script, et je veux pas forcement en apprendre un ,c juste qu'un script comme celui la me serai fort utile. merci.

en fait je pourai me debrouille seul si je savais enregistrer la date dans une variable (script sh):
i= date +%D ne marche pas

$ tar czf projet_`date +%d-%m-%y_%Hh%M`.tar.gz projet/
J'ai enlevé les "/" dans le nom, sachant que c un indicateur de repertoires, c moyen...
Je te conseille d'ailleur plutot :
$ tar czf projet_`date +%y-%m-%d_%Hh%M`.tar.gz projet/
Comme ça, tes différentes sauvegardes seront rangées par ordre chronologique

Ué et tu rajoutes ça dans ton makefile et voilà ^^

ok merci bcp

Et un pti cron histoire que ca se fasse tout seul régulièrement, avec une mini gestion de versioning, et c'est nickel.

Genre hummm (fait a la volée de mémoire et sans rien pour tester, pas garantie que ca marche et y doit manquer pas mal de trucs)

#!/usr/bin/perl

my $rep_sauv = "~/svg/projet/";
my $rep_travail = "~/projet";
my $nom_sav = "sauv_projet";
my $time = localtime[3] ."-". localtime[4] . "-" . localtime[5];
#pas garantie que ce soit les bons choix pour la date, a verif.

system("tar czf " . $rep_sauv . $nom_sav . "_" . $time . ".tar.gz " . $rep_travail);
#après, faire un coup de diff, pour voir si ca a changé (alors là, je donne pas les lignes à faire, c'est vaguement plus long, si tu les veux, dis-le moi )

et hop, tout ca dans l'crontab.

PS : c'est pareil que guilc, mais avec tu peux mettre des trucs marrants, et pareil que Bihi, mais là, les sauvegardes se font toutes seules

Juste une question : Pourquoi utiliser la machinerie perl alors que ce qu tu fais en perl peut se faire avec un simple script shell, de manière plus légère ? (et aussi facile a cronner)

Perl c'est très bien, mais bash semble vraiment plus adapté a un script aussi simple, ou aucune des fonctionnalités propre perl n'est utilisée...

Oui, je sais, mais si je sors la machinerie perl, c'est parce que je pensais à des trucs à faire en plus derrière, que j'ai abandonné après, probleme de "j'ai un cours dans 30 secondes".

Oui, on peut faire mieux en bash, évidemment.

bof, c pas vraiment plus lourd... et souvent on se retrouve à faire des "sed -e" ou des "perl -pe" dans les scripts shell

hmm par contre petit pb, en Perl, comment on échappe proprement les arguments pour les passer à un shell ? par exemple le truc de kim peut poser des gros pbs s'il y a des espaces dans les noms de fichiers... y a tjs la solution de forker, de rediriger les file descriptors comme il faut et de faire un "exec", mais y a pas plus efficace ?

system("tar czf \"${rep_sauv}${nom_sav}_${time}.tar.gz\" \"$rep_travail\"");

eh non... ça ne marche pas s'il y a des quotes ou des dollars par exemple...

comme solution barbare, je vois

sub escape {
  my ($x)=@_;
  $x=~s/'/'"'"'/g;
  return "'$x'";
}

system("tar czf ".escape($rep_sauv).escape($nom_sauv)."_".escape($rep_sauv).".tar.gz ".escape($rep_travail));

mais c'est assez lourd...

hum...
system("tar czf '${rep_sauv}${nom_sav}_${time}.tar.gz' '$rep_travail'");
et là ?

si tu ne mets pas de guillemets autour, ça marche presque : ça marche avec les espaces, $, |, >, mais ça foire à moitié avec les \n ... (il sont sauvagement supprimés)

parce que \n en shell c'est la continuation de ligne...

yup et y en a d'autres ou pas ?

sub my_system {
  $_[0] =~ s/\\n/\$'\n'/g;
  return system(shift);
}

my_system("tar czf \Q${rep_sauv}${nom_sav}_${time}.tar.gz\E \Q$rep_travail\E");

peut-etre comme ça ?

Moué, c'est vrai que c'est un peu mieux... Et comment on fait pour en fait un "list operator" ? (pour pas avoir besoin de parenthèses #flemme#)

Et \$'\n' est du sh normal (et d'ailleurs c probable qu'il manque un \) J'aurais plutôt dit '\n' tout court...

Pollux
: Et comment on fait pour en fait un "list operator" ? (pour pas avoir besoin de parenthèses #flemme#)

Bonne question.

Et \$'\n' est du sh normal (et d'ailleurs c probable qu'il manque un \) J'aurais plutôt dit '\n' tout court...

Il ne manque pas de '\', mais ce n'est pas du sh standard apparemment (en tout cas le sh de NetBSD n'en veut pas).
Et '\n' tout court exécute la commande d'avant, et commence une nouvelle commande.

mes apostrophes étaient à prendre comme des apostrophes littérales, pas comme des délimiteurs... Donc <string> '\n' </string> ne marcherait pas ?

ok. sans \$ ça a l'air de marcher.

Attend, pourquoi tu veux qu'un nom de fichier ait un espace (déjà, c'est débile de mettre des espaces dans les noms de fichiers) ou un saut de ligne ...



PS : que veux-tu dire par "list operator" ?

kim
: Attend, pourquoi tu veux qu'un nom de fichier ait un espace (déjà, c'est débile de mettre des espaces dans les noms de fichiers) ou un saut de ligne ...

1. Parce que c'est possible.
2. Parce que c'est très courant dès que t'es sur un filesystem qui vient de Windows, Mac OS, etc...

1. oui mais c'est ce que j'appelle une incongruité fondamentale ... est-ce qu'on autorise des \n ou des \0 dans les noms de fichiers ? non. L'espace n'est pas un caractère visible et peut etre confondu par l'espace insécable, donc ce n'est pas un bon choix pour l'utiliser dans un nom de fichier. (Bouuuuuuuuh windows ! Pour macos je sais pas ...)
2. Oui, c'est pour ça qu'il faut éviter de travailler sur un espace de travail sous windows. Au pire :
ln -s /mnt/win/Program\ Files /mnt/ProgramFiles
ln -s /mnt/win/Documents\ And\ Settings/monlogin/Mes\ Documents ~/docs_win

et basta, a pu d'espace inutiles

nitro>
vi... et c'est aussi une grosse faille de sécurité si tu exécutes un script avec des données potentiellement "hostiles"...

et "list operator" = tu as le droit d'écrire "print 1,2,3;", alors que si ct pas un list operator ce serait équivalent à "print() 1,2,3;"
mais en fait après essai c'est le cas par défaut pour toutes les fonctions utilisateur, donc pas de pb

Oui aussi.

Et pour le list operator, il me semble en effet que print 1,2,3; passe. Personnellement, je ne fais jamais ce genre d'opérations : je préfère travailler directement avec des listes de variables ou des hashs, et derrière, j'utilise join pour avoir un format sûr, et j'essaye de vérifier le format des variables au mieux.


PS : un truc intéressant sur les failles du genre espace et tout ...
http://www.security-labs.org/index.php3?page=124
Les autres articles sont intéressants aussi.

kim> des \n oui, des \0 non... un nom de fichier, sous Unix, et que tu le veuilles ou non, c'est une chaîne de caractères binaire quelconque terminée par un 0 (d'ailleurs, ça pose des pbs de locale, hmm )

Pour ce qui est du "bouh windows", c'est un peu déplacé : c'est juste que les interfaces graphiques permettent des choses plus subtiles que des espaces pour séparer des fichiers dans une liste, donc que c'est pas un pb de mettre des espaces dans le nom (c'est même plus lisible )

Et pour les symlinks, c'est généralement ce que je fais sous cygwin (surtout qu'il y a pas mal de progs écrits avec les pieds qui supposent justement qu'il y a pas d'espaces dans le nom de fichier).

kim> oui, "print 1,2,3" passe évidemment, mais je voulais que "my_print 1,2,3" passe (ce qui a l'air d'être le cas)

Et comment ça "je ne fais jamais ce genre d'opérations" ? Ca ne t'arrive jamais de passer des params de nature différente (donc pas regroupable dans un même tableau) à une fonction ?

je déréférence beaucoup ce qui évite parfois des petits soucis, et il ne m'ait pas arrivé depuis longtemps de passer des paramètres de nature différente à une fonction (de mémoire ... jamais)

#pipo#

open(FILE,"file"), ça ne t'arrive jamais ?

Si, mais ca, je met les parenthèses, pas habitude, alors j'y fais même plus attention
Merci de me rappeler ces fonctions que j'utilise sans m'en rendre compte.

(ps : on doit pouvoir ouvrir un fichier dans le open ... sysopen non ? -de mémoire- je sais plus comment il marche celui là)