105.1 Lesson 1

Certificate:

LPIC-1

Version:

5.0

Topic:

105 Shells and Shell Scripting

Objective:

105.1 Customize and use the shell environment

Lesson:

1 of 3

Introduction

The shell is arguably the most powerful tool in a Linux system and can be defined as an interface between the user and the kernel of the operating system. It interprets commands entered by the user. Therefore, all system administrators must be skilled in using the shell. As we may certainly know by now, the Bourne Again Shell (Bash) is the de facto shell for the vast majority of Linux distributions.

Once started, the first thing Bash — or any other shell for that matter — does is executing a series of startup scripts. These scripts customize the session’s environment. There are both system wide and user specific scripts. We can put our personal preferences or settings that best fit our users' needs in these scripts in the form of variables, aliases and functions.

The exact series of startup files depends on a very important parameter: the type of shell. Let us have a look at the variety of shells that exist.

Shell Types: Interactive vs. Non-Interactive and Login vs. Non-Login

To start with, let us clarify the concepts of interactive and login in the context of shells:

Interactive / Non-interactive Shells: This kind of shell refers to the interaction that takes place between the user and the shell: The user provides input by typing commands into the terminal using the keyboard; the shell provides output by printing messages on the screen.
Login / Non-login Shells: This kind of shell refers to the event of a user accessing a computer system providing its credentials, such as username and password.

Both interactive and non-interactive shells can be either login or non-login and any possible combination of these types has its specific uses.

Interactive login shells are executed when users log into the system and are used to customize users' configurations according to their needs. A good example of this type of shell would be that of a group of users belonging to the same department who need a particular variable set in their sessions.

By interactive non-login shells we refer to any other shells opened by the user after logging into the system. Users use these shells during sessions to carry out maintenance and administrative tasks such as setting variables, the time, copying files, writing scripts, etc.

On the other hand, non-interactive shells do not require any kind of human interaction. Thus, these shells do not ask the user for input and their output — if any — is in most cases written to a log.

Non-interactive login shells are quite rare and impractical. Their uses are virtually non-existent and we will only comment on them for the sake of insight into shell behaviour. Some odd examples include forcing a script to be run from a login shell with /bin/bash --login <some_script> or piping the standard output (stdout) of a command into the standard input (stdin) of an ssh connection:

<some_command> | ssh <some_user>@<some_server>

As for non-interactive non-login shell there is neither interaction nor login on behalf of the user, so we are referring here to the use of automated scripts. These scripts are mostly used to carry out repetitive administrative and maintenance tasks such as those included in cronjobs. In such cases, bash does not read any startup files.

Opening a Terminal

When we are in a desktop environment, we can either open a terminal application or switch to one of the system consoles. Therefore, a new shell is either a pts shell when opened from a terminal emulator in the GUI or a tty shell when run from a system console. In the first case we are not dealing with a terminal but with a terminal emulator. As part of graphical sessions, terminal emulators like gnome-terminal or konsole are very feature-rich and user-friendly as compared to text-based user interface terminals. Less feature-rich terminal emulators include — amongst others — XTerm and sakura.

Using the Ctrl+Alt+F1-F6 combos we can go to the console logins which open an interactive text-based login shell. Ctrl+Alt+F7 will take the session back into the Desktop.

Note	`tty` stands for teletypewritter; `pts` stands for pseudo terminal slave. For more information: `man tty` and `man pts`.

Launching Shells with `bash`

After logging in, type bash into a terminal to open a new shell. Technically, this shell is a child process of the current shell.

While starting the bash child process, we can specify various switches to define which kind of shell we want to start. Here some important bash invocation options:

bash -l or bash --login: will invoke a login shell.
bash -i: will invoke an interactive shell.
bash --noprofile: with login shells will ignore both the system-wide startup file /etc/profile and the user-level startup files ~/.bash_profile, ~/.bash_login and ~/.profile.
bash --norc: with interactive shells will ignore both the system-wide startup file /etc/bash.bashrc and the user-level startup file ~/.bashrc.
bash --rcfile <file>: with interactive shells will take <file> as the startup file ignoring system wide /etc/bash.bashrc and user-level ~/.bashrc.

We will discus the various startup files below.

Launching Shells with `su` and `sudo`

Through the use of these two similar programs we can obtain specific types of shells:

su

Change user ID or become superuser (root). With this command we can invoke both login and non-login shells:

su - user2, su -l user2 or su --login user2 will start an interactive login shell as user2.
su user2 will start an interactive non-login shell as user2.
su - root or su - will start an interactive login shell as root.
su root or su will start an interactive non-login shell as root.

sudo

Execute commands as another user (including the supersuser). Because this command is mainly used to gain root privileges temporarily, the user using it must be in the sudoers file. To add users to sudoers we need to become root and then run:

root@debian:~# usermod -aG sudo user2

Just as su, sudo allows us to invoke both login and non-login shells:

sudo su - user2, sudo su -l user2 or sudo su --login user2 will start an interactive login shell as user2.
sudo su user2 will start an interactive non-login shell as user2.
sudo -u user2 -s will start an interactive non-login shell as user2.
sudo su - root or sudo su - will start an interactive login shell as root.
sudo -i will start an interactive login shell as root.
sudo -i <some_command> will start an interactive login shell as root, run the command and return to the original user.
sudo su root or sudo su will start an interactive non-login shell as root.
sudo -s or sudo -u root -s will start a non-login shell as root.

When using either su or sudo, it is important to consider our particular case scenario for starting a new shell: Do we need the target user’s environment or not? If so, we would use the options which invoke login shells; if not, those which invoke non-login shells.

What Shell Type Do We Have?

In order to find out what type of shell we are working at, we can type echo $0 into the terminal and get the following output:

Interactive login: -bash or -su
Interactive non-login: bash or /bin/bash
Non-interactive non-login (scripts): <name_of_script>

How Many Shells Do We Have?

To see how many bash shells we have up and running in the system, we can use the command ps aux | grep bash:

user2@debian:~$ ps aux | grep bash
user2       5270  0.1  0.1  25532  5664 pts/0    Ss   23:03   0:00 bash
user2       5411  0.3  0.1  25608  5268 tty1     S+   23:03   0:00 -bash
user2       5452  0.0  0.0  16760   940 pts/0    S+   23:04   0:00 grep --color=auto bash

user2 at debian has logged into a GUI (or X Window System) session and opened gnome-terminal, then she has pressed Ctrl+Alt+F1 to go into a tty terminal session. Finally, she has gone back to the GUI session by pressing Ctrl+Alt+F7 and typed in the command ps aux | grep bash. Thus, the output shows an interactive non-login shell via the terminal emulator (pts/0) and an interactive login shell via the proper text-based terminal (tty1). Note also how the last field of each line (the command) is bash for the former and -bash for the latter.

Where Shells Get their Configuration From: Startup Files

Well, now that we know the shell types that we can find in a Linux system, it is high time that we saw what startup files get executed by what shell. Note that system wide or global scripts are placed in the /etc/ directory, whereas local or user-level ones are found in the user’s home (~). Also, when there is more than one file to be searched, once one is found and run the others are ignored. Explore and study these files yourself with your favorite text editor or by typing less <startup_file>.

Note	Startup files can be divided into Bash specific (those limited only to `bash` configurations and commands) and general ones (relating to most shells).

Interactive Login Shell

Global Level

/etc/profile: This is the system-wide .profile file for the Bourne shell and Bourne compatible shells (bash included). Through a series of if statements this file sets a number of variables such as PATH and PS1 accordingly as well as sourcing — if they exist — both the file /etc/bash.bashrc and those in the directory /etc/profile.d.
/etc/profile.d/*: This directory may contain scripts that get executed by /etc/profile.

Local Level

~/.bash_profile: This Bash specific file is used for configuring the user environment. It can also be used to source both ~/.bash_login and ~/.profile.
~/.bash_login: Also Bash specific, this file will only be executed if there is no ~/.bash_profile file. Its name suggests that it should be used to run commands needed on login.
~/.profile: This file is not Bash specific and gets sourced only if neither ~/.bash_profile nor ~/.bash_login exist — which is normally the case. Thus, the main purpose of ~/.profile is that of checking if a Bash shell is being run and — if so — sourcing ~/.bashrc if it exists. It usually sets the variable PATH so that it includes the user’s private ~/bin directory if it exists.
~/.bash_logout: If it exists, this Bash specific file does some clean-up operations when exiting the shell. This can be convenient in such cases as those in remote sessions.

Exploring Interactive Login Shell Configuration Files

Let us show some of these files in action by modifying /etc/profile and /home/user2/.profile. We will append to each a line reminding us the file being executed:

root@debian:~# echo 'echo Hello from /etc/profile' >> /etc/profile
root@debian:~# echo 'echo Hello from ~/.profile' >> ~/.profile

Note	Two redirection operators `>>` append the output of a command into an existing file — not overwriting it. If the file does not exist, though, it will be created.

Thus, through the output of their respective echo commands we will know when each of these files is read and executed. To prove it, let us see what happens when user2 logs in via ssh from another machine:

user2@debian:~$ ssh user2@192.168.1.6
user2@192.168.1.6's password:
Linux debian 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Nov 27 19:57:19 2018 from 192.168.1.10
Hello from /etc/profile
Hello from /home/user2/.profile

As the last two lines show, it worked. Also, note three things:

The global file was run first.
There were no .bash_profile or .bash_login files in he home directory of user2.
The tilde (~) expanded to the absolute path of the file (/home/user2/.profile).

Interactive Non-Login Shell

Global Level

/etc/bash.bashrc: This is the system-wide .bashrc file for interactive bash shells. Through its execution bash makes sure it is being run interactively, checks the window size after each command (updating the values of LINES and COLUMNS if necessary) and sets some variables.

Local Level

~/.bashrc: In addition to carrying out similar tasks to those described for /etc/bash.bashrc at a user level (such as checking the window size or if being run interactively), this Bash specific file usually sets some history variables and sources ~/.bash_aliases if it exists. Apart from that, this file is normally used to store users' specific aliases and functions.

Likewise, it is also worthwhile noting that ~/.bashrc is read if bash detects its <stdin> is a network connection (as it was the case with the Secure Shell (SSH) connection in the example above).

Exploring Interactive Non-Login Shell Configuration Files

Let us now modify /etc/bash.bashrc and /home/user2/.bashrc:

root@debian:~# echo 'echo Hello from /etc/bash.bashrc' >> /etc/bash.bashrc
root@debian:~# echo 'echo Hello from ~/.bashrc' >> ~/.bashrc

And this is what happens when user2 starts a new shell:

user2@debian:~$ bash
Hello from /etc/bash.bashrc
Hello from /home/user2/.bashrc

Again, the two files were read and executed.

Warning

Remember, because of the order in which files are run, local files take precedence over global ones.

Non-Interactive Login Shell

A non-interactive shell with the -l or --login options is forced to behave like a login shell and so the startup files to be run will be the same as those for interactive login shells.

To prove it, let us write a simple script and make it executable. We will not include any shebangs because we will be invoking the bash executable (/bin/bash with the login option) from the command line.

We create the script test.sh containing the line echo 'Hello from a script' so that we can prove the script runs successfully:
```
user2@debian:~$ echo "echo 'Hello from a script'" > test.sh
```
We make our script executable:
```
user2@debian:~$ chmod +x ./test.sh
```
Finally, we invoke bash with the -l option to run the script:
```
user2@debian:~$ bash -l ./test.sh
Hello from /etc/profile
Hello from /home/user2/.profile
Hello from a script
```
It works! Before running the script, the login took place and both /etc/profile and ~/.profile were executed.

Note	We will learn about shebangs and all other aspects of shell scripting in future lessons.

Let us now have the standard output (stdout) of the echo command into the standard input (stdin) of an ssh connection by means of a pipe (|):

user2@debian:~$ echo "Hello-from-a-noninteractive-login-shell" | ssh user2@192.168.1.6
Pseudo-terminal will not be allocated because stdin is not a terminal.
user2@192.168.1.6's password:
Linux debian 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Hello from /etc/profile
Hello from /home/user2/.profile
-bash: line 1: Hello-from-a-noninteractive-login-shell: command not found

Again, /etc/profile and ~/.profile are executed. Other than that, the first and last lines of the output are quite telling as far as the behaviour of the shell is concerned.

Non-Interactive Non-Login Shell

Scripts do not read any of the files listed above but look for the environment variable BASH_ENV, expand its value if needed and use it as the name of a startup file to read and execute commands. We will learn more about environment variables in the next lesson.

As mentioned above, typically /etc/profile and ~/.profile make sure that both /etc/bash.bashrc and ~/.bashrc get executed after a successful login. The output of the following command shows this phenomenon:

root@debian:~# su - user2
Hello from /etc/bash.bashrc
Hello from /etc/profile
Hello from /home/user2/.bashrc
Hello from /home/user2/.profile

Bearing in mind the lines we previously appended to the startup scripts — and invoking an interactive-login shell at user-level with su - user2 — the four lines of output can be explained as follows:

Hello from /etc/bash.bashrc means /etc/profile has sourced /etc/bash.bashrc.
Hello from /etc/profile means /etc/profile has been fully read and executed.
Hello from /home/user2/.bashrc means ~/.profile has sourced ~/.bashrc.
Hello from /home/user2/.profile means ~/.profile has been fully read and executed.

Note how with su - <username> (also su -l <username> and su --login <username>) we guarantee the invocation of a login shell, whereas su <username> would have only invoked /etc/bash.bashrc and ~/.bashrc.

Sourcing Files

In the previous sections we have discussed that some startup scripts include or execute other scripts. This mechanism is called sourcing and is explained in this section.

Sourcing Files with `.`

The dot (.) is normally found in startup files.

In the .profile file of our Debian server we can find — for instance — the following block:

    # include .bashrc if it exists
    if [ -f "$HOME/.bashrc" ]; then
	. "$HOME/.bashrc"
    fi

We already saw how the execution of a script may lead to that of another. Thus, the if statement guarantees that the file $HOME/.bashrc — if it exists (-f) — will be sourced (i.e. read and executed) at login:

. "$HOME/.bashrc"

Note	As we will learn in the next lesson, `$HOME` is an environment variable that expands to the absolute path of the user’s home directory.

Furthermore, we can use the . whenever we have modified a startup file and want to make the changes effective without a reboot. For example we can:

add an alias to ~/.bashrc:

user2@debian:~$ echo "alias hi='echo We salute you.'" >> ~/.bashrc

Warning

When sending the output of one command into a file, remember not to mistake append (>>) with overwrite (>).

output the last line of ~/.bashrc to check everything went fine:
```
user2@debian:~$ tail -n 1 !$
tail -n 1 ~/.bashrc
alias hi='echo We salute you.'
```
Note

!$ expands to the last argument from the previous command, in our case: ~/.bashrc.
source the file by hand:
```
user2@debian:~$ . ~/.bashrc
```
and invoke the alias to prove it works:
```
user2@debian:~$ hi
We salute you.
```

Note	Refer to the next lesson to learn about aliases and variables.

Sourcing Files with `source`

The source command is a synonym for .. So to source ~/.bashrc we can also do it like this:

user2@debian:~$ source ~/.bashrc

The Origin of Shell Startup Files: `SKEL`

SKEL is a variable whose value is the absolute path to the skel directory. This directory serves as a template for the file system structure of users' home directories. It includes the files that will be inherited by any new user accounts created (including, of course, the configuration files for shells). SKEL and other related variables are stored in /etc/adduser.conf, which is the configuration file for adduser:

user2@debian:~$ grep SKEL /etc/adduser.conf
# The SKEL variable specifies the directory containing "skeletal" user
SKEL=/etc/skel
# If SKEL_IGNORE_REGEX is set, adduser will ignore files matching this
SKEL_IGNORE_REGEX="dpkg-(old|new|dist|save)"

SKEL is set to /etc/skel; thus, the startup scripts that configure our shells lie therein:

user2@debian:~$ ls -a /etc/skel/
.  ..  .bash_logout  .bashrc  .profile

Warning

Remember, files starting with a . are hidden, so we must use ls -a to see them when listing directory contents.

Let us now create a directory in /etc/skel for all new users to store their personal scripts in:

As root we move into /etc/skel:

root@debian:~# cd /etc/skel/
root@debian:/etc/skel#

We list its contents:

root@debian:/etc/skel# ls -a
.  ..  .bash_logout  .bashrc  .profile

We create our directory and check all went as expected:

root@debian:/etc/skel# mkdir my_personal_scripts
root@debian:/etc/skel# ls -a
.  ..  .bash_logout  .bashrc  my_personal_scripts  .profile

Now we delete user2 together with its home directory:

root@debian:~# deluser --remove-home user2
Looking for files to backup/remove ...
Removing files ...
Removing user `user2' ...
Warning: group `user2' has no more members.
Done.

We add user2 again so that it gets a new home directory:

root@debian:~# adduser user2
Adding user `user2' ...
Adding new group `user2' (1001) ...
Adding new user `user2' (1001) with group `user2' ...
Creating home directory `/home/user2' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for user2
Enter the new value, or press ENTER for the default
	Full Name []:
	Room Number []:
	Work Phone []:
	Home Phone []:
	Other []:
Is the information correct? [Y/n] y

Finally, we login as user2 and list all the files in /home/user2 to see if everything went as expected:

root@debian:~# su - user2
user2@debian:~$ pwd
/home/user2
user2@debian:~$ ls -a
.  ..  .bash_history  .bash_logout  .bashrc  my_personal_scripts  .profile

It did.

Guided Exercises

Study how the shells have been started under the column “Shell Started with…” and complete with the required information:

Shell Started with… Interactive? Login? Result of echo $0

sudo ssh user2@machine2

Ctrl+Alt+F2

su - user2

gnome-terminal

A regular user uses konsole to start an instance of sakura

A script named test.sh containing the command echo $0

Write the su and sudo commands to launch the specified shell:

Interactive-login shell as user2

su:

sudo:

Interactive login shell as root

su:

sudo:

Interactive non-login shell as root

su:

sudo:

Interactive non-login shell as user2

su:

sudo:

What startup file gets read when the shell under “Shell Type” is started?

Shell Type /etc/profile /etc/bash.bashrc ~/.profile ~/.bashrc

Interactive-login shell as user2

Interactive login shell as root

Interactive non-login shell as root

Interactive non-login shell as user2

Explorational Exercises

In Bash we can write a simple Hello world! function by including the following code in an empty file:
```
function hello() {
	 echo "Hello world!"
}
```
- What should we do next to make the function available to the shell?
- Once it is available to the current shell, how would you invoke it?
- To automate things, in what file would you put the function and its invocation so that it gets executed when user2 opens a terminal from an X Window session? What type of shell is it?
- In what file would you put the function and its invocation so that it is run when root launches a new interactive shell irrespective of whether it is login or not?
Have a look at the following basic, Hello world! bash script:
```
#!/bin/bash

#hello_world: a simple bash script to discuss interaction in scripts.

echo "Hello world!"
```
- Suppose we make the script executable and run it. Would that be an interactive script? Why?
- What makes a script interactive?
Imagine you have changed the values of some variables in ~/.bashrc and want those changes to take effect without a reboot. From your home directory, how could you achieve that in two different ways?
John has just started an X Window session on a Linux server. He opens a terminal emulator to carry out some administrative tasks but, surprisingly, the session freezes and he needs to open a text shell.
- How can he open that tty shell?
- What startup files will get sourced?
Linda is a user of a Linux server. She kindly asks the administrator to have a ~/.bash_login file so she can have the time and date printed on the screen when she logs in. Other users like the idea and follow suit. The administrator has a hard time creating the file for all other users on the server so he decides to add a new policy and have ~/.bash_login created for all potential new users. How can the administrator accomplish that task?

Summary

In this lesson we learned:

Shells set users' environment in a Linux system.
Bash is the number one shell across GNU/Linux distributions.
The first job a shell carries out is that of reading and executing one or various startup files.
The concepts of interaction and login as related to shells.
How to launch different types of shells with bash, su, sudo and Ctrl+Alt+F1-F6.
How to check the type of shell with echo $0.
The local startup files ~/.bash_profile, ~/.profile, ~/.bash_login, ~/.bash_logout and ~/.bashrc.
The global startup files /etc/profile, /etc/profile.d/*, /etc/bash.bashrc.
Local files take precedence over global ones.
How to redirect the output of a command with > (overwrite) and >> (append).
The meaning of the skel directory.
How to source files.

Commands used in this lesson:

bash: Create a new shell.
su: Create a new shell.
sudo: Create a new shell.
usermod: Modify a user account.
echo: Display a line of text.
ps: Report a snapshot of the current processes.
less: A pager for long files.
ssh: Start an Open SSH connection (remotely).
chmod: Change mode bits of a file, for example make it executable.
grep: Print lines matching a pattern.
ls: List directory contents.
cd: Change directory.
mkdir: Make directory.
deluser: Delete user.
adduser: Add a new user.
.: Source a file.
source: Source a file.
tail: Output the last part of files.

Answers to Guided Exercises

Study how the shells have been started under the column “Shell Started with…” and complete with the required information:

Shell Started with… Interactive? Login? Result of echo $0

sudo ssh user2@machine2

Yes

-bash

Ctrl+Alt+F2

Yes

-bash

su - user2

Yes

-bash

gnome-terminal

Yes

bash

A regular user uses konsole to start an instance of sakura

Yes

/bin/bash

A script named test.sh containing the command echo $0

./test.sh

Write the su and sudo commands to launch the specified shell:

Interactive-login shell as user2

su

su - user2, su -l user2 or su --login user2

sudo

sudo su - user2, sudo su -l user2 or sudo su --login user2

Interactive login shell as root

su

su - root or su -

sudo

sudo su - root, sudo su - or sudo -i

Interactive non-login shell as root

su

su root or su

sudo

sudo su root, sudo su, sudo -s or sudo -u root -s

Interactive non-login shell as user2

su

su user2

sudo

sudo su user2 or sudo -u user2 -s

What startup file gets read when the shell under “Shell Type” is started?

Shell Type /etc/profile /etc/bash.bashrc ~/.profile ~/.bashrc

Interactive-login shell as user2

Yes

Interactive login shell as root

Yes

Interactive non-login shell as root

Yes

Interactive non-login shell as user2

Yes

Answers to Explorational Exercises

In Bash we can write a simple Hello world! function by including the following code in an empty file:
```
function hello() {
	 echo "Hello world!"
}
```
- What should we do next to make the function available to the shell?
  
  To make the function availabe to the current shell, we must source the file which includes it.
- Once it is available to the current shell, how would you invoke it?
  
  We will invoke it by typing its name into the terminal.
- To automate things, in what file would you put the function and its invocation so that it gets executed when user2 opens a terminal from an X Window session? What type of shell is it?
  
  The best file to put it is /home/user2/.bashrc. The invoked shell would be an interactive non-login one.
- In what file would you put the function and its invocation so that it is run when root launches a new interactive shell irrespective of whether it is login or not?
  
  In /etc/bash.bashrc since this file gets executed for all interactive shells — whether login or not.
Have a look at the following basic, Hello world! bash script:
```
#!/bin/bash

#hello_world: a simple bash script to discuss interaction in scripts.

echo "Hello world!"
```
- Suppose we make the script executable and run it. Would that be an interactive script? Why?
  
  No, as there is no human interaction and no commands being typed in by the user.
- What makes a script interactive?
  
  The fact that it requires user input.
Imagine you have changed the values of some variables in ~/.bashrc and want those changes to take effect without a reboot. From your home directory, how could you achieve that in two different ways?
```
$ source .bashrc
```
or
```
$ . .bashrc
```
John has just started an X Window session on a Linux server. He opens a terminal emulator to carry out some administrative tasks but, surprisingly, the session freezes and he needs to open a text shell.
- How can he open that tty shell?
  
  He could do that by pressing Ctrl+Alt+F1-F6 to enter one of the six tty shells.
- What startup files will get sourced?
  
  /etc/profile
  /home/john/.profile
Linda is a user of a Linux server. She kindly asks the administrator to have a ~/.bash_login file so she can have the time and date printed on the screen when she logs in. Other users like the idea and follow suit. The administrator has a hard time creating the file for all other users on the server so he decides to add a new policy and have ~/.bash_login created for all potential new users. How can the administrator accomplish that task?

He could achieve that by putting .bash_login into the /etc/skel directory.

105.1 Lesson 1

Introduction

Shell Types: Interactive vs. Non-Interactive and Login vs. Non-Login

Opening a Terminal

Launching Shells with bash

Launching Shells with su and sudo

What Shell Type Do We Have?

How Many Shells Do We Have?

Where Shells Get their Configuration From: Startup Files

Interactive Login Shell

Global Level

Local Level

Exploring Interactive Login Shell Configuration Files

Interactive Non-Login Shell

Global Level

Local Level

Exploring Interactive Non-Login Shell Configuration Files

Non-Interactive Login Shell

Non-Interactive Non-Login Shell

Sourcing Files

Sourcing Files with .

Sourcing Files with source

The Origin of Shell Startup Files: SKEL

Guided Exercises

Explorational Exercises

Summary

Answers to Guided Exercises

Answers to Explorational Exercises

Launching Shells with `bash`

Launching Shells with `su` and `sudo`

Sourcing Files with `.`

Sourcing Files with `source`

The Origin of Shell Startup Files: `SKEL`