Running shell scripts that wrapped CLIs

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

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

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.

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.

Yeah, I figured that would be the problem. 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.

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

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.

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}')

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

@SimonBarendse

@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

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?

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.

@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.

@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!

Hi everyone,

Looks like we have a conclusive answer and way forward here so I'll be closing this issue out.

Thanks all!

Navigation Menu

Repository navigation

Running shell scripts that wrapped CLIs #120

op CLI version

Goal or desired behavior

Current behavior

Relevant log output

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Running shell scripts that wrapped CLIs #120

Description

op CLI version

Goal or desired behavior

Current behavior

Relevant log output

Activity

martijnarts commented on Dec 19, 2022

mrjones2014 commented on Dec 19, 2022

mrjones2014 commented on Dec 19, 2022

martijnarts commented on Dec 19, 2022

cussiol commented on Dec 23, 2022

SimonBarendse commented on Jan 6, 2023

martijnarts commented on Jan 6, 2023

SimonBarendse commented on Jan 6, 2023

cussiol commented on Feb 9, 2023

lypanov commented on Mar 30, 2023

kjvalencik commented on Apr 20, 2023

AndyTitu commented on May 24, 2023

lypanov commented on Jan 8, 2024

scottisloud commented on May 7, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions