~tild not working during the boot time

[CuriousMind]

Guru

I wrote a simple script to copy a file to the root diretory like

cp test ~/.

the script was executed by the root.

when I ran it, it worked okay.

but, if I run it during the book time, it will not understand "~" until I change it to

cp test /root/.

can someone please explain to me why?

thanks!

[Dennis Handly]

>to copy a file to the root directory like, cp test ~/.

(This is not THE root directory but the home directory of the current user, root.)

>can someone please explain to me why?

Can you add some debugging to your script:

echo ~ $HOME $PATH

[Matti_Kurkela · Accepted solution]

I think this is sort of an "abstract Unix concepts" question, so knowing the actual name and version of the operating system is not so important.

When you log in, the system sets up a certain environment for you. This environment can be designed to assume that the system is working normally, i.e. all the normal filesystems are mounted and all the user accounts are identifiable.

But when the system is are executing a start-up script, these assumptions may not be true. At early phases of the start-up, some filesystems may not have been mounted yet. If networking has not been started yet, and the system uses something like NIS or LDAP for the majority of its user information, most of the user accounts may not be useable yet. To make things simple and predictable, all start-up scripts are run with the same simplified environment. The exact details will vary from one Linux distribution and version to another (and even more from one Unix-like OS to another), but in general, only a minimal subset of normal environment variables can be expected to be present.

• the PATH environment variable may contain a short list of directories on local filesystems only
• the HOME environment variable can be totally undefined or set to HOME=/
• the environment variables SHELL and TERM may or may not be set to meaningful values
• if the TZ environment variable is needed, it is usually initialized to the configured system default timezone.
• locale-related environment variables (LANG and the LC_* variables) may or may not be set.

In Linux, there is an easy way to see what the environment of the start-up scripts is like.

As root, run:

strings /proc/1/environ

 This will display all the environment variables that are given to init (the mother of all user-space processes) by the kernel and the initrd/initramfs. If your Linux system uses traditional SysVinit, all the other environment variables seen by the startup scripts must be initialized by the init itself or by the "rc" script (usually /sbin/rc, /etc/init.d/rc, /etc/rc.d/rc or similar) that processes the /etc/rc?.d directories, running each script in turn.

[CuriousMind]

excellent, excellent reply!!

thank you!!!!!!!!

Is there a command to know about the path at the boot time then?

curious

[Matti_Kurkela]

There is no standard command for that, but it should be possible to figure it out if you need it.

In Linux, root can view the environment variables of any process through /proc/<PID>/environ, and PATH is one of the environment variables.

If your Unix/Linux distribution uses traditional SysVinit, the ENVIRONMENT section of "man init" will be useful:

---------------------------

ENVIRONMENT
       Init sets the following environment variables for all its children:

       PATH   /bin:/usr/bin:/sbin:/usr/sbin

       INIT_VERSION
              As  the name says. Useful to determine if a script runs directly
              from init.

       RUNLEVEL
              The current system runlevel.

       PREVLEVEL
              The previous runlevel (useful after a runlevel switch).

       CONSOLE
              The system console. This is really inherited  from  the  kernel;
              however  if  it  is  not set init will set it to /dev/console by
              default.

--------------------------------

So the PATH setting for the processes init starts directly will always be as documented.

The next step is to look at /etc/inittab to understand how the startup scripts are called.

Here is the essential part of /etc/inittab from RHEL 5:

id:3:initdefault:

# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit

l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6

 So /etc/rc.d/rc.sysinit is started directly by init and it handles the early boot phase. It will be started as its own process, so any environment variable changes in /etc/rc.d/rc.sysinit will be lost when /etc/rc.d/rc.sysinit ends, unless rc.sysinit starts . (Environment variables are always passed from the parent process to the child, never from child to the parent.)

Then the startup scripts are run by /etc/rc.d/rc. Does it make any changes to the PATH environment variable?

# grep PATH /etc/rc.d/rc
#

 No, it doesn't. So the startup scripts will inherit PATH exactly as provided by init.

The next question is, do the startup scripts for various daemons change the PATH?

# grep PATH /etc/init.d/*
/etc/init.d/auditd:PATH=/sbin:/bin:/usr/bin:/usr/sbin
/etc/init.d/functions:PATH="/sbin:/usr/sbin:/bin:/usr/bin"
/etc/init.d/functions:export PATH
<... a lot of search hits... >

 In RHEL 5, it looks like pretty much every standard startup script explicitly sets its own PATH before starting any daemons!

If your Linux distribution has replaced SysVinit with something else (e.g. Upstart in RHEL 6), it might be more difficult to understand how the environment variables are determined for startup scripts. But if you see that all the standard system startup scripts are setting their own PATH, then you definitely should do it too when making your own startup scripts. It is easy to do and will guarantee that your startup script will always have a consistent PATH, no matter how it is called.