Discussion :

[Nosfé]

Bonjour à tous,

J'ai besoin d'un faire un script simple pour renommer des fichiers.
Je dois me connecter à une base mysql pour récupérer des variables.

Je pensais partir sur un script en perl mais mes collègues me disent qu'un shell serait plus léger pour notre serveur, car le perl doit être compilé à chaque fois, sachant que je veux le faire tourner une fois par heure.

Le serveur est sous RedHat 7.

Un perl m'arrangerait car je trouve plus simple de se connecter à ma bdd!


Donc ma question, qu'est-ce qui est le mieux pour ce que je veux faire?

Je ne trouve rien à ce sujet, donc j'aimerais quelques avis svp!

Merci

[N_BaH]

salut,

depuis quand on compile le perl ?

moi, je suis plus à l'aise en shell, donc je le ferais en shell !

[Nosfé]

Salut!

depuis quand on compile le perl ?

Depuis que je crois tout ce qu'on me dit mais que j'ai des doutes alors je viens demander ici

Je précise que je suis novice en shell et perl.


Techniquement, pour un script qui fait la même chose, lequel serait le plus gourmand ?

[Christophe]

Pour compiler du Perl, tu peux regarder du coté de perlcc, mais je ne sais pas ce que ça vaut, et c’est expérimental. Le but premier du Perl est d'être interprété pas compilé.

L’avantage de Perl, c'est son nombre de plugins.

Au niveau perf, les deux (shell ou Perl) seront interprétés. Tu peux toujours essayer de le faire en Perl, tenter une compilation et voir si tu as une amélioration de perfs.

Perl passe par une génération de bytecode, et c'est celui-ci qui est exécuté, donc il y a effectivement une étape en plus. Mais celle-ci est elle réellement significative en temps de traitement ? Pas sûr, surtout pour des petits scripts.

Perl est un langage (interprété), un shell est un interpréteur de commande. Pour des petits scripts, la barrière entre les deux est effectivement fine. En Perl, il sera facile de trouver des fonctions dont tu as besoin fourni dans des modules, il sera facile également d'appeler des programmes externes d'administration telles que sed, awk, etc, (mais ça un shell le fera très bine aussi). Pour taper dans une base de données, ce sera plus facile avec un langage qu'avec un interpréteur de commande, mais encore une fois tu peux faire une requête sql avec l’interpréteur mysql imbriqué dans un shell. La lourdeur (dans le sens temps de traitement et utilisations de ressources) du script sera d'appeler l'interpréteur mysql. Dans un langage, tu devras de toute façon charger une bibliothèque/un module.

Si tu prends un langage (interprété également) comme Python, celui-ci garde le bytecode tant que le script n'est pas modifié (fichiers .pyc), dans le cas de la présence, d'un .pc, Python vérifie que la date du script correspond au .pyc. si c'est le cas, il l’exécute, sinon il crée ce .pyc depuis le source .py et l’exécute.

Si tu as une maitrise de Perl, ce n'est pas intéressant de changer de langage, vu qu'il va te falloir du temps pour prendre le langage en main. Si tu ne maitrises pas, c'est peut-être intéressant que tu en fasses la découverte. Ce que tu peux faire en Perl peut être fait en Python et vice-versa.

[Flodelarab]

Bonjour

• Ne pas faire faire à ton script ce que la base de données fera mieux que toi.
  Tes requêtes sql doivent être les plus complètes possibles pour limiter le post-traitement
  
• Prendre le langage où tu es le plus à l'aise.
  

  Je précise que je suis novice en shell et perl.

  Mouai. Ce n'est pas engageant.
  
  Note, toutefois, que quand tu fais un script shell, tu peux faire du perl.
  Alors que si tu fais du perl, tu ne feras plus de bash/zsh/ksh/dash/sh/csh/etc.
  
  Du coup, avec un script shell, tu peux faire du shell, grep, sed, awk, perl, python, java, etc.
  
• L'avantage du shell est de pouvoir considérer des fichiers.
  Les sorties de condition, les sorties de boucles (for, while), sont des fichiers. Et peuvent être redirigées dans des pipes.
  C'est plus propre si tu veux morceler en étapes et avoir les états intermédiaires dans des fichiers.
  Sinon, tu vas fabriquer un monolithe.

[jack-ft]

J'ai besoin d'un faire un script simple pour renommer des fichiers.
Je dois me connecter à une base mysql pour récupérer des variables.
je veux le faire tourner une fois par heure

A priori, ça n'a pas l'air très compliqué.

Si tu pouvais préciser un peu les spécifications (combien et quelles variables récupérer, quel type de renommage...), voire nous fournir l'algorithme en pseudo-code (indépendant du langage d'implémentation), du coup, les réponses fournies ici pourraient être plus précises.

[Christophe]

Note, toutefois, que quand tu fais un script shell, tu peux faire du perl.
Alors que si tu fais du perl, tu ne feras plus de bash/zsh/ksh/dash/sh/csh/etc.

Rien n'empêche d'appeler un bash ou des commandes de type sed/grep etc depuis Perl, mais ça n'a pas d’intérêt, il vaut mieux faire directement ce que l'on souhaite en Perl. Rien n'empêche d'utiliser des pipes avec Perl.

Mais pour faire un script de renommage de fichiers, j'utiliserais plutôt Bash. Ca me parait bizarre de devoir récupérer une liste de fichier à renommer depuis une base sql. A quoi sert cette base ? il doit y avoir autre chose qui l'utilise comme peut-être du PHP ? Et dans ce cas ce serais peut-être plus judicieux de faire directement le traitement depuis PHP.

[Nosfé]

Merci pour vos réponses!

J'essaie d'améliorer les sauvegardes de mon parc informatique, j'utilise Acronis qui me permet de faire un plan de sauvegarde pour plusieurs machines à la fois, mais il nomme les fichiers en commençant par le hostname de chacune.


Pour les besoin d'autres applications (que je n'ai pas développé), ces fichiers doivent commencer par le numéro d'identification de la machine.

Dans ma base mysql, j'ai la correspondance hostname / n° d'identification que je dois récupérer.


Ma requête me renvoie 1000 lignes environ.

J'espère que c'est un peu plus clair

[disedorgue]

Bonjour,
Un exemple via perl et certainement plus rapide qu'en shell...

Le répertoire contenant les fichiers à renommer:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ ls
foo.txt  xxx_a  xxx_b  xxx_c  xxx_d  xxx_e

Le fichier qui remplacera les données d'une requête mysql

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
$ cat foo.txt 
xxx_a yyy_a
xxx_b yyy_b
xxx_c yyy_c
xxx_d yyy_d
xxx_e yyy_e

Ici, le but est de renommer xxx_? par yyy_?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$ cat foo.txt | perl -ane 'rename $F[0],$F[1]'

Résultat:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ ls
foo.txt  yyy_a  yyy_b  yyy_c  yyy_d  yyy_e

Si on fait ça sur un millier de fichier via la commande mv, on chargera mille fois le contexte d'un processus mv, alors qu'en perl (ou autre python), on ne charge qu'une fois le contexte processus du perl qui traitera les mille renommage de fichier...

Bon, après, pour juste un millier de fichier, le gain de temps sera certainement perceptible mais pas plus que ça.