tphyahoo has asked for the wisdom of the Perl Monks concerning the following question:

Monks, maybe I am lame for calling perl from dos batch files. But I am used to dos, and use batches for testing and other stuff. (Winxp German with Active State Perl 5.8.)

Anyway, I have a situation where if I call a perl script from a dos batch file, I get one output (incorrect). If I call the same script directly from the command line, I get another output (correct). The problem is with the command line options, parsed with getopt::long, with german characters (äöüß). So, for example

perl germanCharProblems.pl -opt wordae="ärgerlich" -opt wordoe="börse" + -opt wordue="übersicht"
causes a problem when called from germanCharProblems.bat, which just contains the above line. But, it is okay straight from the command line.

I don't want to give up my ability to keep stuff in batch files, so I wrote a workaround function -- strange_dos_chars_to_germanchars -- to fix stuff passed in on the options when run from batch. Obviously, this is not a good solution. For one thing, it changes _ to ü if I have an underscore in an argument, obviously not a good thing.

I have a vague idea this *might* have something to do with the concept of perl "locale" but every time I attempt to look at the documentation on this my eyes glaze over. And it might *not* be the locale. Maybe it's activestate perl. Maybe if I tried this on cygwin it would work. Or maybe it's a windows setting?

Here's the script, to make the problem easy to isolate and reproduce:

#!perl use strict; use warnings; #cpan modules. use Getopt::Long; # Option handling ################### # GLOBAL VARS ################### # Our options my %options; # Grab the options from the command line GetOptions ("opt=s" => \%options); wipe_log(); for (keys %options) { logMessage('$options{' . "$_" . '}' . ": $options{$_} \n" ); } #outputs: #$options{wordoe}: b÷rse #$options{wordue}: ³bersicht #$options{wordae}: õrgerlich for (keys %options) { $options{$_} = strange_dos_chars_to_germanchars($options{$_}); logMessage('$options{' . "$_" . '}' . ": $options{$_} \n" ); } #outputs: #$options{wordoe}: börse #$options{wordue}: übersicht #$options{wordae}: ärgerlich # Takes a variable and spits it back out with the proper german charac +ters sub strange_dos_chars_to_germanchars { my $var = shift; my %table = ( 'ß' => '¯' , 'ä' => 'õ' , 'ö' => '÷' , 'ü' => '³' , 'Ä' => '-' , 'Ö' => 'Í' , 'Ü' => '_'); while (my ($k,$v) = each %table) { $var =~ s/$v/$k/g; } return $var; } sub wipe_log { my $logFileName = "log.txt"; open F, "> $logFileName" or die "Cannot open log file: $logFileNam +e"; close F; } sub logMessage { my $message = shift; my $message = "$message\n"; print $message; # maybe could turn this on and off with command li +ne option. do later? my $logFileName = "log.txt"; open F, ">> $logFileName" or die "Cannot open log file: $logFileNa +me"; print F $message,"\n"; close F; }
I would really, really appreciate anyone who could shed some light on this. Thanks!

thomas.

Replies are listed 'Best First'.
Re: problems with german character input in dos batch file.
by holli (Abbot) on Jan 07, 2005 at 18:13 UTC
    i encounter this often. it is because the char "ä" typed at the command line (in ascii) is not the same char typed in an editor like notepad (iso-8859-1).

    solution: use an editor that is capable of writing in plain ascii, like Textpad. Command line "edit.exe" does it too.

      Holli, thank you, that worked.

      I use jgsoft's wonderful editpad and there was a workaround there as well. When I ran "convert ansi to OEM" from the editpad menu, before saving and running the batch, it worked fine. Looked funny in editpad, but worked just as if I had run from the command line.

      Thanks again :)

Re: problems with german character input in dos batch file.
by nashr (Novice) on Jan 07, 2005 at 18:52 UTC
    Without trying to replicate this, one thing that stands out to me is your use of quotes ("). I know from experience in Windows (try using Start/Run for example) that quoted parameters are handled strangely. You might need to look into that.