Top 70 Shell Scripting Environment Setup Interview Questions for Beginners (Part 3/8)

Shell scripting is writing a series of commands in a text file that the shell reads and executes one after another. Instead of typing commands manually each time, you put them in a script file and run it. This saves time and lets you automate repetitive tasks on your Linux system.

Shell scripts automate daily tasks like backups, system monitoring, and log processing. In production environments, a single script can replace dozens of manual steps, reduce human error, and run on schedules automatically. That's why every sysadmin and DevOps engineer needs to write scripts.

A shell is an interactive command interpreter where you type commands at a prompt and see results immediately. A shell script is a text file containing commands that the shell runs in batch mode without waiting for your input. The shell reads the file line by line and executes each command.

Bash stands for Bourne Again Shell. It's the most widely used shell on Linux systems and is the default shell on most modern distributions. Bash includes scripting features, command history, and tab completion that make it powerful for both interactive use and automation.

/bin/bash is the absolute file path to the Bash executable on Linux systems. When you write a script, you specify this path in the shebang line to tell the system which interpreter to use. Without the correct path, your script won't run properly even if the commands inside are correct.

Common shells include sh (the POSIX shell), zsh, ksh, and fish. Each has different features and syntax variations. For interviews and production work on most Linux systems, you'll work with Bash because it's standard and portable across distributions.

Start with Bash because it's the default on most systems and includes helpful features like command completion and history. Scripts written in Bash will run on almost every Linux system you encounter. The sh shell is more minimal and mostly useful when you need maximum portability to systems that don't have Bash.

On most modern systems, /bin/sh is actually a symbolic link to /bin/bash or another shell. However, when sh runs, it operates in POSIX-compatible mode with fewer Bash-specific features. If you want all Bash features, you should always use /bin/bash in your shebang line.

The shebang line is the first line of a script that starts with #! followed by the interpreter path, like #!/bin/bash. It tells the system which interpreter to use when executing the script. Without it, the system doesn't know whether to run the file as a Bash script, Python script, or something else.

The first line must be #!/bin/bash (or #!/bin/sh depending on your shell choice). This is the shebang. The # is required, and there should be no spaces between #, !, and the path.

Technically yes, but it's a bad idea. If you try to run the script directly using ./scriptname, the system will fail without a shebang. You can still execute it using bash scriptname from the command line, but this is unreliable for production scripts.

Shell scripts typically use the .sh extension like myscript.sh, but this is just a convention. Linux doesn't require an extension for scripts to work. The executable permission and shebang line matter much more than the filename.

chmod 755 sets file permissions where 7 means the owner can read, write, and execute, and 5 means others and the group can only read and execute. For shell scripts, 755 is standard because it makes the script executable while protecting it from accidental changes by other users.

Use the chmod command. The most common way is chmod +x scriptname which adds execute permission for everyone. Another way is chmod 755 scriptname which sets specific read, write, and execute permissions in numeric notation.

chmod +x adds execute permission to a file for all users - owner, group, and others. After running this command, you can run the script using ./scriptname directly from the command line instead of having to type bash scriptname.

Yes, you can still run it using bash scriptname or sh scriptname even if the execute bit isn't set. However, you cannot run it directly using ./scriptname. For production scripts and automation, you need the execute permission set.

The ./ means execute this file from the current directory. Without the ./, the shell would look for the script in your PATH variable and fail if it's in the current directory. The ./ explicitly tells the system to look in the current working directory.

PATH is an environment variable that contains a list of directories where the shell looks for executable programs. When you type a command like ls or grep, the shell searches through these directories in order to find the actual executable file. If a program isn't in your PATH, you have to use the full path to run it.

Type echo $PATH in the terminal. This shows all the directories separated by colons. For example, /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin. The shell searches these in order from left to right.

Use export PATH=$PATH:/new/directory in the terminal or add this line to your ~/.bashrc file. This adds the new directory to the end of your PATH so the shell will search there. Changes in ~/.bashrc take effect when you open a new terminal or run source ~/.bashrc.

Environment variables are key-value pairs that store configuration information for your shell and programs. Examples include PATH, HOME, USER, and SHELL. Processes inherit environment variables from their parent shell, so scripts can access this information.

A regular variable exists only in the current shell session and is not inherited by child processes. An environment variable is marked with export and is available to all child processes spawned by the shell. If you want a script to use a value, make it an environment variable.

You can use vi, vim, nano, gedit, or any plain text editor. For beginners, nano is simpler with built-in help. For production work and experienced users, vim offers powerful editing capabilities. Never use word processors like LibreOffice because they add formatting that breaks scripts.

Word processors add invisible formatting codes, line breaks, and special characters that aren't plain text. When you try to run a script created in a word processor, the shell gets confused by these hidden characters and the script fails to execute correctly.

Nano is a beginner-friendly text editor. Type nano filename to create or edit a file. You can use Ctrl+O to save, Ctrl+X to exit, and Ctrl+K to cut lines. Nano shows all commands at the bottom of the screen, making it easy to learn.

Echo prints text to the terminal. In scripts, you use echo to display messages, values of variables, or status updates. For example, echo "Script is starting" shows that text on the screen when the script runs.

Use echo $variablename. For example, if you set NAME="Linux", then echo $NAME will print Linux. The dollar sign $ tells the shell to substitute the variable's value.

Double quotes allow variable expansion - echo "$NAME" will print the value of NAME. Single quotes treat everything literally - echo '$NAME' will print the text $NAME without expanding the variable. Choose based on whether you want the shell to interpret variables.

Use the syntax VARIABLE_NAME=value with no spaces around the equals sign. For example, USERNAME="john" creates a variable named USERNAME with the value john. Variable names are case-sensitive.

Both access the variable's value. The curly braces ${VARIABLE} are useful when the variable is followed by text that could be interpreted as part of the name. For example, echo ${NAME}_file works correctly, while echo $NAME_file tries to access a variable called NAME_file.

The read command pauses a script and waits for the user to type input from the keyboard. Whatever the user types gets stored in a variable that you specify. For example, read USERNAME waits for input and stores it in the USERNAME variable.

Type read VARIABLE in your script. The script will pause and wait for the user to type something and press Enter. That input is now stored in VARIABLE and you can use it in the rest of your script.

Use echo to print a message, then read on the next line. For example: echo "Enter your name:" followed by read NAME. Or use read -p "Enter your name: " NAME which includes the prompt in the read command itself.

Yes, you can do read FIRST LAST to capture two values in one command. The user types both values separated by a space, and they get stored in FIRST and LAST. If the user provides more values than variables, the extra values go into the last variable.

Three main ways: (1) ./scriptname if the file has execute permission, (2) bash scriptname to run it with Bash explicitly, (3) source scriptname to run it in the current shell without spawning a new process. For most cases, ./scriptname is best because it uses the shebang to pick the right interpreter.

bash scriptname explicitly runs the script with Bash, ignoring the shebang line. This is useful for testing or if the script doesn't have the shebang. The ./scriptname method respects the shebang and is more portable because it works with any shell type.

The source command (or . for short) runs a script in the current shell instead of spawning a new one. Variables and changes made by the script affect your current session. This is useful for loading configuration files or functions, but not for most executable scripts.

bash -x runs your script in debug mode. The shell prints each command before executing it, prefixed with a plus sign. This helps you see exactly what the script is doing and find where errors occur. Use it when your script isn't working as expected.

A comment is text that the shell ignores when running the script. It starts with # and goes to the end of the line. Use comments to explain what your code does, making it easier for you and others to understand later.

At the top of the script, include your name or team, the date, what the script does, and any requirements. For complex sections, add line comments explaining the logic. In production, this documentation helps other engineers maintain your code or quickly understand what went wrong.

Yes, add # to the beginning of each line you want to disable. This is useful for testing or debugging. Some editors let you select multiple lines and comment them all at once, which is faster than editing each line individually.

Start with #!/bin/bash, then add comments explaining the script, then declare variables, then write the main logic with functions if needed, and finally cleanup or exit statements. This structure keeps scripts organized and maintainable even as they grow.

An if statement checks whether a condition is true or false. If true, the script executes one block of commands. If false, it skips to the next part. This lets your script make decisions instead of running the same commands every time.

The structure is: if [ condition ]; then commands fi. The [ and ] are test operators. The semicolon separates the condition from "then". The "fi" closes the statement.

Use the -f option: if [ -f filename ]; then ... fi. The -f tests if a regular file exists. Use -d to test for directories. These tests are essential when your script needs to work with files.

In Bash, both = and == compare strings and work the same way in [ ] tests. Use [ "$VAR" = "value" ] to check if two strings match. The = operator is more portable across different shells.

A loop repeats a block of commands multiple times. Instead of writing the same commands over and over, you write them once inside a loop that executes them as many times as needed. Loops are essential for processing lists of items or repeating tasks.

Bash has for loops, while loops, and until loops. A for loop runs a set number of times. A while loop continues while a condition is true. An until loop continues until a condition becomes true. Choose based on whether you know in advance how many repetitions you need.

The structure is: for variable in list; do commands using $variable done. The variable takes each value from the list, one iteration at a time. The done keyword closes the loop.

Use for file in *.txt; do ... done to loop through all .txt files. The * is a wildcard that matches filenames. Inside the loop, $file holds the current filename. This is common when processing multiple files with the same script logic.

A while loop runs as long as a condition is true. When the condition becomes false, the loop stops. Use while loops when you don't know in advance how many iterations you need, like reading lines from a file until there are no more lines.

Command substitution runs a command and uses its output as input to another command or assigns it to a variable. Use the syntax $(command) or backticks `command`. For example, TODAY=$(date +%Y-%m-%d) captures today's date in a variable.

Use VARIABLE=$(command) or VARIABLE=`command`. The modern syntax $(command) is preferred because it's clearer and nests better. For example, FILES=$(ls *.txt) puts the list of text files in FILES.

Output redirection sends a command's output to a file instead of the terminal. Use > to overwrite a file: echo "text" > file.txt. Use >> to append: echo "more" >> file.txt. This lets your script save results or logs for later review.

The > operator overwrites the file with new content, erasing what was there before. The >> operator appends new content to the end of the file. Use >> when building log files or appending results over time.

An exit code is a number returned by a command that indicates success or failure. Exit code 0 means success. Any non-zero value means failure. In scripts, you check exit codes using $? to know if a command worked before proceeding.

Type echo $? to see the exit code of the previous command. In a script, test the exit code immediately after the command you're checking because $? changes with every new command.

Use the exit command with a number: exit 0 for success, exit 1 for failure. You can use different numbers for different errors. At the end of your script, exit 0 signals that everything completed successfully.

The && operator means "run the next command only if the previous one succeeded". The || operator means "run the next command only if the previous one failed". For example: grep "error" log.txt && echo "Errors found" || echo "No errors".

Production scripts run without human supervision. If a command fails and you don't check for it, the script continues with bad data and causes bigger problems. Error handling catches these issues early and either fixes them or stops the script before damage occurs.

The shell treats it as a command instead of a variable assignment. For example, NAME=John works fine, but NAME = John fails because the shell tries to execute NAME as a program with = and John as arguments.

Without execute permission, you cannot run the script directly with ./scriptname. You'll get a permission denied error even though the script logic is correct. Always remember to chmod +x after creating a script.

Without quotes, variables with spaces break into multiple arguments. For example, echo $VAR with VAR="hello world" prints two separate values, not one. Using echo "$VAR" keeps it as a single value. In scripts, proper quoting prevents unexpected word splitting and globbing.

You forgot to use ./ before the filename. Without ./, the shell looks in PATH and doesn't check the current directory. Always use ./scriptname to run scripts in your current directory, or add the current directory to PATH with caution.

The simplest working script contains: #!/bin/bash and at least one command. For example: echo "Hello, World!". That's it. Save this, run chmod +x on it, and then ./scriptname to execute.

Start with shebang and comments describing what it backs up. Define variables for source and destination directories. Check if the source exists, create a timestamp in the backup filename, copy files, and check the exit code. This structure ensures your backups are reliable and traceable.

You need a text editor (nano, vim, or gedit), and the basic Unix utilities that come with Linux. Most systems have everything pre-installed. The only real requirement beyond that is understanding how to use the tools you have.

Test it in a development environment with test data first. Use bash -x to debug any issues. Have someone else read through the logic if possible. Run it several times with different inputs to make sure it handles edge cases gracefully.

Proper error handling with exit codes, helpful comments explaining the logic, logging to track what the script did, cleanup of temporary files, and documentation for other engineers who might maintain it later.

Use functions to break repetitive code into reusable blocks, use meaningful variable names, add comments before each section, keep the logic flow clear and linear, and avoid nesting conditionals too deeply. Scripts that are easy to read are easy to debug and modify later.

Keep initial answers short and direct, two or three sentences. Save the deeper explanations and edge cases for follow up questions. If the interviewer wants more detail, they will ask for it.

Understanding the concept matters much more than exact memorization. Know that PATH is colon-separated directories and that order matters. If you forget the exact syntax, saying "I would check with echo $PATH" is a completely acceptable answer.

Say it starts with #! and the interpreter path, and that you would look up the exact path if needed. Saying "it's something like #!/bin/bash to tell the system to use Bash" is good enough and shows you understand the concept.

Yes, fairly often at Level 1. Expect short tasks like creating a script that uses variables and loops, or one that checks if files exist. Make sure you can write these without looking them up.

Not at all. Many candidates haven't hit this in their early career. Just be able to explain why PATH problems happen once they're described to you. Understanding the mechanism matters more than having lived through every scenario.

Only if it fits naturally into the conversation. Forcing in advanced topics usually reads as trying too hard rather than genuine expertise. Answer what's asked, and let the interviewer steer into deeper topics if they want.