When I use pry on a Linux system with BusyBox, I get things like:
[28] pry(main)> Object.instance_methods
less: invalid option -- R
BusyBox v1.21.1 (2013-10-21 07:24:03 UTC) multi-call binary.
Usage: less [-EMmNh~I?] [FILE]...
View FILE (or stdin) one screenful at a time
-E Quit once the end of a file is reached
-M,-m Display status line with line numbers
and percentage through the file
-N Prefix line number to each line
-I Ignore case in all searches
-~ Suppress ~s displayed past EOF
The culprit is pager.rb:129 -- by default, the pager is less -R -F -X. As you can see, BusyBox less doesn't support any of those options.
I can set the PAGER env variable, but it would be nice to make this "just work".
I think it's actually even worse than you said, because setting PAGER to anything starting with less will still force it to use those options. We should definitely fix that, probably by adding something like a Pry.config.pager_command option that you can set in your .pryrc.
As far as the default behavior, it's a tough one, because the vast majority of Pry users will have a version of less that supports those options and will have a better experience when the options are present. I'd be interested to hear how other people feel about it, but I think making it "just work" for you is probably not the right tradeoff when it makes it behave worse for everyone else.
I'm absolutely not suggesting that pry should be changed to work for me and only me. If I only cared about making it work for me, I would have set the PAGER variable and been done with it. I'm pointing out that there are many flavors of Unix out there, and the current pry defaults are broken on at least a few of them.
Perhaps something like this would make things more robust: check the value of $?.exitstatus after invoking the system pager, and if it is non-zero, use a regex on the first line of output to see if it is complaining about invalid options. If so, drop the options and try again.
If you think that the value of supporting some relatively obscure OSs is not enough to offset the cost of added code complexity, please close this issue -- this is just a suggestion for improvement. If you feel the "improvement" is not really an improvement, that is for you to decide.
FWIW, I see this issue in my Docker images that I base on Alpine Linux, which is being used more and more to make Docker images as small as possible.
And, if like me, you found this issue before this one, a workaround exists.
apk --update add less solved the issue for me. Thx @ruprict!
apk add --no-cache less works as well.
That's how I have added all other packages to my Apline Docker image so far, so not sure if --update is needed.
Most helpful comment
apk --update add lesssolved the issue for me. Thx @ruprict!