Solved set env, export not saving on reboot

SoBe

SoBe

Hello fellow freeBSD community members,

Can you please help?

How can I make sure that the env setting stay for the next reboot?

setnev does not work


Screenshot 2024-07-16 at 22.22.54.png
Screenshot 2024-07-16 at 22.23.27.png

set env does however it does not save on reboot.

What conf file should I save this in?
 
setenv(1) is a tcsh(1) builtin, it's not for sh(1).

Setting variables doesn't persist, a variable's existence ends when the shell exits. For Bourne type shells (sh(1)/bash(1) for example) you use export so a subshell 'inherits' the variable. If you don't export the variable a subshell won't know it.

Code: 
# echo $FOO

# FOO="BAR"
# echo $FOO
BAR
# sh                                                       <----- subshell
# echo $FOO

# ^D                                                      <----- exit subshell, going back to 'parent' 
# echo $FOO
BAR
# export FOO
# sh
# echo $FOO
BAR
#

If you want to "save" that variable you need to add it to ~/.shrc, it's one of the scripts that get started each time you start a sh(1).

Code: 
   Invocation
     If no arguments are present and if the standard input of the shell is
     connected to a terminal (or if the -i option is set), the shell is
     considered an interactive shell.  An interactive shell generally prompts
     before each command and handles programming and command errors
     differently (as described below).  When first starting, the shell
     inspects argument 0, and if it begins with a dash (‘-’), the shell is
     also considered a login shell.  This is normally done automatically by
     the system when the user first logs in.  A login shell first reads
     commands from the files /etc/profile and then .profile in a user's home
     directory, if they exist.  If the environment variable ENV is set on
     entry to a shell, or is set in the .profile of a login shell, the shell
     then subjects its value to parameter expansion and arithmetic expansion
     and reads commands from the named file.  Therefore, a user should place
     commands that are to be executed only at login time in the .profile file,
     and commands that are executed for every shell inside the ENV file.  The
     user can set the ENV variable to some file by placing the following line
     in the file .profile in the home directory, substituting for .shrc the
     filename desired:

           ENV=$HOME/.shrc; export ENV

     The first non-option argument specified on the command line will be
     treated as the name of a file from which to read commands (a shell
     script), and the remaining arguments are set as the positional parameters
     of the shell ($1, $2, etc.).  Otherwise, the shell reads commands from
     its standard input.

     Unlike older versions of sh the ENV script is only sourced on invocation
     of interactive shells.  This closes a well-known, and sometimes easily
     exploitable security hole related to poorly thought out ENV scripts.
 
SirDice said:
setenv(1) is a tcsh(1) builtin, it's not for sh(1).

Setting variables doesn't persist, a variable's existence ends when the shell exits. For Bourne type shells (sh(1)/bash(1) for example) you use export so a subshell 'inherits' the variable. If you don't export the variable a subshell won't know it.

Code: 
# echo $FOO

# FOO="BAR"
# echo $FOO
BAR
# sh                                                       <----- subshell
# echo $FOO

# ^D                                                      <----- exit subshell, going back to 'parent'
# echo $FOO
BAR
# export FOO
# sh
# echo $FOO
BAR
#

If you want to "save" that variable you need to add it to ~/.shrc, it's one of the scripts that get started each time you start a sh(1).

Code: 
   Invocation
     If no arguments are present and if the standard input of the shell is
     connected to a terminal (or if the -i option is set), the shell is
     considered an interactive shell.  An interactive shell generally prompts
     before each command and handles programming and command errors
     differently (as described below).  When first starting, the shell
     inspects argument 0, and if it begins with a dash (‘-’), the shell is
     also considered a login shell.  This is normally done automatically by
     the system when the user first logs in.  A login shell first reads
     commands from the files /etc/profile and then .profile in a user's home
     directory, if they exist.  If the environment variable ENV is set on
     entry to a shell, or is set in the .profile of a login shell, the shell
     then subjects its value to parameter expansion and arithmetic expansion
     and reads commands from the named file.  Therefore, a user should place
     commands that are to be executed only at login time in the .profile file,
     and commands that are executed for every shell inside the ENV file.  The
     user can set the ENV variable to some file by placing the following line
     in the file .profile in the home directory, substituting for .shrc the
     filename desired:

           ENV=$HOME/.shrc; export ENV

     The first non-option argument specified on the command line will be
     treated as the name of a file from which to read commands (a shell
     script), and the remaining arguments are set as the positional parameters
     of the shell ($1, $2, etc.).  Otherwise, the shell reads commands from
     its standard input.

     Unlike older versions of sh the ENV script is only sourced on invocation
     of interactive shells.  This closes a well-known, and sometimes easily
     exploitable security hole related to poorly thought out ENV scripts.
Click to expand...
Thank you that fixed my issue!!
 
You must log in or register to reply here.
Back
Top