Re: Bug#363250: general: Custom PAGER gives error on sid, but works on sarge

[Manoj Srivastava <srivasta@debian.org>]

On 22 Apr 2006, Loïc Minier spake thusly:

> On Sat, Apr 22, 2006, Manoj Srivastava wrote:
>>>> 363250 is more about documenting the semantics of $PAGER (whether
>>> it can uses sh syntax, or whether it's a command with parameters
>>> separated with spaces), to be documented in man man, and/or
>>> policy.
>> Err, we should define how it behaves, not what is inside it. As
>> long as one can pipe things to $PAGER or use $PAGER on a file, what
>> it contains should not matter.
>
> Please read again the original report, the submitter wanted to have
> a pipe of commands in $PAGER, he said this worked in the past, and
> works on other distros.  He did not want to simply be able to use
> $PAGER on a file or to pipe stuff to $PAGER, he wanted $PAGER to be
> parsed as a pipeline, as in sh syntax.

        I read it. I still think that my answer suffices: Put your
 pipeline in a script, and set that to PAGER.  If I have a file that I
 want the users to see, as opposed to output I create, how can I
 figure out how to use the example in the initial bug report?


        There are two use cases that any pager directive must address:

    1) The program is going to generate output which must be piped to
       a pager
    2) The program want to send a file to the user.


>> The safe bet would be for $PAGER to be a script or executable
>> which can handle reading from file or STDIN, like proper UNIX
>> programs.
>
> This is an independent problem First, we already have one layer of
> sh scripting with the sensible-pager program, and it would be a good
> enough place to handle the cases you mention, would people and
> programs use sensible-pager as the default pager.  Second, this
> doesn't define what should happen when someone redefines $PAGER:
> what if one user wants $PAGER to be a pipeline?

        If the PAGER semantics are defined to state that whatever you
 change it to must work in the two use cases, then programs that use
 PAGER directly would not have an issue.

        But perhaps the policy for Debian should be for programs to
 ignore PAGER and just use sensible pager, where all the logic for
 dealing with pager goes in. I still don't see how sensible pager can
 handle the pipeline vs the non-pipeline case, though.

        Barring that, policy would have to be that programs can' t
 user PAGER to work with use case 2, and must be guilty of an "useless
 use of cat" to pipe data to STDIN for PAGER.

        Neither one of these is a happy prospect.

>> To make life easier for people writing programs which deal
>> with $PAGER, and  are using the POSIX exce* set of calls, one may
>> constrain $PAGER to "path [arg [arg ..]]", with no pipes or other
>> shell meta-characters.
>
> Yes, I think this is safe, but I'd go even further and propose the
> following:
> A/ handling of pager in programs
> 1/ programs should default to sensible-pager
> 2/ programs should offer a way to override the default pager in some
> way, for example via an environment variable called <program>_PAGER,
> or a configuration setting -- it might even be better for them to
> avoid handling $PAGER, see 1/

        PAGER has the benefit of being long standardized, and if we do
 not use PAGER, we are breaking user expectations.

        What is the benefit of creating a PAGER clone?

> B/ user configuration of the pager When defined, $PAGER is a sh
> pipeline which reads its data from stdin.

        How do programs present a text file to the user using a PAGER,
 then? cat file.txt | $PAGER?

> This is with the intent of moving any logic for deciding of the best
> pager to run out of each individual program requiring a pager,
> exactly as in the sensible-browser case, which can consider
> $BROWSER, $DISPLAY, x-www-browser, and www-browser to find a
> sensible browser.

        In other words, ignore $PAGER, use sensible-pager all over,
 and let that handle it?

> Manoj, how would this fit in policy?

        Not, unless these questions are answered, and we actually have
 a working implementation.

        manoj
-- 
Liberty don't work as good in practice as it does in speeches. The
Best of Will Rogers
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C