1

Running following version of zsh on Mac OS X.

zsh --version
zsh 5.8 (x86_64-apple-darwin20.0)

Im trying to set an environment variable called token in interactive shell however Im unable to set this for some reason. Is this because it has a special meaning in zsh ?

token=test

and then echo $token produces $token instead of test.

however If I have,

TOKEN=test

then echo $TOKEN produces test.

nixgadget
  • 6,983
  • 16
  • 70
  • 103
  • You need to `export token`. That is, `export token; echo $token` – kiner_shah May 23 '21 at 09:35
  • You dont necessarily need to do an `export` to set a variable. – nixgadget May 23 '21 at 09:37
  • You are probably setting environment variable in .bashrc file. So, whenever you open a new terminal, the contents of that file will be loaded and your environment will be set. Having an export inside .bashrc will make sure that your environment variable is accessible from every terminal. That's what I think happens. – kiner_shah May 23 '21 at 09:38
  • Nope. not setting an environment variable in a bash file. This is in shell. Not in any child process either. So you don't even need to do an `export`. – nixgadget May 23 '21 at 09:39
  • This question should not be closed because its nothing to do with `export` as shown by the two examples. – nixgadget May 23 '21 at 09:41
  • You may try some different name for example `token2` instead of `token`. – kiner_shah May 23 '21 at 09:42
  • 1
    Sure `token2` works fine. But my question is why `token` isnt working in bash ? – nixgadget May 23 '21 at 09:45
  • Can you try `echo "$token"` (with double quotes)? – kiner_shah May 23 '21 at 09:49
  • It results in `"$token"`. – nixgadget May 23 '21 at 09:52
  • 1
    Seems like someone else is running into this very issue on `zsh`. https://github.com/ohmyzsh/ohmyzsh/issues/9918 – nixgadget May 23 '21 at 09:59
  • Can you try using `typeset -p token` and check what it outputs? I get this output when I run `token=test; typeset -p token` -> `declare -- token="test"` – kiner_shah May 23 '21 at 10:06
  • 1
    `typeset -p token` produces `typeset token=token`. Possibly something in zsh/oh-my-zsh – nixgadget May 23 '21 at 10:09
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/232764/discussion-between-kiner-shah-and-nixgadget). – kiner_shah May 23 '21 at 10:13
  • 1
    Are you sure your shell is actually bash and not zsh? bash follows POSIX guidelines that all-lowercase variable names should be safe for applications to use without having special meaning to the shell. zsh does not. – Charles Duffy May 23 '21 at 10:13
  • Mind, I wouldn't be surprised if you had a hook being run that reused the variable name but didn't declare its locals and so was polluting global namespace. If you run `set -x` and inspect the code being run between prompts that should be visible if it's the problem. – Charles Duffy May 23 '21 at 10:15
  • Do you still have the problem during script execution (as opposed to an interactive shell)? That would take a bunch of moving parts of of the picture. – Charles Duffy May 23 '21 at 10:16
  • 1
    @kiner_shah, it's definitely not caused by lack of `export`. The shell will automatically export updates to any previously exported variable (meaning everyone writing `export PATH=...` is doing so unnecessarily). – Charles Duffy May 23 '21 at 10:17
  • Seems it's only isolated to the interactive shell as far as i can tell. – nixgadget May 23 '21 at 10:19
  • 1
    Instead of `bash --version` (which shows us the version of bash first in your PATH), show output of `echo "$BASH_VERSION"`, which shows the actual running shell (which can be a different thing, and moreover will be empty if your active shell isn't actually bash). – Charles Duffy May 23 '21 at 10:22
  • 1
    @KamilCuk updated the question to zsh instead of bash – nixgadget May 23 '21 at 10:22
  • Ah. If it's zsh, this is utterly unsurprising -- because, as described above, zsh doesn't honor POSIX guidelines about all-lowercase variable namespace being reserved for application use. (It's possible to interpret the guidance in the standard as only being relevant to environment as opposed to shell variables, but as both types of variables use the same namespace, I consider that interpretation intentionally obtuse -- not to mention user-hostile for the reasons seen here). – Charles Duffy May 23 '21 at 10:23
  • 1
    Does `zsh -l -i -c 'token=test; echo $token'` reproduces? – KamilCuk May 23 '21 at 10:23
  • `zsh -l -i -c 'token=test; echo $token'` produces `test` – nixgadget May 23 '21 at 10:24
  • 1
    Exact behaviour as described in https://github.com/ohmyzsh/ohmyzsh/issues/9918 – nixgadget May 23 '21 at 10:26
  • 1
    Whatever the problem is, it's not purely with `zsh`. I installed 5.8 using `nix-shell -p zsh` on macOS 10.15, and cannot reproduce the output. – chepner May 23 '21 at 16:44
  • @nixgadget, does `set -x` show anything being assigned to `token`? How about checking the xtrace logs from `zsh -x -l -i` when run interactively? – Charles Duffy May 23 '21 at 18:36
  • 2
    @CharlesDuffy @chepner @KamilCuk thanks for pointing me in the right direction. Looking at the `ohmyzsh` code and `powerlevel10k` in particular it appears to be using it internally. https://github.com/romkatv/powerlevel10k/blob/master/internal/parser.zsh – nixgadget May 23 '21 at 21:49
  • @nixgadget, adding a missing `local token` declaration in that powerlevel10k function may fix your issue. – Charles Duffy May 23 '21 at 22:19
  • Yup it does look like `powerlevel10k` has been patched to fix this now. Thanks for the help to track this down guys. – nixgadget May 24 '21 at 11:14

0 Answers0