# specifying a system-wide path variable



## Alain De Vos (Jun 1, 2021)

How to specify a system-wide path variable, used by including fcron,background-processes and sourced rc scripts and all different shells.


----------



## memreflect (Jun 1, 2021)

Other than setting the PATH yourself in scripts or when executing programs, there may not be an easy way to do what you want.  From my /etc/login.conf:

```
# This PATH may be clobbered by individual applications.  Notably, by default,
# rc(8), service(8), and cron(8) will all override it with a default PATH that
# may not include /usr/local/sbin and /usr/local/bin when starting services or
# jobs.
daemon:\
    :path=/sbin /bin /usr/sbin /usr/bin /usr/local/sbin /usr/local/bin:\
    :mail@:\
    :memorylocked=256M:\
    :tc=default:
```
And service(8) states:

```
ENVIRONMENT
     When used to run rc.d scripts the service command sets HOME to / and PATH
     to /sbin:/bin:/usr/sbin:/usr/bin which is how they are set in /etc/rc at
     boot time.
```
What problem are you facing?  Maybe there's an alternative solution.


----------



## Alain De Vos (Jun 1, 2021)

My current workaround is specifying a full path for every command.
Another workaround would be settting the path variable for every script.


----------



## gpw928 (Jun 1, 2021)

It is imprudent to rely on anything in the environment being "right", and has ever been thus.

All scripts should set (and export) their PATH explicitly.


----------



## covacat (Jun 1, 2021)

gpw928 said:


> It is imprudent to rely on anything in the environment being "right", and has ever been thus.
> 
> All scripts should set (and export) their PATH explicitly.


also binaries that escalate privileges
there were several exploits that were using changed PATH with setuid binaries that executed another binary


----------



## fbsd_ (Jun 1, 2021)

Linux/Unix Most of the shells supports export keyword for making environment variables
There is the usage:
`export EXAMPLE_PATH="/home/username/Desktop"`


----------



## SirDice (Jun 1, 2021)

fbsd_ said:


> Linux/Unix supports export keyword for making environment variables


This isn't a "Linux/Unix" thing, it's specific to Bourne shells (sh(1), bash(1), zsh(1), etc).


----------



## zirias@ (Jun 1, 2021)

Hm, Bourne shells are specified in POSIX  – so, kind of a "Unix thing" 

Anyways, as already mentioned, scripts should not rely on their environment, for security reasons.


----------



## SirDice (Jun 1, 2021)

Zirias said:


> Hm, Bourne shells are specified in POSIX  – so, kind of a "Unix thing"


Still depended on the shell, not the OS.


----------



## zirias@ (Jun 1, 2021)

SirDice said:


> Still depended on the shell, not the OS.


A POSIX (Bourne) shell is part of any POSIX-compliant OS, other shells aren't  Not that it's really important in this context…


----------



## SirDice (Jun 1, 2021)

Zirias said:


> A POSIX (Bourne) shell is part of any POSIX-compliant OS


I don't think that's true though. NT4 was POSIX compliant (certified even) but it didn't have a POSIX shell. 


Zirias said:


> Not that it's really important in this context…


Yeah, sorry, taking this a bit off topic


----------



## zirias@ (Jun 1, 2021)

SirDice said:


> I don't think that's true though. NT4 was POSIX compliant (certified even) but it didn't have a POSIX shell.


Did a quick research on this: You're right, just because "POSIX compliant" lacks some precision. NT4 was POSIX.1 compliant, in a nutshell covering kernel and library APIs. It wasn't POSIX.2 compliant, which covers shell and utilities (like `ls`).
Fun fact: the PowerShell (which is _far_ from a POSIX shell) understands `ls`, hehe…


SirDice said:


> Yeah, sorry, taking this a bit off topic


Hm, indeed. But interesting


----------

