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
|
|
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
orbash --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
orsu --login user2
will start an interactive login shell asuser2
. -
su user2
will start an interactive non-login shell asuser2
. -
su - root
orsu -
will start an interactive login shell asroot
. -
su root
orsu
will start an interactive non-login shell asroot
.
-
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 tosudoers
we need to becomeroot
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
orsudo su --login user2
will start an interactive login shell asuser2
. -
sudo su user2
will start an interactive non-login shell asuser2
. -
sudo -u user2 -s
will start an interactive non-login shell asuser2
. -
sudo su - root
orsudo su -
will start an interactive login shell asroot
. -
sudo -i
will start an interactive login shell asroot
. -
sudo -i <some_command>
will start an interactive login shell asroot
, run the command and return to the original user. -
sudo su root
orsudo su
will start an interactive non-login shell asroot
. -
sudo -s
orsudo -u root -s
will start a non-login shell asroot
.
-
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 |
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 ofif
statements this file sets a number of variables such asPATH
andPS1
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 variablePATH
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 |
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 ofuser2
. -
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 interactivebash
shells. Through its executionbash
makes sure it is being run interactively, checks the window size after each command (updating the values ofLINES
andCOLUMNS
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 ifbash
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 lineecho '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, |
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 ( |
-
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 |
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 itshome
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 commandecho $0
-
Write the
su
andsudo
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
:
- Interactive-login shell as
-
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
Yes
-bash
Ctrl+Alt+F2
Yes
Yes
-bash
su - user2
Yes
Yes
-bash
gnome-terminal
Yes
No
bash
A regular user uses konsole to start an instance of sakura
Yes
No
/bin/bash
A script named
test.sh
containing the commandecho $0
No
No
./test.sh
-
Write the
su
andsudo
commands to launch the specified shell:- Interactive-login shell as
user2
su
-
su - user2
,su -l user2
orsu --login user2
sudo
-
sudo su - user2
,sudo su -l user2
orsudo su --login user2
- Interactive login shell as
root
su
-
su - root
orsu -
sudo
-
sudo su - root
,sudo su -
orsudo -i
- Interactive non-login shell as
root
su
-
su root
orsu
sudo
-
sudo su root
,sudo su
,sudo -s
orsudo -u root -s
- Interactive non-login shell as
user2
su
-
su user2
sudo
-
sudo su user2
orsudo -u user2 -s
- Interactive-login shell as
-
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
Yes
Yes
Yes
Interactive login shell as
root
Yes
Yes
No
No
Interactive non-login shell as
root
No
Yes
No
No
Interactive non-login shell as
user2
No
Yes
No
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.