use Perl

Command line arguments come in as raw bytes. So you have to detect the codeset of the user's environment and encode if necessary. Roughly like this:

use I18N::Langinfo qw(langinfo CODESET);
use Encode qw(decode);
my $codeset = langinfo(CODESET);
for (@ARGV) { $_ = decode $codeset, $_ }

Likewise for environment variable values.

So there's hope that there will be ever Wx for FreeBSD?

I notices recently that rt.cpan.org does not show a TZ. Neither the Mediawiki-based page for the CPAN Meta spec proposal mentioned some days ago here (http://perl-qa.hexten.net/wiki/index.php/CPAN_Meta_Spec_Proposals).

Then I went curious: how does Wikipedia does it? No time zone either there. But the German pages displayed the last modification date in my local time zone! Without any javascript, it is part of the HTML. Then I wandered around the recent changes page in the various Wikipedia languages to find out the time zone used there: most use UTC, some use CEST. I hoped to find a pattern like "if a language is mostly spoken only in one time zone, then use this one, otherwise UTC", but it does not seem to exist a pattern.

What I don't like about absolute times is that everybody is forgetting to display the time zone. Or it would be nice if the time would be displayed in my local time zone (I think this should be possible using Javascript).

Anyway, I will write a proposal to define the META spec in terms of (Perl) data structures, and not anymore in terms of YAML. Though examples could still be in YAML (it's more readable than Perl or JSON or anything else); and there should be an appendix with recommended serialization formats (which would be YAML 1.0/1.1/Tiny/whatever, but probably also a Perl data dump).

Isn't YAML 1.1 specified to be utf-8 anyway?

Yeah, it's quite easy to find data problems there.

Germany > Berlin: the cities there are really boroughs, and most of them are duplicated (with and without the "Berlin-" prefix).

Inconsistent umlaut handling: Germany > Baden-Württemberg has a "u" instead of "ü", but I see umlauts in the "cities" under Berlin.

Croatia > Zagrebacka: this should not be Zagrebacka, but rather Zadarska or so.

Croatia > Grad Zagreb: the city of Zagreb appears twice, once under the correct name and once under the old German name "Agram" (which nobody uses anymore, not even the Germans). Sveta Nedelja appears in two spellings.

Maybe it would be better to use the data from OpenStreetMap?

So if I understand you correctly, then you want support for the "recommends" field in META.yml? As far as I know CPAN.pm cannot handle "recommends" (yet). But it shouldn't be to hard to implement it.

autobundle should be the way to go. Dependencies are resolved in
two ways: because the old installation already had the
dependencies resolved, so you have all required modules also in
the new installation, and because CPAN.pm anyway makes sure that
dependencies are always resolved.

But there's one gotcha: it can happen that left-over modules from
older versions of large distribution may cause the old
distribution to be installed again. Usually one protects himself
by using UNINST=1 while installing distributions, but in reality
almost nobody does it.

ad 1: Yes, they do. Once I setup a yaml file to keep the names of all
non-perl dependencies for some application. It looked roughly like
this:

    - pngcrush

    - jpegtran:
            debian:
                - libjpeg-progs
            redhat:
                - libjpeg
            cygwin:
                - jpeg

    - netpbm:
            debian:
                - "netpbm-progs (>= 10.26.54-5)"
                - "netpbm (>= 2:10.26.54-7)"
            redhat:
                - "netpbm >= 10.26.39"

So if you're lucky, then the package is called everywhere the same.
Sometimes it's everywhere called completely different. Sometimes in
one distribution some software components consists of one and in
another of multiple packages. Sometimes you have to specify versions
(I just used here the .deb resp. .rpm version syntaxes).

I did not have the need to differentiate between various distribution
versions, but I guess that there will be the some edge case when one
has to specify different package names or versions for debian/lenny
vs. debian/etch.

ad 6: Why not put it into META.yml? Perl dependencies are already
there, why not OS dependencies?

The initial problem is that the use.perl.org pages declare iso-8859-1
as its charset. So form data has also to be sent as iso-8859-1. Maybe
a browser shouldn't accept any non-latin1 characters when entering or
pasting data into form fields, but at least gecko-based browsers
doesn't do this. To do something with non-latin1 characters,
gecko-based browsers on Unix system seem to do use this heuristic:

* codepoints below 256 are fine

* if there are codepoints in the 0x80-0x9f range of win1252, then they
    are send like this (try LATIN CAPITAL LETTER S WITH CARON for a test)

* every other codepoint is sent as a numerical HTML entity

About pod2text: no, *pod2text* does not use man, but *perldoc* uses by
default pod2man. The plan was to fix pod2text encoding issues (there
are still some, but they are fixable, in contrast to pod2man) and then
to use something like Pod::Text::Overstrike or Pod::Text::Termcap
instead of Pod::Man.

I just right now created and uploaded
Pod-Perldoc-ToTextTermcap-0.00_50.tar.gz to CPAN. Just install it and
set

    export PERLDOC=-MPod::Perldoc::ToTextTermcap

or

    export PERLDOC=-MPod::Perldoc::ToTextOverstrike

and perldoc will use the new renderer. It looks somewhat different
than man output, but at least bold and underline is done (unlike with
stock Pod::Perldoc::ToText).

Hehe, I would say ASCII-only. Rafael's accents perfectly fit in the latin-1 charset.

If I know beforehand that a script can run a long time or something unexpected is likely to happen, then I install a sighandler to give me a stack trace:

        use sigtrap "handler" => sub { require Carp; Carp::carp() }, 'USR1', 'INFO';

That way I can do "kill -USR1 " and see what's going on.

This is especially nice on BSD systems, where SIGINFO exists. SIGINFO is typically bound to CTRL-T, so I don't have to find the pid (if the script runs in the terminal). The default output of CTRL-T provides also some numbers about memory and CPU usage and the current process state.

I usually workaround the IPC::Run test failure by setting the locale to C. So maybe you can just do the same in the test script, somehow, locally.

It's Croatian, but it means "Input/output error".