2

I know that environment variables are set through reading or executing several configuration files, such as /etc/environment, /etc/profile, ~/.profile, ~/.bashrc, etc.

But when I was reading this blog post, I tried to start a non-login interactive bash shell without importing environment, using the following command:

 osboxes@osboxes:~$ env -i bash

After getting into the new shell, I checked the PATH variable, and got the following result:

osboxes@osboxes:/home/osboxes$ echo $PATH
/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.

As far as I know, this non-login interactive shell doesn't read /etc/environment or source /etc/profile or ~/.profile; it only sources /etc/bash.bashrc and ~/.bashrc.

So how is the PATH variable in this shell set? Is there a specific file to read or source from?

  • 1
    What does your ~/.bashrc file do? You could try also setting HOME to some other directory to avoid picking up that file at all, or use --norc. There will still be a PATH though, if not for any other reason than that the shell assumes a minimal PATH value which is hardcoded into the bash executable. – Kusalananda Nov 1 '18 at 9:12
1

Check that printenv has no value for PATH. If you find something, it's probably from your ~/.bashrc. If it's empty, it's been set by Bash itself. When the shell starts, if it cannot find a value for PATH, it will set one, because very little will work without PATH.

You can see how this is done in the source code (I am looking at the source of Bash 4.4.18, on Ubuntu 18.04):

In variables.c:

  /* Now make our own defaults in case the vars that we think are
     important are missing. */
  temp_var = set_if_not ("PATH", DEFAULT_PATH_VALUE);
#if 0
  set_auto_export (temp_var);   /* XXX */
#endif

In config-top.h you can find the definition (which matches the PATH you show):

/* The default value of the PATH variable. */
#ifndef DEFAULT_PATH_VALUE
#define DEFAULT_PATH_VALUE \
  "/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:."
#endif

I believe it is often considered bad practice to put . in PATH because it makes it very easy to accidentally execute things!

1

As the Bourne Again shell's manual explains, there is a default value for the PATH shell variable, if there is no PATH environment variable to initialize it from and the shell variable is not set in a startup script.

What that value is depends from is, according to the manual, "the system administrator who installs bash". In fact, it depends from what options were chosen by the person who compiled the Bourne Again shell from source.

  • In Debian's package of the Bourne Again shell it is close to the example default from the manual:
    % unsetenv PATH `command -v bash` -c 'echo $PATH ; printenv PATH'
    /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.
    %
  • In the OpenBSD port/package of the Bourne Again shell it is the same:
    $ unsetenv PATH `command -v bash` -c 'echo $PATH ; printenv PATH'
    /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.
    $
  • In the FreeBSD port/package of the Bourne Again shell it was somewhat broken:
    % unsetenv PATH `command -v bash` -c 'echo $PATH ; printenv PATH'
    /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:%%LOCALBASE%%/sbin:%%LOCALBASE%%/bin
    %
    This was adjusted in March 2017 by tweaking the compiler options used to build the software.

The fact that printenv does not print a line tells you that this default PATH shell variable is not exported to an environment variable, incidentally.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.