Why scripts often process text in Bash Scripting - Performance Analysis
Scripts often handle text data like logs or configuration files. Understanding how time grows when processing text helps us write faster scripts.
We want to know how the script's work changes as the text size grows.
Analyze the time complexity of the following code snippet.
#!/bin/bash
filename="data.txt"
while IFS= read -r line; do
echo "$line" | grep -q "error"
if [ $? -eq 0 ]; then
echo "Found error: $line"
fi
done < "$filename"
This script reads a text file line by line and checks if each line contains the word "error".
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Reading each line and searching for a word using grep.
- How many times: Once for every line in the file.
As the number of lines grows, the script checks each line once.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 line checks |
| 100 | 100 line checks |
| 1000 | 1000 line checks |
Pattern observation: The work grows directly with the number of lines.
Time Complexity: O(n)
This means the script's work grows in a straight line as the text file gets bigger.
[X] Wrong: "The script only runs once, so size doesn't matter."
[OK] Correct: The script processes every line, so more lines mean more work and longer time.
Knowing how text processing scales helps you explain script performance clearly and shows you understand real-world scripting challenges.
"What if the script searched for multiple words per line? How would the time complexity change?"
Practice
Solution
Step 1: Understand file types in scripting
Text files contain readable characters, making them easy to handle with commands like grep and sed.Step 2: Compare text and binary files
Binary files need special tools and are harder to manipulate directly in scripts.Final Answer:
Because text files are easy to read and manipulate with simple commands -> Option AQuick Check:
Text files = easy manipulation [OK]
- Thinking binary files are easier to process
- Assuming scripts can't open non-text files
- Confusing file size with ease of processing
error in a file named log.txt using grep?Solution
Step 1: Identify grep command syntax
The correct syntax isgrep [pattern] [file].Step 2: Match pattern and file
Here,erroris the pattern andlog.txtis the file to search.Final Answer:
grep error log.txt -> Option BQuick Check:
grep pattern file = correct syntax [OK]
- Swapping pattern and filename
- Using incorrect flags like -f
- Putting filename before pattern
echo "apple banana cherry" | awk '{print $2}'Solution
Step 1: Understand the input and awk command
The input string is "apple banana cherry". Awk splits input by spaces and $2 refers to the second word.Step 2: Identify the second word
The second word is "banana".Final Answer:
banana -> Option DQuick Check:
awk $2 = second word = banana [OK]
- Confusing $1 and $2 fields
- Expecting full line output
- Not splitting input by spaces
pets.txt. What is wrong?sed 's/cat/dog/g pets.txt'
Solution
Step 1: Check sed command syntax
The substitution command must be enclosed in quotes fully: 's/cat/dog/g'Step 2: Identify the error in the given command
The closing single quote is missing after the g, causing a syntax error.Final Answer:
Missing closing single quote after g -> Option CQuick Check:
Quotes must enclose entire sed expression [OK]
- Forgetting to close quotes
- Misplacing file name inside quotes
- Thinking sed can't replace text
error from multiple log files and save them into a single file errors.txt. Which script snippet correctly does this?Solution
Step 1: Understand grep usage with multiple files
Usinggrep error *.logsearches for 'error' in all files ending with .log.Step 2: Redirect output to a file
The > operator sends all matching lines into errors.txt.Final Answer:
grep error *.log > errors.txt -> Option AQuick Check:
grep pattern files > outputfile [OK]
- Placing > before files
- Swapping pattern and files
- Using incorrect order of arguments
Ready to prove it?
Pass the test and this pattern moves unknown
