Vserbu: Pagină nouă: == Objectives == Upon completion of this lab, you will be able to: * Explain how the kernel executes scripts via the shebang mechanism and how bash...

2025-10-31T14:50:21Z

Pagină nouă: == Objectives == Upon completion of this lab, you will be able to: * Explain how the kernel executes scripts via the shebang mechanism and how bash...

Pagină nouă

== Objectives ==

Upon completion of this lab, you will be able to:

* Explain how the kernel executes scripts via the shebang mechanism and how bash interprets script contents.
* Distinguish between shell builtins and external programs, understanding why certain commands must be builtins.
* Write scripts using proper variable quoting, recognizing that commands are fundamentally lists of strings.
* Use exit status to control script flow with conditionals and logical operators.
* Redirect file descriptors to control input and output streams.
* Implement loops with <code>while</code> and <code>for</code>, incorporating command substitution.
* Define functions with proper variable scoping and work with arrays.
* Apply defensive scripting practices using <code>set -euo pipefail</code>.


== Introduction ==

In previous labs, we explored processes, job control, and the permission model. These concepts form the foundation for understanding how programs execute and interact with the system. We now turn to bash scripting, which allows us to automate tasks and build tools without writing compiled programs.

This lab emphasizes underlying mechanisms rather than syntax alone. We will examine how the kernel interprets shebangs, why certain commands must be shell builtins, and how bash's command model treats everything as lists of strings. Understanding these foundations prepares you for the next lab, where we'll explore signals and inter-process communication using bash scripts rather than C code.


== Prerequisites ==


=== System Requirements ===

A running instance of the course-provided Linux virtual machine with SSH or direct terminal access.


=== Required Packages ===

All necessary utilities (<code>bash</code>, <code>seq</code>, <code>grep</code>, <code>wc</code>) are pre-installed. No additional packages are required.


=== Knowledge Prerequisites ===

You should be familiar with:

* Basic command-line navigation and file operations
* Process concepts from Lab 3 (PIDs, exit status)
* File permissions and the execute bit from Lab 4


== Theoretical Background ==


=== Shebangs and Script Execution ===


==== The Kernel's Role ====

When you execute a file like <code>./script.sh</code>, the kernel first checks the execute permission bit. If set, the kernel examines the file's first bytes. If they are <code>#!</code> (the "shebang"), the kernel reads the rest of that line as a path to an interpreter and re-executes the file using that interpreter.

For example, a script beginning with <code>#!/bin/bash</code> causes the kernel to execute <code>/bin/bash ./script.sh</code>. This mechanism is general-purpose: the kernel doesn't care whether the interpreter is bash, Python, or any other program.

'''Requirements for script execution:'''

* Execute bit must be set (<code>chmod +x script.sh</code>)
* File must begin with a valid shebang pointing to an interpreter
* The interpreter itself must be an executable binary

Without the execute bit, the kernel's permission check fails. Without a shebang, the kernel cannot determine which interpreter to use, and behavior becomes system-dependent.


==== The Shell's Role ====

Once the kernel launches bash with your script as an argument, bash reads the script line by line, parsing each line according to its syntax rules. This involves expanding variables, performing word splitting, executing commands, and capturing results.

The fundamental principle: '''every command is a list of strings'''. When bash executes <code>echo Hello World</code>, it constructs a list of three strings: <code>"echo"</code>, <code>"Hello"</code>, and <code>"World"</code>. The first string identifies the command; remaining strings are arguments. This model applies universally to builtins, external programs, and functions.


=== Builtins vs External Programs ===


==== External Programs and PATH ====

When bash encounters a command that isn't a builtin, it searches the directories in the <code>PATH</code> environment variable for an executable with that name. When found, bash forks a child process and executes the program. Commands like <code>ls</code>, <code>grep</code>, and <code>wc</code> run in separate processes with their own address space.

Use <code>which</code> to locate external programs:

<syntaxhighlight lang="bash">which ls
# Output: /usr/bin/ls</syntaxhighlight>

==== Shell Builtins ====

Builtins are commands built directly into bash. Use <code>type</code> to identify them:

<syntaxhighlight lang="bash">type cd
# Output: cd is a shell builtin</syntaxhighlight>
Builtins exist for two reasons:

'''1. Process State Modification'''

Some commands must modify the shell's own process state. Consider <code>cd</code>: if it were an external program, it would run in a child process, change that child's directory, then exit. The parent shell's directory would remain unchanged because child process state doesn't propagate to parents. For <code>cd</code> to work, it must execute within the shell's own process, making it a necessary builtin.

Other state-modifying builtins include <code>ulimit</code> (resource limits) and <code>umask</code> (permission mask). In the next lab, we'll see <code>export</code> (environment variables) and <code>trap</code> (signal handlers).

'''2. Performance'''

Commands like <code>true</code>, <code>false</code>, <code>echo</code>, and <code>[[</code> are builtins for performance, avoiding process creation overhead. They could theoretically be external programs, but making them builtins is faster.


=== Exercise A: Your First Script and the Shebang ===

This exercise demonstrates the kernel's shebang mechanism and the importance of the execute bit.

'''Steps:'''

<ol style="list-style-type: decimal;">
<li>Create a script <code>/tmp/lab5_hello.sh</code> containing:
<syntaxhighlight lang="bash">#!/bin/bash
echo "Hello from bash!"</syntaxhighlight></li>
<li>Check the file's permissions with <code>ls -l</code>. Note that the execute bit is not set.</li>
<li>Attempt to execute the script directly: <code>/tmp/lab5_hello.sh</code>. This should fail with "Permission denied".</li>
<li>Make the script executable with <code>chmod +x</code> and verify with <code>ls -l</code>.</li>
<li>Execute the script directly. It should now succeed.</li>
<li>Execute the script by passing it to bash: <code>bash /tmp/lab5_hello.sh</code>. Observe that this works even without the execute bit.</li>
<li>Create a second script without a shebang, make it executable, and attempt to run it. Observe the unpredictable behavior.</li>
<li>Clean up both test scripts.</li></ol>

'''Deliverable A:''' Provide <code>ls -l</code> output before and after setting the execute bit, the "Permission denied" error, and the successful execution output.

=== Exercise B: Builtins vs External Commands ===

This exercise demonstrates why certain commands must be builtins.

'''Steps:'''

# Use <code>type</code> to identify whether <code>cd</code>, <code>echo</code>, <code>ls</code>, <code>[[</code>, and <code>grep</code> are builtins or external commands.
# Use <code>which</code> to locate external programs. Try <code>which cd</code> and note that it doesn't find the builtin.
# Create <code>/tmp/lab5_cd_test.sh</code> that prints the current directory, changes to <code>/tmp</code>, and prints the directory again.
# Make the script executable and run it. Observe that the script successfully changes to <code>/tmp</code>.
# Check your shell's current directory with <code>pwd</code>. Note that your shell is still in the original directory.
# Test <code>cd</code> directly in your shell to confirm it works when run as a builtin.
# Clean up the test script.

'''Deliverable B:''' Provide the <code>type</code> command outputs, the script output followed by your shell's <code>pwd</code> output.


=== Variables and Quoting ===


==== The List-of-Strings Model ====

Variables in bash are expanded before commands execute. How they're expanded determines the final command's argument list.

Consider:

<syntaxhighlight lang="bash">greeting="Hello World"
echo $greeting</syntaxhighlight>
Bash expands <code>$greeting</code> to <code>"Hello World"</code>, then performs '''word splitting''', breaking it into separate strings at whitespace. The result: three strings passed to echo: <code>"echo"</code>, <code>"Hello"</code>, <code>"World"</code>.

This works fine for echo, but consider:

<syntaxhighlight lang="bash">filename="my document.txt"
ls $filename</syntaxhighlight>
Word splitting breaks <code>"my document.txt"</code> into <code>"my"</code> and <code>"document.txt"</code>. The <code>ls</code> command receives two arguments and tries to list two separate files, which fails.


==== Quoting Fixes This ====

Double quotes prevent word splitting:

<syntaxhighlight lang="bash">ls "$filename"</syntaxhighlight>
Now <code>ls</code> receives one argument: <code>"my document.txt"</code>. The expansion happens, but the result stays as a single string.

'''Single quotes''' prevent all expansion:

<syntaxhighlight lang="bash">echo '$name' # Outputs: $name (literal)
echo "$name" # Outputs: the value of $name</syntaxhighlight>
'''Best practice:''' Always quote variables unless you specifically need word splitting. Write <code>"$variable"</code> not <code>$variable</code>. This makes scripts robust when variables contain spaces or special characters.


=== Exercise C: Quoting and Word Splitting ===

This exercise demonstrates why quoting variables is essential.

'''Steps:'''

# Create a file named <code>/tmp/my test file.txt</code> (with spaces).
# Store the filename in a variable and try to list it without quotes: <code>ls $myfile</code>. This will fail.
# Try again with proper quoting: <code>ls "$myfile"</code>. This succeeds.
# Test echo with a variable containing multiple spaces, both with and without quotes.
# Create <code>/tmp/lab5_quote_test.sh</code> that demonstrates variable quoting and array expansion both correctly and incorrectly. The script should show:
#* A variable with spaces, echoed with and without quotes
#* An array containing an element with spaces, iterated both ways
# Make the script executable and run it. Observe how the "wrong way" processes four items instead of three.
# Clean up the test files.

'''Deliverable C:''' Provide the error from unquoted <code>ls</code>, the success from quoted <code>ls</code>, complete script output.


=== Exit Status and Conditionals ===

Every command returns an exit status: a number from 0 to 255. By convention, 0 means success; non-zero means failure. Bash stores the last command's exit status in <code>$?</code>:

<syntaxhighlight lang="bash">ls /tmp
echo $? # Outputs: 0 (success)

ls /nonexistent
echo $? # Outputs: non-zero (failure)</syntaxhighlight>
This exit status is bash's fundamental true/false mechanism. An <code>if</code> statement executes a command and checks if it succeeded:

<syntaxhighlight lang="bash">if grep -q "ERROR" /var/log/syslog; then
echo "Errors found"
fi</syntaxhighlight>
If <code>grep</code> finds "ERROR", it returns 0, and the <code>then</code> block executes.


==== The <code>[[</code> Command ====

The <code>[[</code> builtin performs tests and returns an exit status. Despite unusual syntax, it's conceptually just another command:

<syntaxhighlight lang="bash">[[ -f "file.txt" ]] # Returns 0 if file exists, 1 otherwise</syntaxhighlight>
Common operators:

* <code>-f file</code>: True if regular file exists
* <code>-d dir</code>: True if directory exists
* <code>-e path</code>: True if path exists
* <code>string1 == string2</code>: True if strings equal
* <code>num1 -lt num2</code>: True if num1 less than num2

Example:

<syntaxhighlight lang="bash">if [[ -f "config.txt" ]]; then
echo "Config file found"
fi</syntaxhighlight>

==== Logical Operators ====

'''<code>&&</code> (AND):''' Runs next command only if previous succeeded (returned 0):

<syntaxhighlight lang="bash">mkdir /tmp/newdir && cd /tmp/newdir</syntaxhighlight>
'''<code>||</code> (OR):''' Runs next command only if previous failed (returned non-zero):

<syntaxhighlight lang="bash">cd /tmp/important || echo "Failed to change directory"</syntaxhighlight>
'''Explicit error ignoring:'''

<syntaxhighlight lang="bash">rm -f /tmp/maybe-exists.txt || true</syntaxhighlight>
The <code>|| true</code> pattern documents that you're intentionally ignoring potential errors.


=== Exercise D: Exit Status and Conditionals ===

This exercise explores exit status and conditional logic.

'''Steps:'''

# Execute <code>ls /tmp</code> and check <code>$?</code>. It should be 0 (success).
# Execute <code>ls /nonexistent</code> (redirect stderr to <code>/dev/null</code>) and check <code>$?</code>. It should be non-zero.
# Test <code>[[ -f /etc/passwd ]]</code> and <code>[[ -f /nonexistent ]]</code>, checking <code>$?</code> after each.
# Create <code>/tmp/lab5_conditionals.sh</code> that demonstrates:
#* File existence tests with <code>if</code>
#* The <code>&&</code> operator for success chaining
#* The <code>||</code> operator for failure handling
#* The <code>|| true</code> pattern for explicit error ignoring
#* Using command exit status directly in <code>if</code> (e.g., with <code>grep</code>)
#* Numeric and string comparisons with <code>[[</code>
# Make the script executable and run it. Observe the output from each test.
# Clean up the script.

'''Deliverable D:''' Provide exit status values from steps 1-3, complete script output.


=== Output Redirection and File Descriptors ===

Recall from Lab 3 that every process has file descriptors (FDs):

* '''FD 0:''' Standard input (stdin)
* '''FD 1:''' Standard output (stdout)
* '''FD 2:''' Standard error (stderr)

Redirection allows you to control where these streams go.


==== Basic Redirection ====

Redirect stdout to a file:

<syntaxhighlight lang="bash">echo "output" > file.txt</syntaxhighlight>
Redirect stderr:

<syntaxhighlight lang="bash">ls /nonexistent 2> error.txt</syntaxhighlight>
Redirect both:

<syntaxhighlight lang="bash">command &> combined.txt</syntaxhighlight>
Or more explicitly:

<syntaxhighlight lang="bash">command > output.txt 2>&1</syntaxhighlight>
Order matters! <code>2>&1</code> must come after <code>> output.txt</code> to redirect stderr to where stdout is pointing.


==== Pipes ====

The pipe operator <code>|</code> connects one command's stdout to another's stdin:

<syntaxhighlight lang="bash">cat /var/log/syslog | grep "ERROR" | wc -l</syntaxhighlight>
Data flows left to right. The kernel creates an anonymous pipe, connecting the write end to the first command's stdout and the read end to the second command's stdin.


==== Input Redirection ====

Redirect stdin from a file:

<syntaxhighlight lang="bash">wc -l < file.txt</syntaxhighlight>
This differs from <code>wc -l file.txt</code>: with <code><</code>, bash opens the file and connects it to stdin before running <code>wc</code>.


=== Loops ===


==== The <code>for</code> Loop ====

Iterates over a list of values:

<syntaxhighlight lang="bash">for item in value1 value2 value3; do
echo "$item"
done</syntaxhighlight>
Common sources for the list:

'''Filename expansion (globbing):'''

<syntaxhighlight lang="bash">for file in *.txt; do
echo "Processing $file"
done</syntaxhighlight>
'''Command substitution:'''

<syntaxhighlight lang="bash">for i in $(seq 1 10); do
echo "Number $i"
done</syntaxhighlight>

==== The <code>while</code> Loop ====

Executes while a command succeeds:

<syntaxhighlight lang="bash">counter=1
while [[ $counter -le 5 ]]; do
echo "Iteration $counter"
counter=$((counter + 1))
done</syntaxhighlight>
'''Reading files line-by-line:'''

<syntaxhighlight lang="bash">while read -r line; do
echo "Line: $line"
done < file.txt</syntaxhighlight>
The <code>read</code> command returns 0 while reading lines successfully, and non-zero at end-of-file.


=== Exercise E: File Descriptor Redirection ===

This exercise explores redirection, connecting to Lab 3's file descriptor concepts.

'''Steps:'''

# Redirect stdout to a file with <code>></code>, then display the file contents.
# Redirect stderr to a file with <code>2></code> by trying to list a nonexistent directory.
# Redirect both stdout and stderr to the same file using <code>&></code>.
# Demonstrate the <code>2>&1</code> pattern with explicit redirection order.
# Use a pipe to chain <code>cat /etc/passwd</code>, <code>grep "root"</code>, and <code>cut</code> to extract the username.
# Create <code>/tmp/lab5_redirect.sh</code> that demonstrates:
#* Output redirection with <code>></code> and <code>>></code>
#* Stderr capture with <code>2></code>
#* Combined stream redirection with <code>&></code>
#* A pipeline example
#* Input redirection with <code><</code>
# Make the script executable and run it.
# Clean up all test files.

'''Deliverable E:''' Provide the captured stderr contents and complete script output.


=== Command Substitution ===

Command substitution captures a command's stdout for use elsewhere:

<syntaxhighlight lang="bash">current_date=$(date +%Y-%m-%d)
echo "Today is $current_date"</syntaxhighlight>
Bash executes the command in <code>$()</code>, captures its output, and substitutes it in place.

Common in loops:

<syntaxhighlight lang="bash">for i in $(seq 1 10); do
echo "$i"
done</syntaxhighlight>
The <code>seq</code> output (numbers 1-10, one per line) is captured, word-split, and becomes the loop's value list.


=== Functions ===

Functions group commands for reuse:

<syntaxhighlight lang="bash">greet() {
echo "Hello, $1"
}

greet "Alice" # Outputs: Hello, Alice</syntaxhighlight>
'''Arguments:''' Access via <code>$1</code>, <code>$2</code>, etc. <code>$@</code> expands to all arguments; <code>$#</code> gives the count.

'''Return values:''' Functions return exit status (0-255) via <code>return</code>. For other values, write to stdout and capture with command substitution:

<syntaxhighlight lang="bash">get_uppercase() {
echo "$1" | tr '[:lower:]' '[:upper:]'
}

result=$(get_uppercase "hello")</syntaxhighlight>

==== Variable Scope ====

By default, variables are global. Use <code>local</code> for function-local variables:

<syntaxhighlight lang="bash">calculate() {
local temp=$1
local result=$((temp * 2))
echo "$result"
}</syntaxhighlight>
Without <code>local</code>, these variables would affect the global scope.


=== Arrays ===

Arrays are collections of strings:

<syntaxhighlight lang="bash">files=("file1.txt" "file 2.txt" "file3.txt")</syntaxhighlight>
'''Access elements:'''

<syntaxhighlight lang="bash">echo "${files[0]}" # First element
echo "${files[@]}" # All elements
echo "${#files[@]}" # Number of elements</syntaxhighlight>
'''Critical syntax:''' Use <code>"${array[@]}"</code> (with quotes) to preserve each element as a separate string:

<syntaxhighlight lang="bash">for file in "${files[@]}"; do
echo "Processing: $file"
done</syntaxhighlight>
This correctly processes three files, including <code>"file 2.txt"</code> as one item.

'''Without quotes:'''

<syntaxhighlight lang="bash">for file in ${files[@]}; do # WRONG
echo "Processing: $file"
done</syntaxhighlight>
Word splitting breaks <code>"file 2.txt"</code> into <code>"file"</code> and <code>"2.txt"</code>, processing four items instead of three.


=== Defensive Scripting: <code>set -euo pipefail</code> ===

Bash scripts, by default, continue after errors. This can cause silent failures that are hard to debug. These options make scripts safer:


==== <code>set -e</code> (Exit on Error) ====

Exit immediately if any command returns non-zero:

<syntaxhighlight lang="bash">set -e

cp important.txt backup.txt
process backup.txt # Won't run if cp failed</syntaxhighlight>
To allow specific failures:

<syntaxhighlight lang="bash">rm -f /tmp/file.txt || true</syntaxhighlight>

==== <code>set -u</code> (Error on Undefined Variables) ====

Treat undefined variables as errors:

<syntaxhighlight lang="bash">set -u

echo "$undefined_var" # Error: undefined_var: unbound variable</syntaxhighlight>
This catches typos and logic errors.


==== <code>set -o pipefail</code> (Pipeline Failure) ====

Normally, a pipeline's exit status is the last command's status:

<syntaxhighlight lang="bash">grep "ERROR" missing.log | head -n 10
# Returns 0 (head succeeded) even though grep failed</syntaxhighlight>
With <code>pipefail</code>, the pipeline fails if any command fails:

<syntaxhighlight lang="bash">set -o pipefail

grep "ERROR" missing.log | head -n 10
# Returns non-zero (grep failed)</syntaxhighlight>

==== Recommended Practice ====

Start every script with:

<syntaxhighlight lang="bash">#!/bin/bash
set -euo pipefail</syntaxhighlight>
These options prevent silent errors and make debugging easier.


== Scripting Challenges ==


=== Challenge 1: Log File Analyzer ===

Write <code>/tmp/lab5_log_analyzer.sh</code> that analyzes a log file.

'''Requirements:'''

* Accept one argument: log file path
* Print usage message if wrong number of arguments
* Print error if file doesn't exist or isn't readable
* Count lines containing "ERROR", "WARN", and "INFO"
* Print summary report
* Use: shebang, <code>set -euo pipefail</code>, proper quoting, <code>if</code> statements, <code>grep</code>, counting method

'''Test data:'''

<syntaxhighlight lang="bash">cat > /tmp/lab5_test.log <<'EOF'
2024-01-15 10:00:00 INFO Application started
2024-01-15 10:05:23 INFO User login successful
2024-01-15 10:12:45 WARN Connection timeout, retrying
2024-01-15 10:15:00 ERROR Database connection failed
2024-01-15 10:15:30 INFO Connection restored
2024-01-15 10:20:00 ERROR Invalid configuration parameter
2024-01-15 10:25:00 WARN Disk space low
2024-01-15 10:30:00 INFO Backup completed successfully
EOF</syntaxhighlight>
'''Expected output:'''

<pre>Log Analysis Report for /tmp/lab5_test.log
==========================================
ERROR: 2
WARN: 2
INFO: 4</pre>
'''Test:'''

<syntaxhighlight lang="bash">chmod +x /tmp/lab5_log_analyzer.sh
/tmp/lab5_log_analyzer.sh /tmp/lab5_test.log
/tmp/lab5_log_analyzer.sh
/tmp/lab5_log_analyzer.sh /nonexistent.log</syntaxhighlight>
'''Deliverable Challenge 1:'''

* Complete script with comments
* Output from test log
* Output with no arguments (usage)
* Output with nonexistent file (error)


=== Challenge 2: Batch File Processor ===

Write <code>lab5_batch_processor.sh</code> that processes multiple files.

'''Requirements:'''

* Accept two arguments: directory path and operation ("count", "uppercase", or "list")
* Print usage if wrong arguments or invalid operation
* Define three functions (one per operation):
** <code>count</code>: Count lines in each <code>.txt</code> file
** <code>uppercase</code>: Create <code>.upper.txt</code> files with uppercase content
** <code>list</code>: List <code>.txt</code> files with sizes
* Store files in array, use loop to process
* Must use: shebang, <code>set -euo pipefail</code>, functions with <code>local</code>, array with <code>"${array[@]}"</code>, loop, case/if for operation selection

'''Test data:'''

<syntaxhighlight lang="bash">mkdir -p /tmp/lab5_batch_test
echo -e "line 1\nline 2\nline 3" > /tmp/lab5_batch_test/file1.txt
echo -e "hello world\ntest file" > /tmp/lab5_batch_test/file2.txt
echo -e "single line" > /tmp/lab5_batch_test/file3.txt</syntaxhighlight>
'''Expected output for "count":'''

<pre>Processing files in /tmp/lab5_batch_test
Operation: count
========================================
file1.txt: 3 lines
file2.txt: 2 lines
file3.txt: 1 lines</pre>
'''Test:'''

<syntaxhighlight lang="bash">chmod +x lab5_batch_processor.sh
./lab5_batch_processor.sh /tmp/lab5_batch_test count
./lab5_batch_processor.sh /tmp/lab5_batch_test uppercase
cat /tmp/lab5_batch_test/file1.upper.txt
./lab5_batch_processor.sh /tmp/lab5_batch_test list</syntaxhighlight>
'''Deliverable Challenge 2:'''

* Complete script
* Output from "count" operation
* Output from "uppercase" operation + contents of one <code>.upper.txt</code> file
* Output from "list" operation


== Reference: Common Patterns ==

Quick reference for common bash patterns:

'''Script header:'''

<syntaxhighlight lang="bash">#!/bin/bash
set -euo pipefail</syntaxhighlight>
'''Check arguments:'''

<syntaxhighlight lang="bash">if [[ $# -lt 1 ]]; then
echo "Usage: $0 <arg>" >&2
exit 1
fi</syntaxhighlight>
'''Test file types:'''

<syntaxhighlight lang="bash">if [[ -f "$file" ]]; then
echo "Regular file"
elif [[ -d "$file" ]]; then
echo "Directory"
fi</syntaxhighlight>
'''Read file line-by-line:'''

<syntaxhighlight lang="bash">while read -r line; do
echo "$line"
done < "$filename"</syntaxhighlight>
'''Iterate over files:'''

<syntaxhighlight lang="bash">for file in *.txt; do
[[ -f "$file" ]] || continue
echo "$file"
done</syntaxhighlight>
'''Command substitution:'''

<syntaxhighlight lang="bash">date=$(date +%Y-%m-%d)
count=$(wc -l < "$file")</syntaxhighlight>
'''Arrays:'''

<syntaxhighlight lang="bash">arr=("item1" "item 2" "item3")
for item in "${arr[@]}"; do
echo "$item"
done</syntaxhighlight>
'''Functions:'''

<syntaxhighlight lang="bash">process() {
local file="$1"
echo "Processing $file"
}</syntaxhighlight>

== Deliverables and Assessment ==

Submit a single document (PDF or similar) containing screenshots of:

'''Exercise Deliverables:'''

* '''Exercise A:''' Permission outputs, error message, successful output, explanation
* '''Exercise B:''' <code>type</code> outputs, script + pwd output, explanation
* '''Exercise C:''' Error/success outputs, script output, explanation
* '''Exercise D:''' Exit status values, script output, explanation
* '''Exercise E:''' Stderr contents, script output, FD explanations

'''Challenge Deliverables:'''

* '''Challenge 1:''' Script code, test outputs (success, no args, nonexistent file)
* '''Challenge 2:''' Script code, outputs for all three operations, <code>.upper.txt</code> contents


== Additional Resources ==

This lab provides foundations for the next exercise on signals and inter-process communication. You'll use bash's <code>trap</code> builtin and named pipes without writing C code.

For further study:

* Bash manual: <code>man bash</code>
* ShellCheck: https://www.shellcheck.net/
* Advanced Bash-Scripting Guide: https://tldp.org/LDP/abs/html/

@@ Linia 43: / Linia 43: @@
 <span id="theoretical-background"></span>
-== Theoretical Background ==
+== Bash Scripting ==
 <span id="shebangs-and-script-execution"></span>

OS Lab 5 - Bash Scripting - Revizia istoricului

Vserbu la 31 octombrie 2025 14:58

Vserbu la 31 octombrie 2025 14:54

Vserbu: Pagină nouă: == Objectives == Upon completion of this lab, you will be able to: * Explain how the kernel executes scripts via the shebang mechanism and how bash...