Command-Line Arguments

# CHAPTER 12

Command-Line Arguments #

1. Introduction #

Example Script (createuser.sh):

#!/bin/bash

# We don't use 'read'. We just grab the arguments directly.
USERNAME=$1
DEPARTMENT=$2

echo "Creating account for $USERNAME in the $DEPARTMENT department..."

Execution: You must provide the data at launch:

./create_user.sh Alex Engineering
# Output: Creating account for Alex in the Engineering department...

4. Special Argument Variables ($# and $@) #

1. Counting Arguments ($#): The $# variable holds a numeric integer representing exactly how many arguments the user provided.

echo "You provided $# arguments to this script."

2. All Arguments ($@): If you pass 50 server IP addresses to a script, you don't want to type $1, $2... all the way to $50. The $@ variable holds *every single argument* as a massive array.

#!/bin/bash
for IP in "$@"
do
    echo "Pinging $IP..."
done

5. Argument Validation (Failsafes) #

#!/bin/bash

# Check if the total number of arguments ($#) is NOT equal to 1
if [ $# -ne 1 ]; then
    echo "ERROR: Invalid usage."
    echo "Usage: ./deploy.sh [TARGET_IP]"
    exit 1  # Abort the script immediately
fi

TARGET_IP=$1
echo "Deploying to $TARGET_IP..."

6. Handling Spaces in Arguments #

• $1 becomes "Alex"

• $2 becomes "Smith"

7. Diagrams/Visual Suggestions #

• Arrow from ./deploy.sh -> Box labeled $0.

• Arrow from 192.168.1.5 -> Box labeled $1.

• Arrow from production -> Box labeled $2.

8. Best Practices #

• Implement a "Usage" block: Professional scripts always check for a missing argument and instantly respond with a Usage: string. This mimics the behavior of native Linux tools. If you type ping without an IP, it tells you exactly how to use it. Your scripts must do the same to be user-friendly for other engineers.

9. Common Mistakes #

• Confusing $0 and $1: Beginners often think the first word they type (the script name) is $1. It is not. $0 is always reserved for the script's own filename. The actual data payload begins strictly at $1.

10. Mini Project: The Bulk File Renamer #

1. 1. nano renamer.sh

1. 2. Write the code:

#!/bin/bash

# Validation
if [ $# -ne 2 ]; then
    echo "ERROR: Requires exactly two arguments."
    echo "Usage: ./renamer.sh [OLD_EXT] [NEW_EXT]"
    echo "Example: ./renamer.sh txt md"
    exit 1
fi

OLD_EXT=$1
NEW_EXT=$2

# Iterate over all files matching the old extension
for FILE in *.$OLD_EXT
do
    # Use standard bash substitution to rename the string
    NEW_NAME="${FILE%.$OLD_EXT}.$NEW_EXT"
    mv "$FILE" "$NEW_NAME"
    echo "Renamed: $FILE -> $NEW_NAME"
done

1. 3. chmod +x renamer.sh. This is a fully functional CLI tool!

11. Practice Exercises #

1. 1. Explain the architectural advantage of providing data to a script via Command-Line Arguments ($1) rather than prompting the user via the read command.

1. 2. Differentiate the operational utility of the $# variable versus the $@ variable.

12. MCQs with Answers #

13. Interview Questions #

• Q: A junior DevOps engineer writes an automated server reboot script that accepts a target IP address as $1. The script lacks any validation logic. Explain the specific risk of running this script via an automated pipeline that occasionally fails to generate an IP address variable.

• Q: Explain the structural behavior of the $@ variable. If a script executes with ./run.sh server1 server2 server3, walk me through exactly how you would parse the $@ variable to ping each server sequentially.

• Q: A user runs your script using the syntax ./add_user.sh John Doe. Your script utilizes $1 to create the username, but it only creates the user "John". Explain the syntactical mistake the user made during execution, and how they must format the command to pass the full name as a single positional parameter.

14. FAQs #

15. Summary #

16. Next Chapter Recommendation #