-=| Frank Lichtenheld, Thu, Dec 25, 2008 at 11:26:39PM +0000 |=-
> I'm really considering rejecting this module just for being
> crappy:
>
> * the documentation doesn't really describe the behaviour,
> since it claims that it will fall back to the defaults if ENV{PAGER}
> is unusable, which is simply not true, it will only fall back if
> ENV{PAGER} is undefined.
> * Doing the whole PAGER detection in BEGIN is also not the smartest idea
> ever...
> * Same goes for saving it in ENV instead of the actual objects...
> * "#Some platforms don't do -x so we use -e" What crappy platforms are those and
> why not just find them out via $^O or something?
> * Ignores /usr/bin/pager
> * "eval "require $class"; $class->new($_[0], $class);" -- uh, sure, that's surely
> not gonna die in the second statement if the eval failed...
> * The package should recommend "less" since that is not Essential
> * "do{ warn -x $ENV{PAGER} ?" sure, lets us ignore all that stuff we did with split
> and not using -x...
>
> Is it really better to include this module in Debian than just rewriting it?
I agree it is crappy.
I wonder what would be appropriate line of action.
1. fix the above in a series of patches and send them upstream (last
release in 2005)
2. rewrite it from scratch and patch clive to use IO::PagerNG
3. forget about IO::Pager and patch clive to not use it
IO::Pager is only used in the --print-cache option and I guess users
can pipe its output to a pager themselves anyway
What do others think is best?
Options 2 and 3 also have the benefit of not having to deal with the
funny upstream license.
For more background on how clive comes into play see
http://lists.debian.org/debian-perl/2008/12/msg00030.html
--
dam JabberID: dam@jabber.minus273.org
Attachment:
signature.asc
Description: Digital signature