groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] can't translate character code 229 to special character `oa'


From: Eli Zaretskii
Subject: Re: [Groff] can't translate character code 229 to special character `oa' in transparent throughput
Date: Thu, 11 Jun 2015 18:08:30 +0300

> cc: address@hidden
> Date: Thu, 11 Jun 2015 15:18:17 +0100
> From: Ralph Corderoy <address@hidden>
> 
> > -    system("groff -Tpdf -dPDF.EXPORT=1 -mom -z $cmdstring 2>&1 | grep 
> > '^\.ds' | groff -Tpdf -mom - $preconv $cmdstring");
> > +    system("groff -Tpdf -dPDF.EXPORT=1 -mom -z $cmdstring 2>&1 | grep 
> > \"^\.ds\" | groff -Tpdf -mom - $preconv $cmdstring");
> 
> This looks wrong both times.  :-)  It's a double-quoted string in perl,
> so backslash is interpreted as an escape thus \. needlessly escapes the
> non-special dot giving just a dot and grep sees `^.ds' for the pattern
> AFAICS.
> 
>     $ perl
>     system("prargv a\.b 'a\.b' \"a\.b\" \"a\\.b\"");
>         0 '/home/ralph/bin/prargv'
>         1 'a.b'
>         2 'a.b'
>         3 'a.b'
>         4 'a\\.b'
>     $ 
> 
> #4 is what's wanted;

FWIW, I repeated this experiment on MS-Windows, using a small program
named "echoargv" instead of prargv, and I get this:

  0: `echocmd'
  1: `a.b'
  2: `'a.b''
  3: `a.b'
  4: `a\.b'

as you see, my suggestion yields in #3 exactly what you get in #2 on
Unix (which on Windows retains the single quotes, something that's
definitely not wanted).  So I submit that my suggestion was correct,
in the sense that it didn't change the semantics of its Unix original.
IOW, if there is a problem in that command, it exists on Unix as well,
and is unrelated to the change I proposed.

Am I missing something?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]