1P Zsh plugins no loading for shell script

Options
bradical
bradical
Community Member

Is there a documented way to make sure the 1P plugins load when invoking a shell script?

I use Zsh and have sourced the plugins on shell load such that this works fine in an interactive window:

$ which aws
aws: aliased to op plugin run -- aws

$ aws s3 ls
# prompts for access and lists S3 buckets

However, when I write a script to do it:

echo "Shell: $SHELL"
echo "AWS: $(which aws)"

and execute it:

$ ./myscript.sh
Shell: /bin/zsh
AWS: /opt/homebrew/bin/aws

it doesn't seem to be picking up my plugins despite running within the Zsh shell and therefore can't authenticate.

I'm sure this is something I'm misunderstanding about the environment in which the shell is running. Any tips?

Comments

  • Hey @bradical , thank you for reaching out to us!

    This is a known limitation of the shell plugins, and getting these to work in scripts and non-interactive calls is definitely on our roadmap!

    In the meantime, there are some workarounds that you can use:

    • export the alias directly in your script - begin your script with alias aws=op plugin run -- aws
    • source the plugins.sh file in your script - in your zshrc or bashrc or config file, you will find a statement such as source ~/.op/plugins.sh. Including the same statement at the beginning of your script will make sure that all your configured aliases are available in there too.

    Hope these solutions will work, as a stopgap. We'll keep posted with any developments around this! Let us know if we can help with anything else.

    Best,
    Horia

  • jinux_go
    jinux_go
    Community Member
    edited October 2023
    Options

    @Horia.Culea_1P I hope 1Password adds this feature as fast as possible! I don't know how much the work has gone through, but would you mind if you could share what use cases the new feature covers? Is 1Password's "proxy" command intended to be used only in shell scripts or in any executable programs? I wish for the second that gives users options.

    I suggest the following approach: allow users to specify the desired plugin to use and the exact binary file path, like this op plugin run --target aws -- /opt/homebrew/bin/aws. Users deserve more control over what to use.


    Here is my current workaround for now (aws as an example). Put this script file into the one of entries in the $PATH, name it aws, and make sure this file precedes the original one in priority.

    #!/bin/sh
    if [ "${1-}" = '@FROM_PROXY' ]; then
      shift
      exec /opt/homebrew/bin/aws "$@"
    else
      exec op plugin run -- aws '@FROM_PROXY' "$@"
    fi
    

    The@FROM_PROXY trick is here to prevent cyclic execution.