Running shell scripts that wrapped CLIs

[martijnarts]

op CLI version

2.10.0

Goal or desired behavior

I have a shell script that runs doctl, something like:

#!/usr/bin/env bash

doctl account get

Current behavior

It currently will output:

$ ./bin/test.sh
Error: GET https://api.digitalocean.com/v2/account: 401 (request "...") Unable to authenticate you

It should just work, though.

Relevant log output

No response

[martijnarts]

Workaround is replacing the line with op plugin run doctl account get

[mrjones2014]

I think this is because the #!/usr/bin/env bash shebang line causes it to run in a subshell in which ~/.config/op/plugins.sh would not have been sourced.

As far as I know there isn't really any way around this other than having your script check if ~/.config/op/plugins.sh exists, and if so, source it again.

[mrjones2014]

Alternatively, you could write it as a shell function in your ~/.bashrc/~/.zshrc/~/.config/fish/config.fish instead of having it be a script.

e.g. for bash/zsh

mydoctlalias() {
  doctl account get
}

or for Fish shell:

function mydoctlalias
  doctl account get
end

This way it would run in the current shell instead of a subshell and therefore your aliases from ~/.config/op/plugins.sh would be respected.

[martijnarts]

Yeah, I figured that would be the problem. It might be worth adding something like this to the dev documentation.

[cussiol]

Those workarounds only work when you can modify the script. As 1Password Shell Plugins are based on alias, it seems a significant limitation for actual usage.

It is worth to think an alternative official way to make it work.

One way I thought is something like op plugins run <plugins> -- ./script

[SimonBarendse]

I think this is because the #!/usr/bin/env bash shebang line causes it to run in a subshell in which ~/.config/op/plugins.sh would not have been sourced.

This is correct. Furthermore, 1Password Shell Plugins are (currently) build to be used in interactive shells. Besides the problem you're now running into of the aliases not having been sourced, the plugin might also need to prompt (e.g. when you don't have a default credential configured), which is only possible in an interactive terminal.

---

I agree with both these comments:

It might be worth adding something like this to the dev documentation.

Those workarounds only work when you can modify the script. As 1Password Shell Plugins are based on alias, it seems a significant limitation for actual usage. It is worth to think an alternative official way to make it work.

[martijnarts]

I start all my scripts with this now:

if ! [ -x "$(command -v op)" ]; then
    echo >&2 "Error: 1Password CLI not installed, find it at: https://developer.1password.com/docs/cli/get-started#install"
    exit 1
fi

export OP_ACCOUNT=$(op account list | grep '<SOMETHING>.1password.com' | awk '{print $3}')

[SimonBarendse]

As an alternative workaround for now that doesn't require you to change your scripts, you could use a shim: create a file in your $PATH named doctl with the following contents:

op plugin run /usr/local/bin/doctl

It needs to have exec permissions (chmod +x) and it needs to take precedence in your path over the actual doctl binary

[cussiol]

@SimonBarendse I tried that workaround but got an error:

$ op plugin run -- /usr/local/bin/aws
[ERROR] 2023/02/09 01:58:06 unknown plugin: /usr/local/bin/aws
$ op plugin run /usr/local/bin/aws
[ERROR] 2023/02/09 01:58:09 unknown plugin: /usr/local/bin/aws

[lypanov]

All I'm looking for is a way to execute a command (in my case terraform plan) and have op plugin inject the AWS_ environment variables into that command. Is there any way to do this currently or is this or a related ticket blocking that?

[kjvalencik]

My workaround for terraform is a wrapper script that calls aws configure export-credentials --format env before executing the terraform command.

#!/bin/bash

eval "$(op plugin run -- aws configure export-credentials --format env)"

/usr/local/bin/terraform "${@}"

I have an alias to this script set to terraform in my shell config.

[AndyTitu]

@lypanov We have just released our new beta solution for the Terraform shell plugin. This allows AWS to work with Terraform out of the box, and also comes up with a general solution for authenticating terraform providers. Would be awesome if you could give it a try and let us know how/if this simplifies your workflows by a bunch.

[lypanov]

@lypanov We have just released our new beta solution for the Terraform shell plugin. This allows AWS to work with Terraform out of the box, and also comes up with a general solution for authenticating terraform providers. Would be awesome if you could give it a try and let us know how/if this simplifies your workflows by a bunch.

@AndyTitu Sorry for the delay in response, was recovering from illness. This works really well now thank you for the solution!