I want to display some help text, and search it with grep.
aws ec2 help | grep instance
AWS CLI uses more to paginate the help.
To disable it I've already tried:
aws --no-cli-pager ec2 help | grep instance
export AWS_PAGER=''; aws ec2 help | grep instance
and changing cli_pager in config file:
[default]
cli_pager=
It still uses the pager.
I'm using AWS CLIv2 Windows version on Cygwin.
How does one disable it?
There are two ways to disable pagination in the AWS CLI.
1: Using the cli_pager option in the config file:
[default]
cli_pager=
2: Using the AWS_PAGER environment variable:
$ export AWS_PAGER=""
Please note: They only work if you’re using the AWS CLI version 2. They aren’t available if you run AWS CLI version 1. For information on how to install version 2, see Installing, updating, and uninstalling the AWS CLI version 2.
There is in fact no well-supported way to do this for the special case of the help output. The help output is treated specially by the v2 aws-cli and ignores the configured cli_pager gadgetry.
The workaround is simply to remove the tty and pipe to cat:
aws help |cat
see:
https://github.com/aws/aws-cli/issues/4972
Related
I defined my KUBECONFIG for the AWS EKS cluster:
aws eks update-kubeconfig --region eu-west-1 --name yb-demo
but got the following error when using kubectl:
...
Use "kubectl <command> --help" for more information about a given command.
Use "kubectl options" for a list of global command-line options (applies to all commands).
[opc#C eks]$ kubectl get sc
Unable to connect to the server: getting credentials: exec: executable aws not found
It looks like you are trying to use a client-go credential plugin that is not installed.
To learn more about this feature, consult the documentation available at:
https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins
You can also append your custom aws cli installation path to the $PATH variable in ~/.bash_profile: export PATH=$PATH:<path to aws cli program directory>. This way you do not need to sed the kubeconfig file every time you add an EKS cluster. Also you will be able to use aws command at the command prompt without specifying full path to the program for every execution.
I had this problem when installing kubectx on Ubuntu Linux via a Snap package. It does not seem to be able to access the AWS CLI then. I worked around the issue by removing the Snap package and just using the shell scripts instead.
It seems that in ~/.kube/config the command: aws doesn't use the PATH environment and doesn't find it. Here is how to change it to the full path:
sed -e "/command: aws/s?aws?$(which aws)?" -i ~/.kube/config
Maybe it is for me but AWS cli on Mac it not outputting, it is like creating a new vim window when I have something like this. I am wondering is there a way to just show the output?
aws --cli-connect-timeout 6000 --endpoint-url=http://localhost:4566 sqs create-queue --queue-name test_queue
Cli version:
> aws --version
aws-cli/2.1.1 Python/3.9.0 Darwin/19.6.0 source/x86_64
It is possible that you are seeing the output of a pager.
There are a few ways to change this. I add the following to my ~/.aws/config file:
[default]
cli_pager=
For details, see: Using AWS CLI pagination options - AWS Command Line Interface
So Amazon Web Service (AWS) has just upgraded their CLI to v2. I've updated my version to the latest (and checked with aws --version to make sure it's using it). Trouble is, now my simple command doesn't work and I can't figure out why.
With CLI v1, I used: aws s3 sync myfile s3bucket
This worked fine and I had no issues with it.
Now, with CLI v2, it throws this error:
usage: aws [options] <command> <subcommand> [<subcommand> ...] [parameters]
To see help text, you can run:
aws help
aws <command> help
aws <command> <subcommand> help
aws: error: the following arguments are required: paths
I've looked up the documentation and the only mention of "paths" is this:
Options
*******
"paths" (string)
Literally just that. Any idea what this paths option (that is seemingly not an option, but a required parameter) does? And how then do I get aws s3 sync to start working again on this new CLI version?
Very disgruntled right now. I had just got this app working, sent it to a coworker to test it and bam! Broken!
Edit2: On checking the path files, I've realised the mistake. Each new subfolder I added to path adds the \ AFTER the folder, thus ending on the folder "CloudSync\Data" for example. It's not the updated CLI that's messing things up (although it was the update message that broke my program on my coworkers pc). It was that darned \
Thanks for the help though.
sync command can be used to sync two PATHS.. Possibilities are as follows :
<LocalPath> <S3Uri> or <S3Uri> <LocalPath> or <S3Uri> <S3Uri>
i.e. syncing localpath to S3; OR S3 to Local; OR two S3 paths itself.
There are some changes in v2. I executed on my local system and made sure this is working fine: Basically LocalPath should be a folder ; and no longer just a file. So that it will sync all contents inside temp folder in this example.
aws s3 sync temp s3://datalake-dl/
Alex's comment on the accepted answer was my problem too.
This fails with the error "the following arguments are required: paths"
aws s3 sync 'C:\my-folder\' s3://my-bucket-my-folder/
This succeeds
aws s3 sync 'C:\my-folder' s3://my-bucket-my-folder
So I'm trying to update firewall rules for my ligthsail instance. However, running the command
aws lightsail put-instance-public-ports --port-infos fromPort=22,protocol=TCP,toPort=22,cidrs=1.1.1.1 --instance-name Ubuntu-1
returns
Parameter validation failed:
Unknown parameter in portInfos[0]: "cidrs", must be one of: fromPort, toPort, protocol
In the description it seems that this functionality should be there? https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lightsail/put-instance-public-ports.html
Any idea where I mess up the command? Thanks!
Edit:
Updating aws cli version fixed the issue
Based on the comments, the issue was not the command used. The command was correct. The problem was with the outdated AWS CLI used.
The solution was to updated the AWS CLI.
For a month or so, I've been studying AWS services and now I have to accomplish some basic stuff on AWS elastic beanstalk via command line. As far as I understand there are the aws elasticbeanstalk [command] and the eb [command] CLI installed on the build instance.
When I run eb status inside application folder, I get response in the form:
Environment details for: app-name
Application name: app-name
Region: us-east-1
Deployed Version: app-version
Environment ID: env-name
Platform: 64bit Amazon Linux ........
Tier: WebServer-Standard
CNAME: app-name.elasticbeanstalk.com
Updated: 2016-07-14 .......
Status: Ready
Health: Green
That tells me eb init has been run for the application.
On the other hand if I run:
aws elasticbeanstalk describe-application-versions --application-name app-name --region us-east-1
I get the error:
Unable to locate credentials. You can configure credentials by running "aws configure".
In home folder of current user there is a .aws directory with a credential file containing a [profile] line and aws_access_key_id and
aws_secret_access_key lines all set up.
Beside the obvious problem with the credentials, what I really lack is understanding of the two cli. Why is EB cli not asking for credentials and AWS cli is? When do I use one or the other? Can I use only aws cli? Any clarification on the matter will be highly appreciated.
EDIT:
For anyone ending up here, having the same problem with "Unable to locate credentials". Adding --profile profile-name option solved the problem for me. profile-name can be found in ~/.aws/config (or credentials) file on [profile profile-name] line.
In order to verify that the AWS CLI is configured on your system run aws configure and provide it with all the details it requires. That should fix your credentials problem and checking the change in configuration will allow you to understand what's wrong with your current conf.
the eb cli and the aws cli have very similar capabilities, and I too am a bit confused as to why they both should exist. From my experience the main differences are that the cli is used to interact with your AWS account using simple requests while the eb cli creates connections between you and the eb envs and so allows for finer control over them.
For instance - I've just developed a CI/CD pipeline for our beanstalk apps. When I use the eb cli I can monitor the deployment of our apps and notify the developers when it's finished. aws cli does not offer that functionality, and the only to achieve that is to repeatedly query the service until you receive the desired result.
The AWS CLI is a general tool that works on all AWS resources. It's not tied to a specific software project, the type of machine you're on, the directory you're in, or anything like that. It only needs credentials, whether they've been put there manually if it's your own machine, or generated by AWS if it's an EC2 instance.
The EB CLI is a high level tool to wrangle your software project into place. It's tied to the directory you're in, it assumes that the stuff in your directory is your project, and it has short commands that do a lot of background work to magically put everything in the right place.