Hi, On Sat, Apr 22, 2006, Manoj Srivastava wrote: > > 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?
The point is that it used to work with a pipeline, as explained by the submitter, in the past and now it doesn't work, I later replied that it was never said that the content of $PAGER was following sh syntax. You propose a (valid) workaround, I propose to fix the policy, and to even actually support sh syntax (as this is trivial to do from sensible-pager). > 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. I agree that these use cases need to be supported. > 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, if I follow you, this would prevent pipelines. > 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. Yes, I believe the policy should be changed in this way, and as I proposed. Look at the code of sensible-pager, it will call "$PAGER" if sensible-pager is called without any argument, and "$PAGER <filename>" if it's called as "sensible-pager <filename>". This seems good enough for me; if people set $PAGER to a pipeline, they might suffer from problems for the second case, but we can work on that. > 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. Yes, if you mean that permitting pipelines forbids programs to call "$PAGER $file", I agree with you. There are multiple ways to solve this, but I think that whatever way is chosen should be implemented in sensible-pager, and we can even change our mind later, and fix only sensible-pager. The contract of sensible-pager with respect to Debian programs should be to offer two modes of operation, the pipe of data on stdin mode, and the pass a file on the command line mode (matching your use cases 1 and 2). > 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? sensible-pager is not a PAGER clone, it permits us to enhance the handling of $PAGER in a single place instead of changing every program in Debian that wants to send something to $PAGER. Have a look at the sensible-browser code, and at #351901 to convince you that there are useful things that can be done in such a nice place as sensible-pager. Eg, we might send data to "yelp" if running under GNOME. > > 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? That's a question for sensible-pager to solve, but one way is to use cat "$@" | $PAGER indeed. > > 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? Yes. > Not, unless these questions are answered, and we actually have > a working implementation. Well the current implementation works, except for pipelines. :) Bye, -- Loïc Minier <[EMAIL PROTECTED]> "You can gtk_main_run, but you can't gtk_widget_hide." --danw, 19-jul-04 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
