xbps
xbps copied to clipboard
void-linux
[Feature request] Built-in pager for long output
Not much more to add to the title.
I see it as being enabled by a flag, like -p or --pager.
I was mostly thinking about xbps-query, but due to the way available updates and such are displayed, the output can easily be fairly long in xbps-install too.
Considering how many outputs dump massive outputs to stderr, this could be useful.
We need a way to specify the pager. Possible options:
- via command line argument
xbps-query -p 'less -F' -s lib - via enviroment variable
XBPS_PAGER='less -F'
The first way requires specifying the pager each time, so user will end up using an alias. This defeats the purpose of the pager command line option as we can use xbps-query ... | less -F alias directly.
The second way also removes the need for command line argument. We can inspect the enviroment variable directly.
Btw, IIUC less -F is the only way to handle long/short outputs gracefully.
Considering how many outputs dump massive outputs to stderr, this could be useful.
I don't think we should use a pager for stderr. Stderr meant to be used for debug. Also mixing both outputs in a pager may be undesired.
I was mostly thinking about xbps-query, but due to the way available updates and such are displayed, the output can easily be fairly long in xbps-install too.
xbps-install is interactive and requires user input, it should not use pager.
I don't think we should use a pager for stderr. Stderr meant to be used for debug. Also mixing both outputs in a pager may be undesired.
Maybe I don't completely understand your point, but aren't pagers supposed to never be used with scripting anyway?
xbps-install is interactive and requires user input, it should not use pager.
Wouldn't there be a way to wait for the user input once the pager is exited?
Maybe I don't completely understand your point, but aren't pagers supposed to never be used with scripting anyway?
Sure. My point was that we shouldn't pipe both xbps stdout and stderr to a pager.
Actually I didn't have any valid argumentation so I've checked git source code to see, how pager is used there.
https://github.com/git/git/blob/master/pager.c#L135
And I've found that both stdout and stderr are piped into pager. Well, it's okay to do so. False alarm.
Wouldn't there be a way to wait for the user input once the pager is exited?
Oh, nice idea, this will probably work. If so, I think it should be possible to add pager support to install/remove commands as well.
Btw, any response regarding command line argument vs environment variable?
Btw, any response regarding command line argument vs environment variable?
Is there a standard way to specify a pager via the environment?
As for the command line argument, it could probably be done like the colour argument in ls:
--color[=WHEN] colorize the output; WHEN can be 'always' (default
if omitted), 'auto', or 'never'; more info below
Maybe have a default pager, or a list of them?
I think it is usually PAGER. Some applications also use prefixed variables like MANPAGER or GIT_PAGER.
Piping the output to a pager breaks the commands that require user-input.
As for the need for this to be implemented, it isn't. This is would be a user experience upgrade for console environments with limited screen size (and any other environment without scrollback.
Seriously I don't see the point of using a pager... cannot you pipe output to less(1)?
That's what I usually do and that's enough for me.
But still, since the issue is opened I think it won't harm to bring some ideas on possible implementation.
this is why -y exists, to avoid interactivity
But that makes it impossible to review changes before applying them.
Do you know any package manager that supports a pager for install commands? If we were to implement this, having some sort of example would certainly help. I can see the case for a pager for xbps-query, but at the same time I don't see why xbps-query <smth> | less isn't enough.
I think in most environments nowadays there is scrollback available in the terminal emulator. If you are in a console environment with limited screen size and without built-in scrollback you can either use something like tmux or screen to get scrollback, or just manually pipe the output to less. Scrollback is often useful when working on the command line, and with tmux and screen there are already generalized solutions for the problem available. So I think "being able to read the scrollback" is not a valid argument for this feature.
Still, git has a pager which is even enabled by default, so I assume many find it useful there. I guess this is due to the fact that you often have to parse the output of its commands like git diff from top to bottom e.g. before committing. That's much easier with a pager which jumps you to the start of relevant content; if you would use the terminal scrollback you would first have to "search" for the start.
I'm not sure this is so useful for a packet manager. Personally, I only scroll back at system upgrades and some xbps-query operations, or pipe them to grep, e.g. like xbps-query -f <pkg> | grep etc. For most operations I don't need it, but YMMV.
Maybe we should first create a list of concrete situations where this would be useful?
Another thought: Generally you don't want to parse the full output of xbps-install -Su (which is one of the most common tasks I guess). You probably want to read what's printed before the confirmation prompt (to see which packages are updated and to what version) - that's already easy because it oftens fits on the screen and if not, it's not many lines of scrollback. The other thing you want to read is important messages during the upgrade, like creation of .new-* files or custom messages from packages.
For the latter, there may be better solutions like a pager, like https://github.com/void-linux/xbps/issues/381.
Piping to less simply does not work, all that is shown is the repo update lines and the (broken) yes/no prompt. It also is a broken input state where you need to ctrl-c to stop xbps before exiting less. Dry run does not help, it instead prints an enormously verbose format that lacks columns, uses unfriendly format for sizes, and includes the repo url for each package. (Was is intended to be a machine-readable output format?)
Generally you don't want to parse the full output of xbps-install -Su (which is one of the most common tasks I guess). You probably want to read what's printed before the confirmation prompt (to see which packages are updated and to what version)
Hence why the pager is only needed before the confirmation prompt, and also part of why it it needs to be implemented within xbps and not just as a "pipe it to less".
that's already easy because it oftens fits on the screen and if not, it's not many lines of scrollback
I reach frequently enough situations where this is not the case, even sometimes going further than scrollback limit in some terminals. Tmux and screen are also not exactly trivial to use and require a non-negligible soup of convoluted keyboard shortcuts (entering scrollback in tmux is [Ctrl+B] followed by [a key hidden in second or 3rd layer on non-us keyboard layouts]). Using tmux's scolllback, the arrow keys also move a cursor instead of moving the screen up or down. You're either learning tmux/screen as is or travelling with your configs (and always run everything through it, despite the bugs it often causes). I also remember that at the time I made this issue, a bug existed where xbps-install in tmux on the linux console would completely break.
The other thing you want to read is important messages during the upgrade, like creation of .new-* files or custom messages from packages. For the latter, there may be better solutions like a pager, like #381.
The other issue is indeed probably the best way to deal with informational messages pre/post upadate, but as mentioned over there, it will propbably require some way to deal with the scrollback problem, like a pager. Integrating both the list of package changes and the install notes into the same pager view would probably be a good way to solve both.
Oh yes, with piping to less I was more thinking about other non-interactive commands like xbps-query... should have made myself more clear.
that's already easy because it oftens fits on the screen and if not, it's not many lines of scrollback
I reach frequently enough situations where this is not the case, even sometimes going further than scrollback limit in some terminals.
The part before the confirmation prompt does not fit in the scrollback? Didn't know it could be that much (but I'm also quite new to void).
Hence why the pager is only needed before the confirmation prompt, and also part of why it it needs to be implemented within xbps and not just as a "pipe it to less".
How would that work then from a user POV: First press q to leave the pager, then Y/n for the confirmation prompt?
The part before the confirmation prompt does not fit in the scrollback? Didn't know it could be that much (but I'm also quite new to void).
For normal (frequent) updating, the listing part of the output will entirely fit on even small terminals. But it's not even close to fitting big TTYs (think 1080p+ console) when the last update was a while ago.
How would that work then from a user POV: First press q to leave the pager, then Y/n for the confirmation prompt?
That's how I think it'd work best. It might require a message at the end about needing to exit the pager, but probably not if the pager is not default on