Skip Menu |
 

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Pod-Simple CPAN distribution.

Report information
The Basics
Id: 91805
Status: rejected
Priority: 0/
Queue: Pod-Simple

People
Owner: Nobody in particular
Requestors: waterlan [...] xs4all.nl
Cc: RRA [...] cpan.org
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



CC: twaugh [...] fedoraproject.org
Subject: pod2man fails on Latin-1 POD file without =encoding command.
Date: Thu, 02 Jan 2014 22:14:37 +0100
To: bug-podlators [...] rt.cpan.org
From: Erwin Waterlander <waterlan [...] xs4all.nl>
Hi, I'm the maintainer of dos2unix (http://waterlan.home.xs4all.nl/dos2unix.html), and I got a report from RedHat that dos2unix fails to compile on Rawhide (the bleeding edge distribution), because of pod2man. Dos2unix uses POD files for documenation. I have two POD files (in Dutch and Spanish) encoded in ISO8859-1. I deliberately did not add =encoding commands, because the =encoding command was introduced in perl 5.10, and there are many older perl versions around. Perl 5.8 is still used a lot. RedHat Rawhide uses perl 5.18.1 and this is the error message: *** ERROR: Non-ASCII character seen before =encoding in 'België'. Assuming ISO8859-1 at line 506 in file ../nl/man1/dos2unix.pod ../nl/man1/dos2unix.pod has 1 pod syntax error. make[1]: *** [../nl/man1/dos2unix.1] Error 1 There are indeed non-ASCII characters in this file, namely ISO8859-1 characters. Pod2man assumes ISO8859-1 when there is no =encoding command, so I think that this error should not happen. best regards, Erwin Waterlander
Subject: Re: [rt.cpan.org #91805] pod2man fails on Latin-1 POD file without =encoding command.
Date: Thu, 02 Jan 2014 13:24:17 -0800
To: bug-podlators [...] rt.cpan.org
From: Russ Allbery <rra [...] cpan.org>
Download (untitled) / with headers
text/plain 2.2k
"waterlan via RT" <bug-podlators@rt.cpan.org> writes: Show quoted text
> I'm the maintainer of dos2unix > (http://waterlan.home.xs4all.nl/dos2unix.html), and I got a report from > RedHat that dos2unix fails to compile on Rawhide (the bleeding edge > distribution), because of pod2man.
Show quoted text
> Dos2unix uses POD files for documenation. I have two POD files (in Dutch > and Spanish) encoded in ISO8859-1.
Show quoted text
> I deliberately did not add =encoding commands, because the =encoding > command was introduced in perl 5.10, and there are many older perl > versions around. Perl 5.8 is still used a lot.
Show quoted text
> RedHat Rawhide uses perl 5.18.1 and this is the error message:
Show quoted text
> *** ERROR: Non-ASCII character seen before =encoding in 'België'. > Assuming ISO8859-1 at line 506 in file ../nl/man1/dos2unix.pod > ../nl/man1/dos2unix.pod has 1 pod syntax error. > make[1]: *** [../nl/man1/dos2unix.1] Error 1
Show quoted text
> There are indeed non-ASCII characters in this file, namely ISO8859-1 > characters. Pod2man assumes ISO8859-1 when there is no =encoding > command, so I think that this error should not happen.
The warning in this case comes from Pod::Simple. pod2man doesn't have any control over the warning itself. Pod::Simple really wants you to use =encoding and produces an unconditional warning in current versions if it has to guess. pod2man uses Pod::Simple in all newer versions of Perl, and is just passing along that warning. The workaround that works with every version of Perl is to replace all non-ASCII characters with appropriate E<> codes. Another approach that would at least fix your build is to add --errors=stderr to the pod2man invocation. Unfortunately, though, you'd need to probe whether pod2man supports that command-line option, since it was only added relatively recently. (But any version that doesn't have that command-line option will also not fail on errors.) I'm surprised that =encoding didn't work with Perl 5.8. I thought it had been around for longer than that. -- #!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker $^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD, 00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{ rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
Subject: Re: [rt.cpan.org #91805] pod2man fails on Latin-1 POD file without =encoding command.
Date: Fri, 03 Jan 2014 03:04:43 +0100
To: bug-podlators [...] rt.cpan.org
From: waterlan <waterlan [...] xs4all.nl>
Download (untitled) / with headers
text/plain 1.4k
Russ Allbery via RT schreef op 2014-01-02 22:24: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=91805 > > > "waterlan via RT" <bug-podlators@rt.cpan.org> writes: > > > The warning in this case comes from Pod::Simple. pod2man doesn't have > any > control over the warning itself. Pod::Simple really wants you to use > =encoding and produces an unconditional warning in current versions if > it > has to guess. pod2man uses Pod::Simple in all newer versions of Perl, > and > is just passing along that warning.
The POD specification says that the default encoding assumed is Latin-1. It is even part of the warning. So I don't understand why I get an error. This is a bug. Pod:Simple should not guess. Show quoted text
> > The workaround that works with every version of Perl is to replace all > non-ASCII characters with appropriate E<> codes. Another approach that > would at least fix your build is to add --errors=stderr to the pod2man > invocation. Unfortunately, though, you'd need to probe whether pod2man > supports that command-line option, since it was only added relatively > recently. (But any version that doesn't have that command-line option > will also not fail on errors.)
The E<> codes sound interesting. Although I think that this new behaviour is a bug, and should be fixed. Where can I find a list of E<> codes? Show quoted text
> > I'm surprised that =encoding didn't work with Perl 5.8. I thought it > had > been around for longer than that.
-- Erwin Waterlander http://waterlan.home.xs4all.nl/
Subject: Re: [rt.cpan.org #91805] pod2man fails on Latin-1 POD file without =encoding command.
Date: Thu, 02 Jan 2014 18:50:10 -0800
To: bug-podlators [...] rt.cpan.org
From: Russ Allbery <rra [...] cpan.org>
Download (untitled) / with headers
text/plain 1.8k
"waterlan via RT" <bug-podlators@rt.cpan.org> writes: Show quoted text
> The POD specification says that the default encoding assumed is Latin-1.
It's actually somewhat more complicated than that. From perlpodspec: * Since Perl recognizes a Unicode Byte Order Mark at the start of files as signaling that the file is Unicode encoded as in UTF-16 (whether big-endian or little-endian) or UTF-8, Pod parsers should do the same. Otherwise, the character encoding should be understood as being UTF-8 if the first highbit byte sequence in the file seems valid as a UTF-8 sequence, or otherwise as Latin-1. Oh, I see the pod2man documentation is wrong. I'll fix that. Show quoted text
> It is even part of the warning. So I don't understand why I get an > error. This is a bug. Pod:Simple should not guess.
Well, I can reassign this bug to the Pod-Simple distribution if you'd like. Pod::Simple has recently gotten somewhat more aggressive about warnings in an attempt to get people to clean up POD that's ambiguous, and I suspect this might be part of that. Show quoted text
> The E<> codes sound interesting. Although I think that this new > behaviour is a bug, and should be fixed. Where can I find a list of E<> > codes?
See perlpod (search for "a character escape"). It's either an HTML entity name or the numeric code for a Unicode character. You probably already know this, but just in case: pod2man by default will butcher your non-ASCII characters due to old, old legacy issues with *roff. This will be changed in an upcoming release, but in the meantime, you probably want -u. (I'm guessing that's what you're already doing.) -- #!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker $^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD, 00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{ rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
Subject: Re: [rt.cpan.org #91805] pod2man fails on Latin-1 POD file without =encoding command.
Date: Fri, 03 Jan 2014 10:11:17 +0100
To: bug-podlators [...] rt.cpan.org
From: waterlan <waterlan [...] xs4all.nl>
Download (untitled) / with headers
text/plain 3.3k
Russ Allbery via RT schreef op 2014-01-03 03:50: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=91805 > > > "waterlan via RT" <bug-podlators@rt.cpan.org> writes: >
>> The POD specification says that the default encoding assumed is >> Latin-1.
> > It's actually somewhat more complicated than that. From perlpodspec: > > * Since Perl recognizes a Unicode Byte Order Mark at the start of > files as signaling that the file is Unicode encoded as in > UTF-16 > (whether big-endian or little-endian) or UTF-8, Pod parsers > should > do the same. Otherwise, the character encoding should be > understood as being UTF-8 if the first highbit byte sequence in > the > file seems valid as a UTF-8 sequence, or otherwise as Latin-1. > > Oh, I see the pod2man documentation is wrong. I'll fix that. >
>> It is even part of the warning. So I don't understand why I get an >> error. This is a bug. Pod:Simple should not guess.
> > Well, I can reassign this bug to the Pod-Simple distribution if you'd > like. Pod::Simple has recently gotten somewhat more aggressive about > warnings in an attempt to get people to clean up POD that's ambiguous, > and > I suspect this might be part of that.
It would be my preference that Pod:Simple was less aggressive about latin1. If you now are going to change the pod2man documentation and start demanding an =encoding command for latin1, then in my opinion you are breaking backward compatibility. As perl 5.18 will spread, I will get more bug reports. Show quoted text
>
>> The E<> codes sound interesting. Although I think that this new >> behaviour is a bug, and should be fixed. Where can I find a list of >> E<> >> codes?
> > See perlpod (search for "a character escape"). It's either an HTML > entity > name or the numeric code for a Unicode character.
OK. Thanks. Show quoted text
> > You probably already know this, but just in case: pod2man by default > will > butcher your non-ASCII characters due to old, old legacy issues with > *roff. This will be changed in an upcoming release, but in the > meantime, > you probably want -u. (I'm guessing that's what you're already doing.)
I know -u, but I use it only for non-Latin1 scripts. I want to stay as much as possible compatible with old perl versions. One reason is that my program is also compiled on Windows and even DOS. There the perl versions are many versions behind, mostly at 5.8 (MSYS, DJGPP). Another important reason is that inside many business corporations people are very conservative about upgrading. Perl 5.8 is still used a lot on Unix and Linux inside businesses. Big corporations often have many versions of software packages installed in parallel and default to an old stable version. When people bounce on a POD syntax error they mostly don't know what to do. By using Latin1 encoding for the latin1 scripts, and no =encoding command, I'm compatible with old perl versions. For non-Latin1 scripts I include the pod2man produced man pages in the source package. Now with the new perl 5.18 coming this seems also my best option for Latin-1 scripts to avoid trouble. I'm wondering how many other packages, besides perl itself, are using POD for documentation. It feels like I'm the only one. At least for non-English languages. I don't see many people translate there manuals. regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/
Subject: Re: [rt.cpan.org #91805] pod2man fails on Latin-1 POD file without =encoding command.
Date: Fri, 03 Jan 2014 10:45:31 +0100
To: bug-podlators [...] rt.cpan.org
From: waterlan <waterlan [...] xs4all.nl>
Download (untitled) / with headers
text/plain 3.8k
waterlan schreef op 2014-01-03 10:11: Show quoted text
> Russ Allbery via RT schreef op 2014-01-03 03:50:
>> <URL: https://rt.cpan.org/Ticket/Display.html?id=91805 > >> >> "waterlan via RT" <bug-podlators@rt.cpan.org> writes: >>
>>> The POD specification says that the default encoding assumed is >>> Latin-1.
>> >> It's actually somewhat more complicated than that. From perlpodspec: >> >> * Since Perl recognizes a Unicode Byte Order Mark at the start >> of >> files as signaling that the file is Unicode encoded as in >> UTF-16 >> (whether big-endian or little-endian) or UTF-8, Pod parsers >> should >> do the same. Otherwise, the character encoding should be >> understood as being UTF-8 if the first highbit byte sequence >> in the >> file seems valid as a UTF-8 sequence, or otherwise as Latin-1. >> >> Oh, I see the pod2man documentation is wrong. I'll fix that. >>
>>> It is even part of the warning. So I don't understand why I get an >>> error. This is a bug. Pod:Simple should not guess.
>> >> Well, I can reassign this bug to the Pod-Simple distribution if you'd >> like. Pod::Simple has recently gotten somewhat more aggressive about >> warnings in an attempt to get people to clean up POD that's ambiguous, >> and >> I suspect this might be part of that.
> > It would be my preference that Pod:Simple was less aggressive about > latin1. > > If you now are going to change the pod2man documentation and start > demanding an =encoding command for latin1, then in my opinion you are > breaking backward compatibility. As perl 5.18 will spread, I will get > more bug reports. >
>>
>>> The E<> codes sound interesting. Although I think that this new >>> behaviour is a bug, and should be fixed. Where can I find a list of >>> E<> >>> codes?
>> >> See perlpod (search for "a character escape"). It's either an HTML >> entity >> name or the numeric code for a Unicode character.
> > OK. Thanks.
I have looked at E<> codes, but I'm not going to use them. First of all, the main reason why I switched from ROFF to POD is that I don't want to burden translators with complicated syntaxes. Translators are often not programmers, so it is easiest if they work with 'normal' text. Using escape sequences will scare them off. Second the E<> codes don't work in a verbatim block. Show quoted text
>
>> >> You probably already know this, but just in case: pod2man by default >> will >> butcher your non-ASCII characters due to old, old legacy issues with >> *roff. This will be changed in an upcoming release, but in the >> meantime, >> you probably want -u. (I'm guessing that's what you're already >> doing.)
> > I know -u, but I use it only for non-Latin1 scripts. > I want to stay as much as possible compatible with old perl versions. > One reason is that my program is also compiled on Windows and even > DOS. There the perl versions are many versions behind, mostly at 5.8 > (MSYS, DJGPP). > Another important reason is that inside many business corporations > people are very conservative about upgrading. Perl 5.8 is still used a > lot on Unix and Linux inside businesses. Big corporations often have > many versions of software packages installed in parallel and default > to an old stable version. > > When people bounce on a POD syntax error they mostly don't know what to > do. > > By using Latin1 encoding for the latin1 scripts, and no =encoding > command, I'm compatible with old perl versions. For non-Latin1 scripts > I include the pod2man produced man pages in the source package. Now > with the new perl 5.18 coming this seems also my best option for > Latin-1 scripts to avoid trouble. > > > I'm wondering how many other packages, besides perl itself, are using > POD for documentation. It feels like I'm the only one. At least for > non-English languages. I don't see many people translate there > manuals. > > regards,
-- Erwin Waterlander http://waterlan.home.xs4all.nl/
Subject: Re: [rt.cpan.org #91805] pod2man fails on Latin-1 POD file without =encoding command.
Date: Fri, 03 Jan 2014 10:03:00 -0800
To: bug-podlators [...] rt.cpan.org
From: Russ Allbery <rra [...] cpan.org>
Download (untitled) / with headers
text/plain 3.3k
"waterlan via RT" <bug-podlators@rt.cpan.org> writes: Show quoted text
> It would be my preference that Pod:Simple was less aggressive about > latin1.
I'll reassign the bug. Show quoted text
> If you now are going to change the pod2man documentation and start > demanding an =encoding command for latin1, then in my opinion you are > breaking backward compatibility.
Well, I understand how you feel, but this is not something under my control unless I intend to diverge behavior from all other POD processing modules in Perl. All Pod::Simple clients work the same. All that my change to the documentation achieves is that the documentation will now be accurate about how the guessing mechanism works instead of wrong. Show quoted text
> I know -u, but I use it only for non-Latin1 scripts.
pod2man will butcher non-ASCII Latin-1 scripts if you process them without -u. This has been the case for basically forever, back to when Tom Christiansen was maintaining it. The output without -u is basically wrong for nroff (although compatible with very old *roff implementations). It makes an attempt at producing correct results for groff, but to a first approximation no one uses groff any more. My intent in the future is to change pod2man to start producing UTF-8 by default, since this is what most modern man implementations now expect, and continuing to butcher people's names in man pages feels rude. I suspect most (possibly all) modern *roff implementations will cope with UTF-8 input now, or at least won't produce any worse output than the current output. Show quoted text
> I want to stay as much as possible compatible with old perl versions. > One reason is that my program is also compiled on Windows and even DOS. > There the perl versions are many versions behind, mostly at 5.8 (MSYS, > DJGPP).
If you want the documentation to build in those environments, I would use E<>. That's what I did with all of my own POD documentation of that vintage. Show quoted text
> By using Latin1 encoding for the latin1 scripts, and no =encoding > command, I'm compatible with old perl versions. For non-Latin1 scripts I > include the pod2man produced man pages in the source package. Now with > the new perl 5.18 coming this seems also my best option for Latin-1 > scripts to avoid trouble.
I do this myself, and I think it's a good idea. I understand the desire to build everything in the distribution from source, but newer versions of pod2man produce considerably better output, which means that you'll be doing your users a favor by including versions built with newer versions of Perl. Show quoted text
> I'm wondering how many other packages, besides perl itself, are using > POD for documentation. It feels like I'm the only one.
Tons. Most of my bug reports are from people who are using POD for things other than Perl, and all of my own packages, in whatever programming language, are documented with POD. Show quoted text
> At least for non-English languages. I don't see many people translate > there manuals.
That's true. Translating a full manual is a ton of work. I only know of a few projects that have put in the effort, and it's a never-ending task to try to keep the non-English manuals up-to-date. -- #!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker $^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD, 00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{ rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
Subject: Re: [rt.cpan.org #91805] pod2man fails on Latin-1 POD file without =encoding command.
Date: Fri, 03 Jan 2014 10:03:51 -0800
To: bug-podlators [...] rt.cpan.org
From: Russ Allbery <rra [...] cpan.org>
Download (untitled) / with headers
text/plain 908b
"waterlan via RT" <bug-podlators@rt.cpan.org> writes: Show quoted text
> I have looked at E<> codes, but I'm not going to use them. First of all, > the main reason why I switched from ROFF to POD is that I don't want to > burden translators with complicated syntaxes. Translators are often not > programmers, so it is easiest if they work with 'normal' text. Using > escape sequences will scare them off.
Ah, yes, if you're dealing with a full translated page, E<> is kind of a mess. You could automatically convert, but meh. Show quoted text
> Second the E<> codes don't work in a verbatim block.
Oh, yes, that's true, and probably unsurmountable. -- #!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker $^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD, 00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{ rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
Download (untitled) / with headers
text/plain 596b
Pod::Simple maintainers, The problem reported here is the warning generated by Pod::Simple if it has to autodetect encoding. This combines with pod2man's policy, as requested by perl5-porters, to error if there are syntax problems, rather than adding a POD ERRORS section or writing to standard error where it may just get lost in build logs. The result is that there aren't good solutions for writing POD files that are majority-non-ASCII in a way that's backward-compatible to pre-Pod::Simple pod2man. I'm not sure there's any good solution here, but forwarding the bug to you as requested.
Subject: Re: [rt.cpan.org #91805] pod2man fails on Latin-1 POD file without =encoding command.
Date: Fri, 03 Jan 2014 23:14:01 +0100
To: bug-podlators [...] rt.cpan.org
From: waterlan <waterlan [...] xs4all.nl>
Download (untitled) / with headers
text/plain 2.8k
Russ Allbery via RT schreef op 2014-01-03 19:03: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=91805 > > > "waterlan via RT" <bug-podlators@rt.cpan.org> writes: >
>> It would be my preference that Pod:Simple was less aggressive about >> latin1.
> > I'll reassign the bug.
Thanks. Show quoted text
>> I know -u, but I use it only for non-Latin1 scripts.
> > pod2man will butcher non-ASCII Latin-1 scripts if you process them > without > -u. This has been the case for basically forever, back to when Tom > Christiansen was maintaining it. The output without -u is basically > wrong > for nroff (although compatible with very old *roff implementations). > It > makes an attempt at producing correct results for groff, but to a first > approximation no one uses groff any more.
The pod2man output for Latin1 is indeed incorrect for the non-ASCII latin1 characters. I do some post processing, with perl, to convert the wrong output to groff escape sequences. I have reported a bug about this in the past. The groff escape sequences work in a latin1 and in an utf8 world. I know that groff escape sequences don't work with all roff implementations, but I never had any complaints. Show quoted text
> My intent in the future is to change pod2man to start producing UTF-8 > by > default, since this is what most modern man implementations now expect, > and continuing to butcher people's names in man pages feels rude. I > suspect most (possibly all) modern *roff implementations will cope with > UTF-8 input now, or at least won't produce any worse output than the > current output.
On Linux this is true. On Windows UTF-8 is still problematic. Cygwin supports UTF-8, but the man system still expects man pages in Latin-1 encoding. They should switch from the legacy man to man-db (like the major Linux distributions did) which is much better in handling man pages in different encodings. But man-db has not been ported to Cygwin yet. I wanted to port man-db to Cygwin myself, but I don't have the time. On MINGW/MSYS UTF-8 is not supported at all. MSYS2 is like Cygwin. Show quoted text
>> By using Latin1 encoding for the latin1 scripts, and no =encoding >> command, I'm compatible with old perl versions. For non-Latin1 scripts >> I >> include the pod2man produced man pages in the source package. Now with >> the new perl 5.18 coming this seems also my best option for Latin-1 >> scripts to avoid trouble.
> > I do this myself, and I think it's a good idea. I understand the > desire > to build everything in the distribution from source, but newer versions > of > pod2man produce considerably better output, which means that you'll be > doing your users a favor by including versions built with newer > versions > of Perl.
I agree. This is the direction that I'm going now. It is the easiest for everybody. I have already created a beta version that works this way. best regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/
Subject: Re: [rt.cpan.org #91805] pod2man fails on Latin-1 POD file without =encoding command.
Date: Fri, 03 Jan 2014 14:17:17 -0800
To: bug-Pod-Simple [...] rt.cpan.org
From: Russ Allbery <rra [...] cpan.org>
Download (untitled) / with headers
text/plain 1.4k
"waterlan via RT" <bug-Pod-Simple@rt.cpan.org> writes: Show quoted text
> Russ Allbery via RT schreef op 2014-01-03 19:03:
Show quoted text
>> pod2man will butcher non-ASCII Latin-1 scripts if you process them >> without -u. This has been the case for basically forever, back to when >> Tom Christiansen was maintaining it. The output without -u is >> basically wrong for nroff (although compatible with very old *roff >> implementations). It makes an attempt at producing correct results for >> groff, but to a first approximation no one uses groff any more.
Show quoted text
> The pod2man output for Latin1 is indeed incorrect for the non-ASCII > latin1 characters. I do some post processing, with perl, to convert the > wrong output to groff escape sequences. I have reported a bug about this > in the past. The groff escape sequences work in a latin1 and in an utf8 > world. I know that groff escape sequences don't work with all roff > implementations, but I never had any complaints.
Oh, okay, yes. I remember that bug report. For the record, while I don't have time to implement direct groff escape output, I'd be willing to merge patches that add that as an output mode, given your information about the state of UTF-8 on Windows cygwin. -- #!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker $^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD, 00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{ rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
CC: RRA [...] cpan.org
Subject: Re: [rt.cpan.org #91805] pod2man fails on Latin-1 POD file without =encoding command.
Date: Fri, 03 Jan 2014 23:49:58 +0100
To: bug-Pod-Simple [...] rt.cpan.org
From: waterlan <waterlan [...] xs4all.nl>
Download (untitled) / with headers
text/plain 2.7k
Russ Allbery via RT schreef op 2014-01-03 23:17: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=91805 > > > "waterlan via RT" <bug-Pod-Simple@rt.cpan.org> writes:
>> Russ Allbery via RT schreef op 2014-01-03 19:03:
>
>>> pod2man will butcher non-ASCII Latin-1 scripts if you process them >>> without -u. This has been the case for basically forever, back to >>> when >>> Tom Christiansen was maintaining it. The output without -u is >>> basically wrong for nroff (although compatible with very old *roff >>> implementations). It makes an attempt at producing correct results >>> for >>> groff, but to a first approximation no one uses groff any more.
>
>> The pod2man output for Latin1 is indeed incorrect for the non-ASCII >> latin1 characters. I do some post processing, with perl, to convert >> the >> wrong output to groff escape sequences. I have reported a bug about >> this >> in the past. The groff escape sequences work in a latin1 and in an >> utf8 >> world. I know that groff escape sequences don't work with all roff >> implementations, but I never had any complaints.
> > Oh, okay, yes. I remember that bug report. For the record, while I > don't > have time to implement direct groff escape output, I'd be willing to > merge > patches that add that as an output mode, given your information about > the > state of UTF-8 on Windows cygwin.
My workaround is in the dos2unix package in makefile man/man1/Makefile. It fixes only the non-ASCII characters that are present in the dos2unix manuals, but you can get the idea. perl -pli.bak \ -e s/A\\\\\\*\'/\\\\[\'A]/g\; \ -e s/a\\\\\\*\'/\\\\[\'a]/g\; \ -e s/E\\\\\\*\'/\\\\[\'E]/g\; \ -e s/e\\\\\\*:/\\\\[:e]/g\; \ -e s/e\\\\\\*\'/\\\\[\'e]/g\; \ -e s/i\\\\\\*\'/\\\\[\'i]/g\; \ -e s/n\\\\\\*~/\\\\[~n]/g\; \ -e s/O\\\\\\*\'/\\\\[\'O]/g\; \ -e s/o\\\\\\*\'/\\\\[\'o]/g\; \ -e s/u\\\\\\*\'/\\\\[\'u]/g\; \ $@ Here are some differences in the Spanish version of dos2unix.1.bak and dos2unix.1, where you can see the fixes to groff escape sequences. $ diff dos2unix.1.bak dos2unix.1 138,139c138,139 < \& dos2unix [para\*'metros] [ARCHIVO ...] [\-n ARCH_DE_ENTRADA ARCH_DE_SALIDA ...] < \& unix2dos [para\*'metros] [ARCHIVO ...] [\-n ARCH_DE_ENTRADA ARCH_DE_SALIDA ...] --- Show quoted text
> \& dos2unix [par\['a]metros] [ARCHIVO ...] [\-n ARCH_DE_ENTRADA > ARCH_DE_SALIDA ...] > \& unix2dos [par\['a]metros] [ARCHIVO ...] [\-n ARCH_DE_ENTRADA > ARCH_DE_SALIDA ...]
141c141 < .SH "DESCRIPCIO\*'N" --- Show quoted text
> .SH "DESCRIPCI\['O]N"
143c143 < El paquete Dos2unix incluye las utileri\*'as \f(CW\*(C`dos2unix\*(C'\fR y \f(CW\*(C`unix2dos\*(C'\fR para --- Show quoted text
> El paquete Dos2unix incluye las utiler\['i]as > \f(CW\*(C`dos2unix\*(C'\fR y \f(CW\*(C`unix2dos\*(C'\fR para
regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/
CC: grant [...] mclean.net.nz
Subject: Re: [rt.cpan.org #91805] pod2man fails on Latin-1 POD file without =encoding command.
Date: Sat, 11 Jan 2014 13:56:53 -0800
To: "bug-Pod-Simple [...] rt.cpan.org via RT" <bug-Pod-Simple [...] rt.cpan.org>
From: "David E. Wheeler" <dwheeler [...] cpan.org>
Download (untitled) / with headers
text/plain 1.9k
On Jan 3, 2014, at 1:38 PM, Russ Allbery via RT <bug-Pod-Simple@rt.cpan.org> wrote: Show quoted text
> I'm not sure there's any good solution here, but forwarding the bug to you as requested.
I asked Grant McClean about this; he added the =encoding warning. His reply: Show quoted text
> Hi David > > If I understand things correctly, the issue arises because the original > reporter has non-ASCII POD files that don't declare an encoding but he > doesn't want to add an =encoding declaration because of a desire to > remain compatible with old versions of Perl. He could add the encoding > declaration and old Perls would ignore it except that there is also a > desire to treat all POD warnings as errors. > > If we wanted to help support this type of use-case then I guess we could > add an option to Pod::Simple to tell it to not warn about the missing > =encoding. But then that would set a precedent and people might want an > option for every possible warning. > > Another approach would be to add some more general warning filtering. > But users of Pod::Simple can already do that themselves by providing an > alternative implementation of the 'whine' method. E.g.: Pod::Man could > add: > > sub whine { > my $self = shift; > return if $_[1] =~ /Non-ASCII character seen before =encoding/; > $self->SUPER::whine(@_); > } > > Or, alternatively the user who has this particular set of requirements > could do: > > use Pod::Man; > > { > my $old_whine = \&Pod::Simple::whine; > *Pod::Simple::whine = sub { > $old_whine->(@_) > unless $_[2] =~ /Non-ASCII character seen before =encoding/; > }; > } > > I'm not convinced that any change to Pod::Simple itself is desirable. > > Regards > Grant > > P.S. I'm about to go on vacation so will probably be off grid for at > least a week.
I am inclined to agree with him. What happens if you add =encoding ISO8859-1 To those two files? Does pod2man on 5.8 complain about an unrecognized Pod command? Best, David
CC: RRA [...] cpan.org
Subject: Re: [rt.cpan.org #91805] pod2man fails on Latin-1 POD file without =encoding command.
Date: Sun, 19 Jan 2014 16:56:44 +0100
To: bug-Pod-Simple [...] rt.cpan.org
From: Erwin Waterlander <waterlan [...] xs4all.nl>
Download (untitled) / with headers
text/plain 3.9k
Op 11-1-2014 22:57, David Wheeler via RT schreef: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=91805 > > > On Jan 3, 2014, at 1:38 PM, Russ Allbery via RT <bug-Pod-Simple@rt.cpan.org> wrote: >
>> I'm not sure there's any good solution here, but forwarding the bug to you as requested.
> I asked Grant McClean about this; he added the =encoding warning. His reply: >
>> Hi David >> >> If I understand things correctly, the issue arises because the original >> reporter has non-ASCII POD files that don't declare an encoding but he >> doesn't want to add an =encoding declaration because of a desire to >> remain compatible with old versions of Perl. He could add the encoding >> declaration and old Perls would ignore it except that there is also a >> desire to treat all POD warnings as errors. >> >> If we wanted to help support this type of use-case then I guess we could >> add an option to Pod::Simple to tell it to not warn about the missing >> =encoding. But then that would set a precedent and people might want an >> option for every possible warning. >> >> Another approach would be to add some more general warning filtering. >> But users of Pod::Simple can already do that themselves by providing an >> alternative implementation of the 'whine' method. E.g.: Pod::Man could >> add: >> >> sub whine { >> my $self = shift; >> return if $_[1] =~ /Non-ASCII character seen before =encoding/; >> $self->SUPER::whine(@_); >> } >> >> Or, alternatively the user who has this particular set of requirements >> could do: >> >> use Pod::Man; >> >> { >> my $old_whine = \&Pod::Simple::whine; >> *Pod::Simple::whine = sub { >> $old_whine->(@_) >> unless $_[2] =~ /Non-ASCII character seen before =encoding/; >> }; >> } >> >> I'm not convinced that any change to Pod::Simple itself is desirable. >> >> Regards >> Grant >> >> P.S. I'm about to go on vacation so will probably be off grid for at >> least a week.
> I am inclined to agree with him. What happens if you add > > =encoding ISO8859-1 > > To those two files? Does pod2man on 5.8 complain about an unrecognized Pod command? > > Best, > > David > >
Hi, Pod2man 5.8 breaks on an =encoding command. $ perl -v This is perl, v5.8.8 built for msys-64int Copyright 1987-2006, Larry Wall $ make man make -C man/man1 make[1]: Entering directory `/c/Users/waterlan/src/svnwork/dos2unix/trunk/dos2unix/man/man1' # make target - create manual page from a *.pod page podchecker dos2unix.pod *** WARNING: =item type mismatch ('definition' vs. 'number') at line 279 in file dos2unix.pod dos2unix.pod pod syntax OK. pod2man \ --center="$(date "+%Y-%m-%d")" \ --name="dos2unix" \ --section="1" \ dos2unix.pod \ | perl -p -e 's/[Pp]erl v[0-9.]+/dos2unix/;' \ Show quoted text
> dos2unix.1 && \
rm -f pod*.tmp perl -pli.bak \ -e s/A\\\\\\*\'/\\\\[\'A]/g\; \ -e s/a\\\\\\*\'/\\\\[\'a]/g\; \ -e s/E\\\\\\*\'/\\\\[\'E]/g\; \ -e s/e\\\\\\*:/\\\\[:e]/g\; \ -e s/e\\\\\\*\'/\\\\[\'e]/g\; \ -e s/i\\\\\\*\'/\\\\[\'i]/g\; \ -e s/n\\\\\\*~/\\\\[~n]/g\; \ -e s/O\\\\\\*\'/\\\\[\'O]/g\; \ -e s/o\\\\\\*\'/\\\\[\'o]/g\; \ -e s/u\\\\\\*\'/\\\\[\'u]/g\; \ dos2unix.1 # make target - create manual page from a *.pod page podchecker ../es/man1/dos2unix.pod *** ERROR: Unknown command 'encoding' at line 53 in file ../es/man1/dos2unix.pod *** WARNING: =item type mismatch ('definition' vs. 'number') at line 297 in file ../es/man1/dos2unix.pod ../es/man1/dos2unix.pod has 1 pod syntax error. make[1]: *** [../es/man1/dos2unix.1] Error 1 make[1]: Leaving directory `/c/Users/waterlan/src/svnwork/dos2unix/trunk/dos2unix/man/man1' make: *** [man/man1/dos2unix.1] Error 2 I continue by adding the generated man pages to the source code package. regards,
Subject: Re: [rt.cpan.org #91805] pod2man fails on Latin-1 POD file without =encoding command.
Date: Sun, 19 Jan 2014 11:06:35 -0800
To: "bug-Pod-Simple [...] rt.cpan.org via RT" <bug-Pod-Simple [...] rt.cpan.org>
From: "David E. Wheeler" <david [...] justatheory.com>
Download (untitled) / with headers
text/plain 343b
On Jan 19, 2014, at 7:57 AM, waterlan via RT <bug-Pod-Simple@rt.cpan.org> wrote: Show quoted text
> Pod2man 5.8 breaks on an =encoding command.
Well, the other thing you can do is require a newer version of Pod::Simple. The =encoding directive was added in 2.03, released on 2003-09-01. I suspect that would be the simplest thing for you to do. Best, David
CC: waterlan [...] xs4all.nl
Subject: Re: [rt.cpan.org #91805] pod2man fails on Latin-1 POD file without =encoding command.
Date: Sun, 19 Jan 2014 12:01:08 -0800
To: bug-Pod-Simple [...] rt.cpan.org
From: Russ Allbery <rra [...] cpan.org>
"david@justatheory.com via RT" <bug-Pod-Simple@rt.cpan.org> writes: Show quoted text
Show quoted text
> On Jan 19, 2014, at 7:57 AM, waterlan via RT > <bug-Pod-Simple@rt.cpan.org> wrote:
Show quoted text
>> Pod2man 5.8 breaks on an =encoding command.
Show quoted text
> Well, the other thing you can do is require a newer version of > Pod::Simple. The =encoding directive was added in 2.03, released on > 2003-09-01. I suspect that would be the simplest thing for you to do.
The core problem here is that pod2man in Perl 5.8 used Pod::Parser, not Pod::Simple. Upgrading podlators would fix the problem, but I think one of the goals here is to avoid requiring a specific Perl dependency on behalf of the person building this software. (Which is not Perl software; it's just using pod2man to generate man pages for non-Perl code.) -- #!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker $^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD, 00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{ rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
Subject: Re: [rt.cpan.org #91805] pod2man fails on Latin-1 POD file without =encoding command.
Date: Sun, 19 Jan 2014 12:15:18 -0800
To: "bug-Pod-Simple [...] rt.cpan.org via RT" <bug-Pod-Simple [...] rt.cpan.org>
From: "David E. Wheeler" <david [...] justatheory.com>
Download (untitled) / with headers
text/plain 1.2k
On Jan 19, 2014, at 12:01 PM, Russ Allbery via RT <bug-Pod-Simple@rt.cpan.org> wrote: Show quoted text
> Upgrading podlators would fix the problem, but I think one of the goals > here is to avoid requiring a specific Perl dependency on behalf of the > person building this software. (Which is not Perl software; it's just > using pod2man to generate man pages for non-Perl code.)
Yeah, but at some point you need to write that off. I think it’s reasonable to expect that people stuck on ancient versions of Perl might have to do a little more work to keep using tools. As for dos2unix, I can see that’s more of a barrier than usual, since it’s not distributed on CPAN. In that case, building the man pages and distributing them in the tarball seems like a reasonable workaround. Better might be a way to turn off Pod::Simple’s warnings. Could you add a flag to pod2man to pass `no_whining => 1` to Pod::Simple? Not that that would help pod2man on older versions of Perl, either. Another solution would be to have the build stuff remove =encoding lines from appropriate files on older Perls. At any rate, this discussion has not convinced me that Pod::Simple needs to change. Overall this functionality is an improvement, and there are workarounds for supporting older systems where appropriate. Am I missing something? Best, David
CC: waterlan [...] xs4all.nl
Subject: Re: [rt.cpan.org #91805] pod2man fails on Latin-1 POD file without =encoding command.
Date: Sun, 19 Jan 2014 12:34:11 -0800
To: bug-Pod-Simple [...] rt.cpan.org
From: Russ Allbery <rra [...] cpan.org>
Download (untitled) / with headers
text/plain 2.8k
"david@justatheory.com via RT" <bug-Pod-Simple@rt.cpan.org> writes: Show quoted text
> Yeah, but at some point you need to write that off. I think it’s > reasonable to expect that people stuck on ancient versions of Perl might > have to do a little more work to keep using tools. As for dos2unix, I > can see that’s more of a barrier than usual, since it’s not distributed > on CPAN. In that case, building the man pages and distributing them in > the tarball seems like a reasonable workaround. Better might be a way to > turn off Pod::Simple’s warnings. Could you add a flag to pod2man to pass > `no_whining => 1` to Pod::Simple?
There's already such a flag (as well as a few other possibilities), but they were added in versions of pod2man that postdate Perl 5.8. :) So if those options are available, pod2man handles =encoding properly anyway, so there's no need to use them. Show quoted text
> At any rate, this discussion has not convinced me that Pod::Simple needs > to change. Overall this functionality is an improvement, and there are > workarounds for supporting older systems where appropriate.
Show quoted text
> Am I missing something?
You're reaching the same conclusion that I ended up reaching about podlators: I'm unhappy about the backward incompatibility, and if I could go back in time and fix it, I would, but I'm unenthused by the things that I could do right now to fix the problem without retroactively changing the contents of Perl 5.8. The one concrete thing that I could do now is to suppress the error for not using =encoding in current pod2man. But the problem I have with doing that is that I don't think it's actually correct. Undeclared encodings aren't something that we should encourage. I suppose one could make an argument that I should suppress that warning until Perl 5.8 is no longer something that anyone cares about, and then enable it. But that's part of why I forwarded this bug to you as the Pod::Simple maintainer: if we're going to decide to do that to make it more possible to write POD that's portable to Pod::Simple formatters in Perl 5.8, I don't feel like this should be a decision that I make just for pod2man. The same issue potentially applies to old pod2html, etc., and it feels like we should be applying the same policy uniformly across all the Pod::Simple consumers. Now, pod2man and pod2text are somewhat special in that they've been core functionality for longer than just about any other POD formatter, and maybe it is appropriate for me to have a different warning strategy than other Pod::Simple consumers. If you do feel that's the case, I'll certainly listen to arguments in that direction. But so far, that doesn't feel quite right to me. -- #!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker $^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD, 00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{ rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
Subject: Re: [rt.cpan.org #91805] pod2man fails on Latin-1 POD file without =encoding command.
Date: Sun, 19 Jan 2014 15:48:20 -0800
To: "bug-Pod-Simple [...] rt.cpan.org via RT" <bug-Pod-Simple [...] rt.cpan.org>
From: "David E. Wheeler" <david [...] justatheory.com>
Download (untitled) / with headers
text/plain 891b
On Jan 19, 2014, at 12:34 PM, Russ Allbery via RT <bug-Pod-Simple@rt.cpan.org> wrote: Show quoted text
> There's already such a flag (as well as a few other possibilities), but > they were added in versions of pod2man that postdate Perl 5.8. :) So if > those options are available, pod2man handles =encoding properly anyway, so > there's no need to use them.
Okay, good. Show quoted text
> Undeclared encodings aren't something that we should encourage.
I agree. Show quoted text
> Now, pod2man and pod2text are somewhat special in that they've been core > functionality for longer than just about any other POD formatter, and > maybe it is appropriate for me to have a different warning strategy than > other Pod::Simple consumers. If you do feel that's the case, I'll > certainly listen to arguments in that direction. But so far, that doesn't > feel quite right to me.
I don’t know. Have you had many other complaints? David
CC: waterlan [...] xs4all.nl
Subject: Re: [rt.cpan.org #91805] pod2man fails on Latin-1 POD file without =encoding command.
Date: Sun, 19 Jan 2014 18:17:34 -0800
To: bug-Pod-Simple [...] rt.cpan.org
From: Russ Allbery <rra [...] cpan.org>
"david@justatheory.com via RT" <bug-Pod-Simple@rt.cpan.org> writes: Show quoted text
> Russ Allbery via RT <bug-Pod-Simple@rt.cpan.org> wrote:
Show quoted text
>> Now, pod2man and pod2text are somewhat special in that they've been >> core functionality for longer than just about any other POD formatter, >> and maybe it is appropriate for me to have a different warning strategy >> than other Pod::Simple consumers. If you do feel that's the case, I'll >> certainly listen to arguments in that direction. But so far, that >> doesn't feel quite right to me.
Show quoted text
> I don’t know. Have you had many other complaints?
Not about this. I've gotten other complaints about the =item number vs. desc type mismatch, but that has a fairly straightforward (if ugly) fix with Z<>. -- #!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker $^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD, 00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{ rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
Subject: Re: [rt.cpan.org #91805] pod2man fails on Latin-1 POD file without =encoding command.
Date: Mon, 20 Jan 2014 09:12:36 -0800
To: "bug-Pod-Simple [...] rt.cpan.org via RT" <bug-Pod-Simple [...] rt.cpan.org>
From: "David E. Wheeler" <david [...] justatheory.com>
Download (untitled) / with headers
text/plain 492b
On Jan 19, 2014, at 6:17 PM, Russ Allbery via RT <bug-Pod-Simple@rt.cpan.org> wrote: Show quoted text
> Not about this. I've gotten other complaints about the =item number > vs. desc type mismatch, but that has a fairly straightforward (if ugly) > fix with Z<>.
Then I think I will just leave it alone. If there were a lot of complaints, I think it would be worth looking at hacking something in. But if there are few or just one, and there is a workaround, then not so much. Okay by you? Thanks, David
CC: waterlan [...] xs4all.nl
Subject: Re: [rt.cpan.org #91805] pod2man fails on Latin-1 POD file without =encoding command.
Date: Mon, 20 Jan 2014 11:20:29 -0800
To: bug-Pod-Simple [...] rt.cpan.org
From: Russ Allbery <rra [...] cpan.org>
Download (untitled) / with headers
text/plain 952b
"david@justatheory.com via RT" <bug-Pod-Simple@rt.cpan.org> writes: Show quoted text
> Russ Allbery via RT <bug-Pod-Simple@rt.cpan.org> wrote:
Show quoted text
>> Not about this. I've gotten other complaints about the =item number >> vs. desc type mismatch, but that has a fairly straightforward (if ugly) >> fix with Z<>.
Show quoted text
> Then I think I will just leave it alone. If there were a lot of > complaints, I think it would be worth looking at hacking something > in. But if there are few or just one, and there is a workaround, then > not so much. Okay by you?
It's okay with me. I'll let you know if the situation changes. Hopefully Perl 5.8 will die out; the newer versions are so much nicer. -- #!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker $^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD, 00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{ rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
Amen to that!
CC: bug-Pod-Simple [...] rt.cpan.org
Subject: Re: [rt.cpan.org #91805] pod2man fails on Latin-1 POD file without =encoding command.
Date: Mon, 20 Jan 2014 22:19:12 +0100
To: Russ Allbery <rra [...] cpan.org>
From: waterlan <waterlan [...] xs4all.nl>
Download (untitled) / with headers
text/plain 579b
Russ Allbery schreef op 2014-01-20 20:20: Show quoted text
> "david@justatheory.com via RT" <bug-Pod-Simple@rt.cpan.org> writes: >
>> Then I think I will just leave it alone. If there were a lot of >> complaints, I think it would be worth looking at hacking something >> in. But if there are few or just one, and there is a workaround, then >> not so much. Okay by you?
> > It's okay with me. I'll let you know if the situation changes. > Hopefully > Perl 5.8 will die out; the newer versions are so much nicer.
It's fine with me too. -- Erwin Waterlander http://waterlan.home.xs4all.nl/
Subject: Re: [rt.cpan.org #91805] pod2man fails on Latin-1 POD file without =encoding command.
Date: Mon, 20 Jan 2014 13:20:28 -0800
To: "bug-Pod-Simple [...] rt.cpan.org via RT" <bug-Pod-Simple [...] rt.cpan.org>
From: "David E. Wheeler" <david [...] justatheory.com>
Download (untitled) / with headers
text/plain 144b
On Jan 20, 2014, at 1:19 PM, waterlan via RT <bug-Pod-Simple@rt.cpan.org> wrote: Show quoted text
> It's fine with me too.
Great, thanks Erwin. Best, David


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.