Shells and shell scripting

Shells and shell scripting covers customising the shell environment and writing simple scripts: startup files, variables and aliases, exit status, conditionals, loops and positional parameters. Objective 105 of LPIC-1 Exam 102-500, worth 15% of the exam.

Share of the exam
15%
Questions in a real sitting
roughly 9 of 60
Questions in this bank
45
Signed for by a person
0
Machine-checked only
45

Partly checked. None of the 45 questions here has been read against the cited source by a person. 45 questions have been checked against their cited clause by an automated pass — which is not the same thing, and is not a signature.

Only questions a person has signed for are used in mock exams here. That is the whole difference between the two kinds of checking above.

How these questions are written — where each question comes from, what the verification ledger records, and what happens when one is found wrong.

What this objective covers

The 45 questions written for this objective cite 2 LPI exam objectives (105.1, 105.2) and 4 manual pages (bash(1), execve(2), test(1), useradd(8)).

They break down as 30 single-answer questions, 7 choose-several questions and 8 type-the-answer questions.

What this objective is really about

Two halves that share a foundation. The first is the shell as an environment you configure; the second is the shell as a language you write in. Both come back repeatedly to one idea: what a child process inherits from its parent, and what it cannot change about it.

The environment, and why sourcing exists

Executing a script forks a new process. Anything that process changes — variables, working directory, umask — dies with it, which is why running a script that exports a variable leaves your own shell unchanged. Sourcing with . or source does not fork: the commands run in the current shell and their effects persist. That is the whole reason ~/.bashrc is sourced rather than executed, and it is the most commonly examined fact in this objective.

Aliases are per-shell and are never inherited, so making one permanent means putting it in a startup file. Note also that bash does not expand aliases in non-interactive shells, so an alias in .bashrc has no effect inside a script.

Scripting

A script starts with a shebang — #! as the very first two bytes, followed by an absolute path to the interpreter. #!/bin/sh selects the POSIX shell, which on Debian-family systems is dash and will reject bash-only syntax such as [[ ]] and arrays.

Exit status 0 means success and non-zero means failure, which is the opposite of the truthiness convention in most languages. $? holds the status of the last foreground command and is overwritten by the very next one. && runs the right-hand side only on success and || only on failure; both are driven purely by the status, never by output.

Positional parameters are $1 upward, $# is their count excluding $0, and $0 is the name the script was invoked as. When forwarding arguments, use "$@" — it produces one word per argument and is the only form that keeps an argument containing spaces intact. "$*" joins everything into a single word.

[ is a command whose last argument must be ], which is why the spaces are mandatory. [[ ]] is bash syntax rather than a command, so word splitting and globbing are not applied to unquoted variables inside it, which makes it markedly safer. Use [ for portable /bin/sh scripts and [[ ]] for bash-only ones. Loops close with done, if closes with fi, and case closes with esac.

Lessons in this objective

The objective cut into the pieces the blueprint declares. Each one has the material written out and the questions that test it.

Drill this objective

The trainer can run a short practice set drawn from this objective alone, which is what the weight column above is for: revise the heavy objectives first.

Practise Shells and shell scripting

Questions on this objective (page 1 of 3)

Practise Shells and shell scripting

The other objectives in LPIC-1 Exam 102-500