déplacer un script perl/dbm vers un nouveau serveur, et passer de dbm?

Question

J'ai été chargé de mettre en miroir un site sur un nouveau serveur. L'ancien site a quelques scripts Perl qui, pour autant que je puisse voir en interne (je ne sais rien sur Perl, bien que je comprenne assez bien le codage en général, et en particulier PHP/js/etc) ne dépendent pas de l'ancien serveur. Cela dit, quand j'essaie d'exécuter ce script, qui regarde à travers un fichier de base de données pour trouver le fichier d'article approprié, il ne récupère rien.

Fondamentalement, il s'agit d'un ancien CMS rudimentaire, comme je l'explique, où il a cherché le nom de fichier dans le fichier PAG et l'a affiché. Je suis un peu perdu ici. Y a-t-il une raison pour que la mise en miroir ne fonctionne pas sur le nouveau site? J'ai vérifié les permissions, j'ai vérifié que Perl est installé dans les mêmes répertoires /usr/etc. Je pense qu'il utilise DBM parce que, according to another article, si je vois des commandes comme celles-ci:

dbmopen(%ARTS, $art_dbm, 0644); 
$entry = $ARTS{$article_id}; 
dbmclose(%ARTS); 

il doit être DBM, non? Sur une note connexe, existe-t-il un moyen de fusionner les informations de ce fichier PAG avec les fichiers d'origine sans un script Perl incroyablement sophistiqué? c'est-à-dire, recréer les 100 fichiers texte avec cette information dans le fichier lui-même, plutôt que stockés séparément?

EDIT: merci pour la 1ère réponse ci-dessous. Pouvez-vous expliquer ce que HASH peut être, et le masque? J'ai doublechecked que le fichier .pag (le nom de la base de données) est en effet à l'endroit où il est défini plus tôt dans le fichier .pl, et qu'il a été transféré en binaire. pourtant je ne peux pas l'obtenir pour l'ouvrir correctement!

EDIT 3: Ok, désolé, montage final ici: j'ai utilisé le code de la matrice ci-dessous (Shwern) et a constaté qu'il ne trouve pas ce fichier DB, bien qu'il soit là (deux fichiers articles.pag et articles. dir, mais la variable ne fait référence qu'à des "articles" sans extensions) dans le bon répertoire et avec les bonnes permissions ... Donc, la question est maintenant de savoir ce qui se passe? sont ces différentes versions de perl? ou est-ce que je fais juste quelque chose de basique et de stupide? pour l'enregistrement (oui, c'est terrible) je n'ai pas encore d'accès shell, même si je travaille dessus ... On m'a demandé de le faire en raison de mes compétences en "new web", et je ne suis certainement pas le bon personne pour des choses comme perl et dbm, bien que je puisse lire les fichiers et les comprendre. En guise de suggestion finale, est-ce que quelqu'un sait comment (un script ou autre) je pourrais demander aux gens du serveur d'origine (qui ne sont pas les codeurs) de faire un vidage ASCII, ou serait-ce hors de propos? J'ai besoin de mettre ceci dans CSV et de nouveau dans le dossier afin que je puisse réutiliser dans un autre DB ... quel cauchemar!

Answer 1

Si je lis correctement votre question, vous rencontrez des difficultés pour ouvrir la base de données sur une nouvelle machine. La base de données existe-t-elle?

La documentation de la méthode dbmopen est disponible sur la ligne de commande via perldoc -f dbmopen (et sur ce lien pour la dernière version de perl stable, 5.10.1).

Comme vous pouvez le voir dans les documents, le deuxième argument à dbmopen contient le nom de fichier en cours d'ouverture. Dans le code que vous avez collé, cela est contenu dans la variable scalaire $art_dbm. Donc, ce que vous devez faire est de chercher une déclaration plus tôt de cette variable (peut-être qu'elle est chargée à partir d'un fichier de configuration, ou elle peut être codée en dur). Ensuite, une fois que vous avez trouvé cette base de données, tout ce qui devrait être nécessaire est de transférer ce fichier sur votre nouvelle machine.

Si vous avez besoin de plus d'aide pour déchiffrer le code, n'hésitez pas à éditer votre question avec un extrait de code et nous pouvons partir de là.

(Maintenant, si vous avez trouvé la base de données, mais vous ne pouvez pas l'ouvrir, vous avez un autre problème .. Cela fait longtemps que je traite avec des fichiers mais PAG.)

Answer 2

Avez-vous encore accès aux machines d'origine?

Bien que vous utilisiez des fichiers DBM, cette fonctionnalité peut provenir de plusieurs implémentations, dont certaines ne sont pas compatibles. Je viderais le fichier avec le même perl qui l'a créé, puis le recréerais avec le nouveau perl.

Answer 3

Il y a quelques petites choses qui pourraient mal se passer. La plus évidente est que l'appel dbmopen() n'ouvre pas le fichier. Si le fichier DBM n'existe pas, plutôt que d'échouer, dbmopen() en crée un nouveau qui pourrait être la raison pour laquelle il semble vide.

Pour éliminer cette possibilité, assurez-vous que le fichier DBM existe et est lisible. Vous voulez également vérifier si le dbmopen() a réussi, il va (habituellement) faire une erreur si c'est le mauvais format.

die "$art_dbm does not exist" unless -e $art_dbm; 
die "Cannot read $art_dbm" unless -r $art_dbm; 
dbmopen(%ARTS, $art_dbm, 0644) or die "dbmopen of $art_dbm failed: $!"; 

Malheureusement, dbmopen() est trop intelligent pour son propre bien. Si vous lui donnez "foo" il pourrait créer "foo.db" à la place. Cela dépend de la mise en œuvre. Voir ci-dessous.

L'autre possibilité est que vos deux Perls tentent d'ouvrir le fichier avec deux implémentations DBM différentes. Perl peut être compilé avec différents ensembles d'implémentations DBM sur vos différentes machines. dbmopen() utilisera le premier dans une liste codée en dur (et historique). C'est en fait une enveloppe autour de AnyDBM_File. Vous pouvez vérifier quelle implémentation est utilisée avec ...

use AnyDBM_File; 
print "@AnyDBM_File::ISA\n"; 

Assurez-vous qu'ils sont identiques. Si ce n'est pas le cas, chargez la bibliothèque DBM en question avant d'utiliser dbmopen. perldoc -f dbmopen explique.

Voici une démonstration. Nous voyons d'abord ce que dbmopen() va faire par défaut.

$ perl -wle 'use AnyDBM_File; print "@AnyDBM_File::ISA"' 
NDBM_File 

Ensuite, créez et remplissez un fichier dbm.

$ perl -wle 'dbmopen(%foo, "tmpdbm", 0644) or die $!; $foo{23} = 42; print %foo' 
2342 

Maintenant, nous pouvons le lire.

$ perl -wle 'dbmopen(%foo, "tmpdbm", 0644) or die $!; print %foo' 
2342 

Et essayez de le lire en utilisant une autre implémentation DBM.

$ perl -wle 'use GDBM_File; dbmopen(%foo, "tmpdbm", 0644) or die $!; print %foo' 

Rien dans le fichier, mais aucune erreur non plus. Il s'avère qu'il a fait un fichier appelé tmpdbm alors que ndbm utilisait tmpdbm.db. Essayons Berkeley DB.

$ perl -wle 'use DB_File; dbmopen(%foo, "tmpdbm", 0644) or die $!; print %foo' 
Inappropriate file type or format at -e line 1. 

Au moins cela donne une erreur. Le meilleur moyen est de déterminer quelle implémentation DBM utilise la machine d'origine et d'utiliser ce module avant l'appel à dbmopen(). Cela rendra la situation statique. PS L'utilitaire Unix file vous donnera également une bonne idée du type de DBM qu'il contient.

$ file tmpdbm 
tmpdbm: GNU dbm 1.x or ndbm database, little endian 
$ file tmpdbm.db 
tmpdbm.db: Berkeley DB 1.85 (Hash, version 2, native byte-order) 

Et espèrent $diety ne est pas une question d'ordre d'octet, moins fréquent maintenant que presque tout est x86. PPS Comme vous pouvez le voir, l'utilisation de fichiers DBM est un peu un gâchis. Étrange étant donné qu'il est censé être juste un hachage sur disque.