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?

2
  • 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, 2022 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, 2022 at 17:29

1 Answer 1

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.

2
  • 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, 2022 at 3:49
  • 3
    @bobdylan See Are there naming conventions for variables in shell scripts? (summary: environment variables or variables introduced by the system or shell are usually upper-case).
    – Kusalananda
    Sep 18, 2022 at 5:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .