zsh - .zshrc script on MacOS no longer prompts for input at Terminal startup, but it does when manually "sourced&qu

admin管理员组

文章数量:1395780

For a long time, I've had a simple script in my .zshrc file on MacOS that will fetch some values from BitWarden (using the Bitwarden CLI) to set them as environment variables. For this, the script needs to login to my vault, which means it will prompt me for my BitWarden password when it's run:

if [[ -z "${MY_USERNAME}" || -z "${MY_PASSWORD}" ]]
then
    BW_SESSION=$(bw unlock --raw)
    bw sync
    MY_USER=$(bw get username my-vault-item --session $BW_SESSION)
    MY_PASSWORD=$(bw get password my-vault-item --session $BW_SESSION)
    launchctl setenv MY_USER $MY_USER
    export MY_USER=$MY_USER
    launchctl setenv MY_PASSWORD $MY_PASSWORD
    export MY_PASSWORD=$MY_PASSWORD
    bw lock > /dev/null 2>&1
fi

However, a few months ago (perhaps after an OS update), it stopped working. After a reboot, when I open iTerm (or the default MacOS Terminal app), the script now runs without prompting me for my password after bw unlock, so it doesn't get a session key and the subsequent commands fail as expected.

The interesting thing is, if I manually do source .zshrc after that, everything works perfectly. It prompts for my password, my env variables are set, and they're available for any future sessions until I reboot again.

Any idea of why the script is no longer prompting me for my password when executed automatically at shell startup app, but it does when manually sourced?

Edit: Fot to mention I've also tried adding a 5s delay before the bw unlock line, like this:

if [[ -z "${MY_USERNAME}" || -z "${MY_PASSWORD}" ]]
then
    sleep 5
    BW_SESSION=$(bw unlock --raw)
    bw sync
    MY_USER=$(bw get username my-vault-item --session $BW_SESSION)
    MY_PASSWORD=$(bw get password my-vault-item --session $BW_SESSION)
    launchctl setenv MY_USER $MY_USER
    export MY_USER=$MY_USER
    launchctl setenv MY_PASSWORD $MY_PASSWORD
    export MY_PASSWORD=$MY_PASSWORD
    bw lock > /dev/null 2>&1
fi

But it didn't change anything. The terminal waits for 5 seconds, everything's properly initialized, but then it pushes through without prompting me for my password anyway.

For a long time, I've had a simple script in my .zshrc file on MacOS that will fetch some values from BitWarden (using the Bitwarden CLI) to set them as environment variables. For this, the script needs to login to my vault, which means it will prompt me for my BitWarden password when it's run:

if [[ -z "${MY_USERNAME}" || -z "${MY_PASSWORD}" ]]
then
    BW_SESSION=$(bw unlock --raw)
    bw sync
    MY_USER=$(bw get username my-vault-item --session $BW_SESSION)
    MY_PASSWORD=$(bw get password my-vault-item --session $BW_SESSION)
    launchctl setenv MY_USER $MY_USER
    export MY_USER=$MY_USER
    launchctl setenv MY_PASSWORD $MY_PASSWORD
    export MY_PASSWORD=$MY_PASSWORD
    bw lock > /dev/null 2>&1
fi

However, a few months ago (perhaps after an OS update), it stopped working. After a reboot, when I open iTerm (or the default MacOS Terminal app), the script now runs without prompting me for my password after bw unlock, so it doesn't get a session key and the subsequent commands fail as expected.

The interesting thing is, if I manually do source .zshrc after that, everything works perfectly. It prompts for my password, my env variables are set, and they're available for any future sessions until I reboot again.

Any idea of why the script is no longer prompting me for my password when executed automatically at shell startup app, but it does when manually sourced?

Edit: Fot to mention I've also tried adding a 5s delay before the bw unlock line, like this:

if [[ -z "${MY_USERNAME}" || -z "${MY_PASSWORD}" ]]
then
    sleep 5
    BW_SESSION=$(bw unlock --raw)
    bw sync
    MY_USER=$(bw get username my-vault-item --session $BW_SESSION)
    MY_PASSWORD=$(bw get password my-vault-item --session $BW_SESSION)
    launchctl setenv MY_USER $MY_USER
    export MY_USER=$MY_USER
    launchctl setenv MY_PASSWORD $MY_PASSWORD
    export MY_PASSWORD=$MY_PASSWORD
    bw lock > /dev/null 2>&1
fi

But it didn't change anything. The terminal waits for 5 seconds, everything's properly initialized, but then it pushes through without prompting me for my password anyway.

• macos
• zsh

Share Improve this question Follow edited Mar 13 at 10:39 VMX asked Mar 13 at 10:22 VMXVMX 32722 silver badges1010 bronze badges 5

• 1 You could try running type launchctl and type bw in your normal Terminal and getting the full paths to them. Then set your PATH at the top of the script so it can find the executables you wish to use. Obviously set PATH to the *containing directory for bw, not the full path to bw. – Mark Setchell Commented Mar 13 at 11:04
• 1 Put setopt xtrace at the beginning of your .zshrc. This will cause it to show a trace of all the commands being executed. Then you should be able to see what happens when it gets to that if. – Barmar Commented Mar 13 at 11:13
• @Barmar, the trace shows what I already expected: after the bw unlock command, I get a "You are not logged in" output (which is visible in my terminal session). It's simply not asking me for my password, so the command fails. @MarkSetchell, the executable is found and command is being run. In the terminal I get an error message saying "You are not logged in", which happens right after the bw unlock command. – VMX Commented Mar 13 at 15:28
• 1 I don't know the Bitwarden CLI commands. Which command is supposed to prompt for a password? – Barmar Commented Mar 13 at 15:42
• Yes, apologies. bw unlock prompts you for your password, or you can also provide the password as an argument. However, I think I found the issue. Thanks @MarkSetchell for pointing me in the right direction. I will create an answer. – VMX Commented Mar 13 at 16:18

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 1

Ok, I figured this out after @MarkSetchell gave me a clue to follow.

What was happening was that, at some point in the past, I moved from a different installation method to npm for the Bitwarden CLI tool.

However, I didn't clean things up properly, and I had two version of the tool coexisting in my system: an old one at /usr/local/bin, and the latest one at /Users/myuser/.npm-global/bin/bw.

In my .zshrc file, my Bitwarden script was running BEFORE the npm path was added to my path variable. Meaning, the script was trying to use the (now very outdated) BW CLI client. And it was probably failing because of an incompatibility with the latest BW features. But because I was not getting a "not found" error, it wasn't easy to notice that I was actually running an older version.

All I had to do was make sure that the npm path was added to the shell before the script is executed, and of course I also cleaned up the old installation to prevent any future confusion.

Thanks everyone for your answers!

本文标签：