Accept usage of different pagers

[mirlord]

Accept usage of some system-wide set (by $PAGER) pagers:

• less (default)
• more
• vimpager

If the unsupported pager is set - it will be automatically replaced by
the default one.

Partially closes issue #8. Mentioned there most pager cannot be supported easily.

[mirlord]

most can be easily supported, as I can see.
The only problem, that the default configuration file (mad.conf) uses a non standard control-sequence: 90m. most's capabilities are limited to smth like this: http://wiki.bash-hackers.org/scripting/terminalcodes

I can change the default config, or add a special one and use it with most.

What would be the best option?

[bahamas10]

I'm checking this out from your comment on #12. This implementation is definitely better as it is pager-aware, however the eval statement doesn't sit well with me. I see the reasoning behind it, and in a perfect world we could assume everybody has bash v4 and associative arrays, but that's not the case. I would recommend an implementation like this.

# Check env, default to less
local pager_cmd=${PAGER:-less}
local pager_opt=

# Command specific options
case "$pager_cmd" in
    less) pager_opt='-R';;
    more) pager_opt='';;
    most) pager_cmd='less';; # most not supported
    *) pager_opt='';;
esac

foo | "$pager_cmd" $pager_opt

In the above example we have $pager_cmd that is set to $PAGER, and will default to less. Then we case-statement over the $pager_cmd variable to generate command-specific options. Having 'more' and '*' in the case statement is redundant, but they are there to illustrate the point.

In the call to foo at the bottom, $pager_cmd is quoted to avoid word-splitting by bash, but $pager_opt is left unquoted so the options will expand as though they were typed on the command line.

[mirlord]

Not a problem to reimplement.
But maintainer's decision about most and [90m formatting escape-sequence required to do it as 100% ready for another pull-request :(