Why should anyone ever put anything in /etc/zshenv or ~/.zshenv? [closed]
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
There is already a question "What should/shouldn't go in .zshenv, .zshrc, .zlogin, .zprofile, .zlogout?".
I'm wondering why anyone ever puts anything in /etc/zshenv or ~/.zshenv. For those who are unfamiliar, these files are generally sourced on every zsh invocation, even when it is executing a script file. Sourcing of the global file cannot be overridden; sourcing the local file can be prevented by executing zsh as zsh -f.
It just seems like a bad idea to have configuration files which change the behavior of all my Zsh scripts. Doesn't even the existence of this feature make Zsh scripts highly non-portable? I remember experiencing problems where system administrators put things in /etc/zshenv which break my scripts or severely slow them.
And let's suppose that I only use ~/.zshenv to export environment variables - why should it be that I can temporarily override one of these variables when executing a Bash script, or a Perl script, but not a Zsh script? And why not simply configure these variables in ~/.zprofile, which is sourced with every login shell? The nature of environment variables is that they are inherited, so this would seem to be enough. If I need these variables in a cron job, I can execute it with zsh -cl...
shell-script zsh portability
asked Aug 29 at 6:07
Metamorphic
23115
closed as primarily opinion-based by Kiwy, Jeff Schaller, countermode, schily, msp9011 Aug 29 at 13:05
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |Â
up vote
1
down vote
favorite
There is already a question "What should/shouldn't go in .zshenv, .zshrc, .zlogin, .zprofile, .zlogout?".
I'm wondering why anyone ever puts anything in /etc/zshenv or ~/.zshenv. For those who are unfamiliar, these files are generally sourced on every zsh invocation, even when it is executing a script file. Sourcing of the global file cannot be overridden; sourcing the local file can be prevented by executing zsh as zsh -f.
It just seems like a bad idea to have configuration files which change the behavior of all my Zsh scripts. Doesn't even the existence of this feature make Zsh scripts highly non-portable? I remember experiencing problems where system administrators put things in /etc/zshenv which break my scripts or severely slow them.
And let's suppose that I only use ~/.zshenv to export environment variables - why should it be that I can temporarily override one of these variables when executing a Bash script, or a Perl script, but not a Zsh script? And why not simply configure these variables in ~/.zprofile, which is sourced with every login shell? The nature of environment variables is that they are inherited, so this would seem to be enough. If I need these variables in a cron job, I can execute it with zsh -cl...
shell-script zsh portability
asked Aug 29 at 6:07
Metamorphic
23115
closed as primarily opinion-based by Kiwy, Jeff Schaller, countermode, schily, msp9011 Aug 29 at 13:05
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
Maybe you need to share a same variable or want everyone to have the same profile, there's hundred reason why anyone would do anything. Your question is opinion base though.
– Kiwy
Aug 29 at 8:01
1
~/.zprofileis not sourced for commands executed over rshd/sshd, or cron jobs...~/.zshenvcan be used to fix wrong system defaults as a user for instance. It can be used to implement some debugging or any time you'd need something to be run for every zsh invocation. Most shells have an equivalent like bash's$BASH_ENV. Allcshinvocations read ~/.cshrc (which is why you see#! /bin/csh -fin she-bangs).
– Stéphane Chazelas
Aug 29 at 16:11
Thanks for the list of possibilities. FWIW I realize that I'm using~/.zshenvto make sure that~/.zprofilegets sourced forsshcommands.if [ -z "$SOURCED_ZPROFILE" ]; then . $ZDOTDIR:-$HOME/.zprofile; fi(then that variable is set at the end of.zprofile). But there is nothing else in there. Seems a bit powerful for debugging but that is an interesting thought.
– Metamorphic
Aug 29 at 21:12
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
There is already a question "What should/shouldn't go in .zshenv, .zshrc, .zlogin, .zprofile, .zlogout?".
I'm wondering why anyone ever puts anything in /etc/zshenv or ~/.zshenv. For those who are unfamiliar, these files are generally sourced on every zsh invocation, even when it is executing a script file. Sourcing of the global file cannot be overridden; sourcing the local file can be prevented by executing zsh as zsh -f.
It just seems like a bad idea to have configuration files which change the behavior of all my Zsh scripts. Doesn't even the existence of this feature make Zsh scripts highly non-portable? I remember experiencing problems where system administrators put things in /etc/zshenv which break my scripts or severely slow them.
And let's suppose that I only use ~/.zshenv to export environment variables - why should it be that I can temporarily override one of these variables when executing a Bash script, or a Perl script, but not a Zsh script? And why not simply configure these variables in ~/.zprofile, which is sourced with every login shell? The nature of environment variables is that they are inherited, so this would seem to be enough. If I need these variables in a cron job, I can execute it with zsh -cl...
shell-script zsh portability
asked Aug 29 at 6:07
Metamorphic
23115
There is already a question "What should/shouldn't go in .zshenv, .zshrc, .zlogin, .zprofile, .zlogout?".
I'm wondering why anyone ever puts anything in /etc/zshenv or ~/.zshenv. For those who are unfamiliar, these files are generally sourced on every zsh invocation, even when it is executing a script file. Sourcing of the global file cannot be overridden; sourcing the local file can be prevented by executing zsh as zsh -f.
It just seems like a bad idea to have configuration files which change the behavior of all my Zsh scripts. Doesn't even the existence of this feature make Zsh scripts highly non-portable? I remember experiencing problems where system administrators put things in /etc/zshenv which break my scripts or severely slow them.
And let's suppose that I only use ~/.zshenv to export environment variables - why should it be that I can temporarily override one of these variables when executing a Bash script, or a Perl script, but not a Zsh script? And why not simply configure these variables in ~/.zprofile, which is sourced with every login shell? The nature of environment variables is that they are inherited, so this would seem to be enough. If I need these variables in a cron job, I can execute it with zsh -cl...
shell-script zsh portability
shell-script zsh portability
asked Aug 29 at 6:07
Metamorphic
23115
asked Aug 29 at 6:07
Metamorphic
23115
asked Aug 29 at 6:07
Metamorphic
23115
asked Aug 29 at 6:07
Metamorphic
23115
asked Aug 29 at 6:07
Metamorphic
23115
23115
closed as primarily opinion-based by Kiwy, Jeff Schaller, countermode, schily, msp9011 Aug 29 at 13:05
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as primarily opinion-based by Kiwy, Jeff Schaller, countermode, schily, msp9011 Aug 29 at 13:05
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
Maybe you need to share a same variable or want everyone to have the same profile, there's hundred reason why anyone would do anything. Your question is opinion base though.
– Kiwy
Aug 29 at 8:01
1
~/.zprofileis not sourced for commands executed over rshd/sshd, or cron jobs...~/.zshenvcan be used to fix wrong system defaults as a user for instance. It can be used to implement some debugging or any time you'd need something to be run for every zsh invocation. Most shells have an equivalent like bash's$BASH_ENV. Allcshinvocations read ~/.cshrc (which is why you see#! /bin/csh -fin she-bangs).
– Stéphane Chazelas
Aug 29 at 16:11
Thanks for the list of possibilities. FWIW I realize that I'm using~/.zshenvto make sure that~/.zprofilegets sourced forsshcommands.if [ -z "$SOURCED_ZPROFILE" ]; then . $ZDOTDIR:-$HOME/.zprofile; fi(then that variable is set at the end of.zprofile). But there is nothing else in there. Seems a bit powerful for debugging but that is an interesting thought.
– Metamorphic
Aug 29 at 21:12
add a comment |Â
Maybe you need to share a same variable or want everyone to have the same profile, there's hundred reason why anyone would do anything. Your question is opinion base though.
– Kiwy
Aug 29 at 8:01
1
~/.zprofileis not sourced for commands executed over rshd/sshd, or cron jobs...~/.zshenvcan be used to fix wrong system defaults as a user for instance. It can be used to implement some debugging or any time you'd need something to be run for every zsh invocation. Most shells have an equivalent like bash's$BASH_ENV. Allcshinvocations read ~/.cshrc (which is why you see#! /bin/csh -fin she-bangs).
– Stéphane Chazelas
Aug 29 at 16:11
Thanks for the list of possibilities. FWIW I realize that I'm using~/.zshenvto make sure that~/.zprofilegets sourced forsshcommands.if [ -z "$SOURCED_ZPROFILE" ]; then . $ZDOTDIR:-$HOME/.zprofile; fi(then that variable is set at the end of.zprofile). But there is nothing else in there. Seems a bit powerful for debugging but that is an interesting thought.
– Metamorphic
Aug 29 at 21:12
Maybe you need to share a same variable or want everyone to have the same profile, there's hundred reason why anyone would do anything. Your question is opinion base though.
– Kiwy
Aug 29 at 8:01
Maybe you need to share a same variable or want everyone to have the same profile, there's hundred reason why anyone would do anything. Your question is opinion base though.
– Kiwy
Aug 29 at 8:01
1
1
~/.zprofile is not sourced for commands executed over rshd/sshd, or cron jobs... ~/.zshenv can be used to fix wrong system defaults as a user for instance. It can be used to implement some debugging or any time you'd need something to be run for every zsh invocation. Most shells have an equivalent like bash's $BASH_ENV. All csh invocations read ~/.cshrc (which is why you see #! /bin/csh -f in she-bangs).– Stéphane Chazelas
Aug 29 at 16:11
~/.zprofile is not sourced for commands executed over rshd/sshd, or cron jobs... ~/.zshenv can be used to fix wrong system defaults as a user for instance. It can be used to implement some debugging or any time you'd need something to be run for every zsh invocation. Most shells have an equivalent like bash's $BASH_ENV. All csh invocations read ~/.cshrc (which is why you see #! /bin/csh -f in she-bangs).– Stéphane Chazelas
Aug 29 at 16:11
Thanks for the list of possibilities. FWIW I realize that I'm using
~/.zshenv to make sure that ~/.zprofile gets sourced for ssh commands. if [ -z "$SOURCED_ZPROFILE" ]; then . $ZDOTDIR:-$HOME/.zprofile; fi (then that variable is set at the end of .zprofile). But there is nothing else in there. Seems a bit powerful for debugging but that is an interesting thought.– Metamorphic
Aug 29 at 21:12
Thanks for the list of possibilities. FWIW I realize that I'm using
~/.zshenv to make sure that ~/.zprofile gets sourced for ssh commands. if [ -z "$SOURCED_ZPROFILE" ]; then . $ZDOTDIR:-$HOME/.zprofile; fi (then that variable is set at the end of .zprofile). But there is nothing else in there. Seems a bit powerful for debugging but that is an interesting thought.– Metamorphic
Aug 29 at 21:12
add a comment |Â
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Maybe you need to share a same variable or want everyone to have the same profile, there's hundred reason why anyone would do anything. Your question is opinion base though.
– Kiwy
Aug 29 at 8:01
1
~/.zprofileis not sourced for commands executed over rshd/sshd, or cron jobs...~/.zshenvcan be used to fix wrong system defaults as a user for instance. It can be used to implement some debugging or any time you'd need something to be run for every zsh invocation. Most shells have an equivalent like bash's$BASH_ENV. Allcshinvocations read ~/.cshrc (which is why you see#! /bin/csh -fin she-bangs).– Stéphane Chazelas
Aug 29 at 16:11
Thanks for the list of possibilities. FWIW I realize that I'm using
~/.zshenvto make sure that~/.zprofilegets sourced forsshcommands.if [ -z "$SOURCED_ZPROFILE" ]; then . $ZDOTDIR:-$HOME/.zprofile; fi(then that variable is set at the end of.zprofile). But there is nothing else in there. Seems a bit powerful for debugging but that is an interesting thought.– Metamorphic
Aug 29 at 21:12