please reconsider using a pager by default in v2

[bgdnlp]

Please consider switching from using a pager by default to making it opt-in. It's great to have the option, just don't force it on everyone. It could be added to aws config and the user could be asked about it on first setup. Please reconsider.

It's not too late. The pain and confusion caused by this change is not worth the small benefit IMO. Especially since it's not working as intended. There are many combinations out there that are not Linux and bash.

Is your feature request related to a problem? Please describe.
I'm using Mac and zsh. My ~/.aws/credentials contains multiple profiles and "default" is not used.
aws-cli version is: aws-cli/2.0.28 Python/3.7.4 Darwin/19.5.0 botocore/2.0.0dev32
Command used to test: aws --profile myprofile elasticache create-snapshot --cache-cluster-id mycluster --snapshot-name deleteme

• On Mac and FreeBSD (at least), the output of less isn't printed to console by default. That is, when you quit less the output is lost, so you'd have to run the command again. Which is usually ok, but very annoying when it comes to aws-cli.
• Setting cli_pager= in [default] doesn't work when using another profile. Which means I'd have to set it in every profile on every host.
• Setting AWS_PAGER="" in ~/.zprofile (zsh) doesn't work for some reason. Setting AWS_PAGER="None" doesn't work either, it still pipes through less. I checked that the variable is set with set | grep AWS_PAGER. Note that $PAGER is also set, to less.
• What about running aws-cli in other environments? Containers, Lambda, embedded into other application packages, delivered to third parties, etc.

Describe the solution you'd like
Turn off using a pager by default, leave it as an option.

Additional context
I realize there are ways to "fix" it or work around this new "feature". We could add instructions to new releases that use aws-cli v2. We can change all the scripts we have and set AWS_PAGER in them. Get fancy and try to detect if a tty is present and set accordingly.

But why? Serious question, what is the reasoning behind this breaking change, considering the amount of work we need to do to acomodate it? Personally I see the CLI as being used mainly in scripts, if I want an interactive experience I go to the web console.

[kdaily]

Hi @bgdnlp, thanks for the report and the details about your experience and your environment. There's another open issue related to this (#5102) regarding the defaults for this feature.

I am surprised that the AWS_PAGER environment variable isn't working for you. I am also using OSX and the zsh shell, and adding export AWS_PAGER="" to my ~/.zprofile suppresses paging. Here's what I see for my env variables:

 > set | grep PAGER
AWS_PAGER=''
PAGER=less

I'm going to leave this open as a feature request for now, as you have provided a number of good talking points.

[bgdnlp]

I've seen that issue, and the others, but we're asking for different things. What @QuinnyPig is asking for is good for an interactive tool like "git log", my point is that interactive use is not the main use case for aws-cli, unlike "git log".

Even where it is used interactively, the paging behavior is not always wanted (see less defaults [1] and the comments on the linked issue). Also, isatty() might not be entirely reliable on other operating systems, for example on Windows. There are probably more corner cases.

You could add a switch like --use-pager so that people who want it can set aliases in their shell. Honor the setting in config and AWS_PAGER. Tell people about it on first use and in the docs. But please reconsider making it a default because there's too much of an impact on existing tools.

About zsh, I don't know, maybe it behaves differently for different commands? That's why I mentioned what command I'm using to test. I can make it a bug report if it's a bug. This is what I'm using, slightly redacted:

 ~ » aws --version
aws-cli/2.0.28 Python/3.7.4 Darwin/19.5.0 botocore/2.0.0dev32
 ~ » set | grep PAGER
AWS_PAGER=''
PAGER=less
 ~ » aws --profile my-profile elasticache create-snapshot --snapshot-name mysnapshot --cache-cluster-id myredis
 ~ »

There's no output because it goes to less which doesn't print it to console.

--
[1] For anyone looking, the -X option will cause less to NOT clear the screen when it quits. Which means you can still scroll up to find older aws-cli output and copy&paste. -X can be sent to less by default by adding it to the value of LESS env var. This is set by default on some Linuxes. -R and -F might also be desirable.

[andrew-glenn]

Cross referencing: I've submitted a PR that changes this behavior from default to opt-in. See #5398

[andyjduncan]

Please reconsider this change, it is so disruptive. My usage of the AWS CLI is split pretty evenly between interactive use and automation scripting. I now have to work where, and in what cases, and how, I need to set or unset a combination of environment variables or configurations option to get the behaviour I want.
Alternatively, if this behaviour is opt-in, most of the I can leave everything as default, and in the rare cases I need to page the CLI output, I have a solution to that: I can pipe it through a pager.
Please look at this again.

[bgdnlp]

Any news on this, especially @andrew-glenn 's patch? I keep tripping over it from time to time and I'm a bit worried of what will happen when/if some OS distributions switch from awscli v1 to awscli v2 while keeping the same package name.

[sc0ttdav3y]

OMG I'm glad I finally spent some time to search up this issue. I've been going nuts for over a year, and I didn't know what changed to cause my AWS commands to show in less rather than stdout.

My main gripe is that all my automation scripting started pausing in less after running each AWS command.

If AWS is hell-bent on using a pager by default, perhaps they can detect whether the command is invoked by the user or by another script, and only use the pager when in interactive mode.

At least I have a workaround for now — set AWS_PAGER to "".

[RichardBradley]

+1 to this!

Some of our CI builds started hanging recently when they produced more than one page of output. It took us quite a while to isolate the issue to this new default setting. I'm not even sure if we've recently changed from v1 to v2 CLI, or if our scripts have recently started producing more than one page of output.

I think it's not standard for unixy CLI tools to require interactive input by default. It should be opt-in to avoid breaking scripts.