9

I always thought that PS1 was an environment variable. But when I check the default .bashrc of Ubuntu and check for PS1 with

grep PS1 /etc/skel/.bashrc

there is no export PS1.

If there is no export, does it mean that it isn't an environment variable?

Jens
  • 1,738
  • 4
  • 17
  • 36
bob dylan
  • 1,832
  • 3
  • 20
  • 31
  • 1
    Here is a Simple test you can try out quickly : [[A]] In level 1 Bash Process : Execute `PS1=##########` then the Prompt will Change. Now start level 2 `bash` within the same Bash Process, PS1 will revert back in Level 2 Bash Process. Now, Exit this level 2 Bash Process, going back to Level 1 Bash Process [[B]] Execute `export PS1=##########` & Start a new Level 2 Bash Process. You will see that PS1 will not revert. In [[A]] , it was not exported, while in [[B]] , it was exported. This will Confirm that it is not exported by Default. Hence it is not `Environment Variable` by Default. – Prem Sep 17 '22 at 16:09
  • It's an environment variable if it's set as one somewhere. Like you could set `PS1` in `/etc/environment`, and the shell you get at login would read it in from the environment. Though with `PS1` in particular, Bash unsets it if running non-interactively, and sets it to a default value when running interactively if it isn't set, so there's often no _need_ to export it in the environment but there might be need to set it in `bashrc`. But if you _don't_ set it unconditionally in `.bashrc`, you can do things like `PS1='some variant prompt' bash` to run another shell with a modified prompt – ilkkachu Sep 17 '22 at 17:29

1 Answers1

14

The PS1 variable, as well as a few other variables that affect the shell (see the section called Shell Variables in the bash manual), are not exported and are, therefore, not environment variables.

PS1 and some other variables are not environment variables as they do not have to be passed to child processes. For example, the PS1 variable lets the current shell know what the primary prompt should look like, which is probably not something that any other program would be interested in. The same is true for variables like HISTFILE and PROMPT_COMMAND. The bash shell also unsets the PS1 variable when starting up unless the shell is interactive.

As a general rule of thumb, export variables that child processes will need to see. Don't export variables that will only be used within the current shell session (either by the shell itself or by your script or interactive commands).

Note also that even though your shell's initialization files do not export a particular variable, that variable may still be exported by the shell's parent. This is the case for the PATH variable, for example, as well as possibly TERM, SHELL and others. This means these variables don't generally have to be exported again (unless you unset them).

The IFS variable determines how the shell should perform word-splitting and the behaviour of the read built-in utility. The shell generally resets this variable, as using the variable's value from the environment could have unwanted and surprising effects. In general, IFS should never be exported. It is also a good idea not to set and export the CDPATH variable as it affects the behaviour of the cd command, which could disrupt the expected behaviour of scripts.

Kusalananda
  • 320,670
  • 36
  • 633
  • 936
  • So... I don't want to criticize our elders here... but shouldn't it be called ps1 instead of PS1 if it isn't an environment variable ? I really thought it was a convention for environment variables, but I guess some of them are all uppercase nevertheless. – bob dylan Sep 18 '22 at 03:49
  • 3
    @bobdylan See [Are there naming conventions for variables in shell scripts?](https://unix.stackexchange.com/q/42847) (summary: environment variables or variables introduced by the system or shell are usually upper-case). – Kusalananda Sep 18 '22 at 05:47