Discussion :

[saw-next]

bonjour tout le monde,

j'ai un problème avec mon script, j'ai un fichier C:/ERASE.TXT contenant un nombre de fichiers:

Code :

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

1
2
3
4
c:/F20081203.txt
%SystemRoot%/F20081023.txt
D:/Temp/F20090110.txt
..etc

je voudrai faire un script qui va parcourir C:/ERASE.TXT et effacer tous ces fichiers..sinon afficher un message "$fichier introuvable" si le fichier n'existe pas.

au final ça sera une chose du genre:

Code :

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

1
2
3
c:/file1.txt effacer
d:/file2.txt introuvable
..etc

voici mon code qui ne fonctionne pas

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#! perl
 
use strict; 
use warnings;
 
open my $file,"<","C:/erase.txt" or die "fichier introuvable";
 
while(my $line=<$file>)
{
  if(unlink($line) == 0) 
  {
    print "$line intouvable";
  }
  else
  {
    print "$line effacer";
  }
}

je suis sous Windows Xp

merci beaucoup

[Philou67430]

Peux-tu préciser ce qui ne marche pas... ?

Sinon, deux remarques :
- je doutes que l'interpolation des variables du shell Windows (comme %SystemRoot% se fasse correctement)
- il est sans doute préférable de chomper les noms de fichier avant unlink.

[saw-next]

Peux-tu préciser ce qui ne marche pas... ?

Bonjour et merci Philou67430, on dirai que le code ne supprime qu'un seul fichier, et le surprenant dans tout ça c'est que, quand j'appel le script une autre fois pour supprimer le fichier suivant, il ne supprime rien
J'ai essayer comme t'as dit, t'éviter l'utilisation des variables du Shell
%SystemRoot%..etc mais rien ne se passe..

merci en tout cas

[Philou67430]

Et le chomp($line) avant le if ?
Si ton fichier est de type Windows, il peut aussi être utile de définir le séparateur de ligne avec "\r\n" en début de programme :

Code :

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

$/ = "\r\n";

[saw-next]

Et le chomp($line) avant le if ?
[/CODE]

Merci Philou67430,

problème résolu, c'était juste le chomp

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
#! perl
 
use strict; 
use warnings;
 
 
open my $file,"<","erase.txt" or die "fichier introuvable";
 
while(my $line=<$file>)
{
  chomp($line);
 
  if(unlink($line) == 0) 
  {
    print "$line intouvable\n";
  }
  else
  {
    print "$line effacer\n";
  }
}

avec: contenu du fichier erase.txt

Code :

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

1
2
3
c:\file test.txt
D:\dossier\file.tmp
..etc

il peut aussi être utile de définir le séparateur de ligne avec "\r\n" en début de programme :
[CODE]$/ = "\r\n";

j'ai pas compris

@+

[Philou67430]

Je ne connais pas la valeur par défaut de ton $/, ni comment se termine tes lignes dans ton fichier, c'est pourquoi je t'ai proposé de modifier sa valeur.

Pour comprendre, lire :
perldoc perlvar (chercher la variable $/).

[Jedai]

Si ton fichier est de type Windows, il peut aussi être utile de définir le séparateur de ligne avec "\r\n" en début de programme :

Code :

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

$/ = "\r\n";

S'il est sous Windows, il ne faut surtout pas qu'il redéfinisse ainsi $/ : le mode de lecture texte, qui est le défaut sous Windows traduit automatiquement les \r\n en \n en entrée et les \n en \r\n à l'écriture.

--
Jedaï

[Philou67430]

Sauf s'il est sous XP/Cygwin installé avec l'option fichier texte Unix

[saw-next]

perldoc perlvar (chercher la variable $/).

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
>> perldoc perlvar | find "$/"


        local $/; # enable localized slurp mode
        undef $/; # enable slurp mode
    executed, the global value of $/ is now changed for any other code
            local $/;
            been read from it. (Depending on the value of $/, Perl's idea of
    $/      The input record separator, newline by default. This influences
                local $/;           # enable "slurp" mode
            Remember: the value of $/ is a string, not a regex. awk has to
            Setting $/ to a reference to an integer, scalar containing an
                local $/ = \32768; # or \"32768", or \$var_containing_32768
            at the end of the print. Also, it's just like $/, but it's what
                      unless $this_perl =~ m/$Config{_exe}$/i;}
                      unless $secure_perl_path =~ m/$Config{_exe}$/i;}

par contre j'ai un autre problème:
exemple de fichier que le script ne peut pas supprimer

Code :

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

D:\Documents and Settings\Administrateur\Bureau\dod.txt

es-ce un problème de chemins long ?

==> Je n'ai pas Cygwin


@+

[Philou67430]

Je pencherais plus pour des problèmes de droit (et en second lieu pour des espaces dans le nom, bien que je pense que ce soit correctement traité par défaut).

[Jedai]

Sauf s'il est sous XP/Cygwin installé avec l'option fichier texte Unix

Dans ce cas je lui souhaite bien du plaisir... (Je suis très fortement défavorable à l'utilisation du Perl de Cygwin, je préfère largement les solutions natives comme Active Perl ou Strawberry Perl)

--
Jedaï

[Philou67430]

Y a-t-il une FAQ, ou une quelconque page qui liste les inconvénients de perl sous Cygwin, car j'avoue n'utiliser que cela, et je ne rencontre que de rares problèmes ?
Je précise que je n'utilise pas de GUI (même si Tk est dispo), ni de programmation Win32... dans ces contextes particuliers, je suis d'accord avec ton analyse. Pour le traitement de texte en général, la programmation réseau, la programmation système, ... je n'ai pas vu de problème majeur (ou de problème tout court). J'avais même écrit une application de test qui tournait sans problème sur Solaris et WinXP/cygwin (bien sur, cela ne fait pas une généralité).

[Jedai]

Et bien tu as déjà un petit exemple de problème ci-dessus. D'un autre côté mon expérience avec Cygwin date un peu maintenant, mais il y avait tout un tas de petits problèmes de compatibilité entre le Perl de Cygwin et Windows, il n'était pas toujours évident de récupérer certains modules avec une composante XS également, j'ai pratiquement toujours eu plus de succès à compiler ces modules avec une chaîne à base de Mingw et ActivePerl, les modules qui s'attendaient à se trouver sous Unix s'installaient souvent sans problèmes sur le Perl de Cygwin mais se heurtaient ensuite aux petites différences entre Cygwin et un vrai Unix, etc...
En fait ma critique s'applique à l'ensemble de Cygwin, je conserve toujours un cygwin sur mes installations de Windows, mais autant que possible, je préfère utiliser les adaptations Windows natives des applications Linux, lorsqu'elles existent. (Et je préfère encore un vrai Linux bien sûr, ces jours ci je ne travaille plus trop sous Windows pour être honnête)

Disons que tant qu'à être sous Windows je préfère travailler vraiment sous Windows, pas dans un ersatz imparfait d'Unix.

Je t'accorderais qu'il y a une part importante de préférence personnelle dans cet argument.
--
Jedaï

[saw-next]

bonjour les gars

alors est-ce que le problème de chemins dans les fichiers n'a pas de solution !

merci beaucoup

[Philou67430]

Merci pour ce retour Jedai... en fait, j'utilise Cygwin depuis très longtemps, et j'avoue qu'il s'est bien amélioré. En fait, je ne peux plus me passer de bash, find et grep, uniq, sort et diff ... du coup, comme tout est dispo, c'est vraiment plus simple que des outils indépendant.
En plus, il y a le serveur X.
Je ne veux pas dire que cygwin est la panacée, mais il fonctionner qu'en même assez bien. Très rares sont les modules qui ne s'installent pas avec cpan (Bioperl, mais j'ai entendu dire que c'était pareil avec n'importe quel perl).

Concernant les fins de fichier, je doute que la solution native règle mieux les problèmes que la version cygwin : en fait, lorsque tu manipules des fichiers hétérogènes, le problème refait sans doute surface : des fichiers Unix sous Windows et inversement. Lorsque je travaillais sur des plateformes Windows ET Solaris, j'ai été confronté au problème, et la solution était bien souvent un dos2unix préalable.