Can't use --profile

[stefansundin]

I am trying to use --profile in my alias, but awscli is not forwarding it. It would also be acceptable for me if it instead set AWS_PROFILE since that would make things work in most cases.

Example alias:

test-args =
  !f() {
    echo arguments: $*
    echo profile: $AWS_PROFILE
  }; f

Output:

$ aws test-args test --profile admin
arguments: test
profile:
$ aws test-args test --profile2 admin
arguments: test --profile2 admin
profile:

It would be great if I would get this result:

$ aws test-args test --profile admin
arguments: test
profile: admin

Thanks!

Edit: The same thing happens with --region.

[vaneek]

I would definitely like to see command line options included as it would allow one to easily switch/override
accounts, profiles, regions, etc.

[ranman]

I was able to get this working with pure hackery:

docker-repo-uri =
    !f() {
        oargs=($(ps -o args= $PPID | cut -d' ' -f 3-))
        for i in "${!oargs[@]}"; do
            if [[ "${oargs[$i]}" == "--region" ]]; then
                region="--region ${oargs[$i+1]}"
            elif [[ "${oargs[$i]}" == "--profile" ]]; then
                profile="--profile ${oargs[$i+1]}"
            fi
        done
        aws ecr $region $profile \
        describe-repositories --output text \
        --query "repositories[?repositoryName == '${1}'].repositoryUri"
    }; f

[kyleknap]

That's an interesting edge case. So for the external aliases, the global arguments such as --profile and --region get consumed before the external alias gets ran so they are not proxied over to the command run in the subprocess.

I do not for sure if we can make the change (for backwards compatibility reasons), but I think it will be safe to make the change because we do not forward any of the values from the global parameters to the subprocess. But we will need to do more research to make sure there are no missing edge cases.

[stefansundin]

Hey @kyleknap. Thanks for looking into this. What do you think about my idea to populate AWS_PROFILE and AWS_REGION instead of forwarding the arguments? Maybe that's a better alternative?

[kyleknap]

It might. I would need to think about it. It may solve the issue involving --region and --profile but there are other global arguments that do not have environment variables so they would still have issue. Another scenario I want to avoid is someone actually setting the AWS_PROFILE or AWS_REGION environment variable and all of a sudden they start having that variable clobbered. However, I am not sure why they would be passing in those arguments in the first place if it currently it is getting completely ignored, but it is possible that it could cause issues. So for those reasons, I am still initially liking proxying the arguments over the use of environment variables, but that could change.

[vaneek]

Hi @kyleknap, thanks for the update but I think calling it an edge case is maybe understating its usefulness. I work with a number of accounts, Iam user ids and roles, the use of profiles has helped but the last thing I want to do is start mucking around with environment variables. I like the ideas and concepts introduced by the project but I think support of core CLI functionality will be needed.

[stefansundin]

In a quick test I did, --profile and --region seems to take precedence over AWS_PROFILE and AWS_REGION.

@vaneek I don't think Kyle was referring this issue as an edge case, but rather he was trying to think of new bugs that could be introduced in certain edge cases by fixing this bug, so he's just being extra careful not to break something else. :)

[aripalo]

Thanks @ranman for the hack! 🙂 Without it, using AWS Aliases would have been no go for me as I use multiple AWS accounts (therefore multiple profiles) and regions.

But again, it's a hack and now I must include it to every external alias I make, so hoping this gets fixed in AWS CLI!

[stefansundin]

This is actually a real pain.. I think the sooner this is fixed, the better. I don't want to rely on some hacky solution.

[yermulnik]

Any updates on this request?

[tomassommar]

+1

[troy-mac]

+1

[troy-mac]

Without the use of --profile the tool is truly a no go for me and for everyone I know in that is an AWS DevOps engineer. I don't know anyone not using multiple accounts these days. seeing the issue is 3 years old I feel it has been abandon. cool concept and tool, would be nice to complete it :)

[yermulnik]

Based on ranman's hackery I had to add this codeblock to every single AWS CLI alias that is wrapped into a function:

some-alias-name = 
  !f() {
    oargs=$(ps -o args= $PPID | cut -d' ' -f 3-)
    for oarg in $oargs; do
      if [ "$oarg" = "--region" -o "$oarg" = "--profile" -o "$oarg" = "--query" -o "$oarg" = "--output" ]; then
        needopt="$oarg"
        continue
      elif [ -n "$needopt" ]; then
        myopts="$myopts $needopt $oarg"
        unset needopt
      fi
    done

    [any other code you might need]

    aws $myopts <command> <subcommand> [parameters]
  }; f

Only opts listed in the if statement would get passed to AWS CLI along with their values hence you might want to amend the list according to your needs.

[Nitrodist]

Would be nice if we could have @yermulnik extracted into a function or something - that snippet works great, though.

[four43]

Has AWS abandoned CLI extensibility? Should we just give up trying to use this and go back to shell aliases?

[yermulnik]

I've just stublmed upon AWS CLI not passing args from command line properly as I would have expected it to... and found that when running AWS CLI installed with Homebrew ps output of cmdline with args is overly long and hence gets shortened to some sane length (probs man ps should have some info on this though I was too lazy to search for that).
For me locally ps output gets stripped from this:

/home/linuxbrew/.linuxbrew/Cellar/awscli/2.7.25/libexec/bin/python3.10 /home/linuxbrew/.linuxbrew/bin/aws --profile my-profile-name list-route53-zones

to this:

/home/linuxbrew/.linuxbrew/Cellar/awscli/2.7.25/libexec/bin/python3.10 /home/linuxbrew/.linuxbrew/bi

which is the cause of the issue with AWS CLI cmdline parameters being missed.
To fix this I needed to force unlimited length for ps output by adding double w:
ps -o args= $PPID becomes ps -wwo args= $PPID
Just bulk replace it across entire file and that's it.
Hope this helps someone 😺