Top 55 Bash Scripting Interview Questions and Answers for Freshers

A bash script is a plain text file that contains a series of bash commands. When you run it, the shell executes those commands in order, exactly as if you had typed them yourself in the terminal one by one.

On a real Linux system, bash scripts handle the tasks that would otherwise eat your time: automated backups, user account creation, log cleanup, service restarts. Anything repetitive is a candidate for a script.

The shebang is the first line of a script, written as #!/bin/bash. It tells the operating system which interpreter to use when running the file. Without it, the system does not know whether to treat the file as a bash script, a Python script, or something else.

In production, scripts get run by cron jobs, automation tools, and other users who may be in a different shell environment. The shebang guarantees that bash always runs your bash script, regardless of what shell the user has set as their default.

You use chmod +x scriptname.sh to give the file execute permission, then run it with ./scriptname.sh from the directory where it lives.

The ./ tells the shell to look in the current directory. Without it, the shell searches only the directories listed in your PATH variable and will not find your script unless it is in one of those locations.

For most beginner scripts these behave identically. But in environments where scripts use a different shebang, or where permission controls matter, the distinction is real.

Any line that starts with a # character is a comment. Bash ignores it completely during execution. The shebang on line one is actually an exception to this because the kernel reads it before bash takes over.

Comments are not optional in production scripts. A script that runs perfectly but has no comments becomes a debugging nightmare six months later when someone else needs to modify it at two in the morning.

A variable stores a value you want to reuse. You declare it without spaces: NAME="linuxteck". You read it back with a dollar sign: $NAME or ${NAME}.

Spaces matter here. NAME = "linuxteck" with spaces will throw an error because bash interprets it as a command named NAME with arguments. That catches beginners constantly.

The echo command prints text or the value of a variable to standard output. It is one of the most used commands in scripting for displaying messages, logging output, and debugging.

In real scripts, echo is often redirected to a log file instead of printing to screen, which is how automated scripts create their own audit trail. If you want to go deeper on how echo works inside scripts, the guide on using echo in shell scripts covers the practical patterns well.

Double quotes allow variable expansion and command substitution. Single quotes treat everything literally and suppress all expansion.

If you write echo "$USER", bash replaces $USER with the actual username. If you write echo '$USER', the output is the literal string $USER. This difference causes real bugs when people use single quotes expecting variable values and get the variable name instead.

Use the read command. It pauses the script, waits for the user to type something and press Enter, then stores that input in the variable you specify.

Example: read -p "Enter your name: " USERNAME prompts the user and stores their answer in USERNAME. The -p flag lets you put the prompt text on the same line as the cursor, which looks cleaner than echoing first and reading separately.

Exit code 0 means the command or script completed successfully. Any non-zero exit code means something went wrong. The specific number gives more detail about what kind of failure occurred.

In automated pipelines and cron jobs, exit codes are how the system knows whether to continue or alert. A script that always exits 0 even when it fails silently breaks automation. This is why professional scripts always check exit codes and exit with the right value.

The script outputs: Hello, Linux

The variable NAME is assigned the string "Linux". When echo runs with double quotes, bash expands $NAME to its value before printing. So the output is the expanded string, not the literal characters.

The output would be:

$0 always holds the script name as it was called. $1 is the first argument passed to the script. $# is the count of all arguments. "hello" and "world" are two separate arguments so the count is 2.

The -f flag checks whether a path exists and is a regular file (not a directory or device file). On any standard Linux system, /etc/passwd always exists, so the output would be:

File existence checks like this are foundational. Any script that reads a config file or log should check whether the file is there before trying to open it. Skipping that check causes confusing errors when files are missing.

The loop runs three times, once for each value in the list.

The variable i takes each value in turn. The do...done block is the body of the loop. This basic structure is how you automate repetitive tasks across multiple values or files.

Start with the shebang, then echo the message. Simple and correct wins here.

Every script needs the shebang. Without it, you are depending on the calling environment to interpret the file correctly. Adding it costs nothing and avoids real problems in automated contexts.

Use $1 to capture the first argument. Add a check so the script gives a clear message if nothing was passed.

The -z flag tests whether a string is empty. Checking for missing arguments and exiting with a non-zero code is basic defensive scripting. It shows the interviewer you think about how a script will behave when someone uses it incorrectly.

Check for the directory first using -d, then create it only if it is missing.

The ! negates the condition. -d checks for a directory. Wrapping the variable in quotes handles paths with spaces safely. This pattern appears constantly in real admin scripts, especially those that set up backup or log directories.

Use a for loop with brace expansion for a clean range syntax.

Brace expansion {1..5} generates a sequence without needing seq or any external tool. Clean and readable. For loops with ranges are used everywhere in admin scripting, from processing numbered files to iterating over server lists.

Accept the file path as an argument and use the -f test to check it.

Exiting with 1 when the file is missing makes this script composable. If another script calls this one and the file check fails, the calling script can detect the failure and respond. That kind of thinking is what separates a script written for one use from one written to be reliable in a real environment.

Use a counter variable and increment it inside the loop with arithmetic expansion.

The -le flag means "less than or equal to." The ((COUNT++)) increments the counter. Without incrementing, the loop runs forever. That is one of the most common beginner bugs and something interviewers watch for.

This trips up people with Python or JavaScript backgrounds most often. The error message is also confusing because it does not say "variable assignment failed." It says the variable name is not a recognized command.

$? holds the exit code of the most recently executed command or script. Zero means success. Anything else means failure.

This is how you check whether a command worked inside a script. You run the command, then immediately check $? before running anything else, because the next command will overwrite it.

These syntax errors are easy to introduce and sometimes hard to find in a longer script. Indenting your code consistently makes them much easier to spot.

Command substitution lets you capture the output of a command and use it as a value. The modern syntax is $(command). The older syntax uses backticks: `command`.

Example: DATE=$(date +%Y-%m-%d) stores today's date in the variable DATE. This is used all the time in backup scripts, log file naming, and timestamped output.

Both hold all the arguments passed to a script. The difference shows up when they are quoted. "$*" treats all arguments as a single string. "$@" preserves each argument as a separate item.

In practice, almost always use "$@" when you need to loop over or pass along arguments. If any argument contains a space, "$*" will break it incorrectly while "$@" handles it properly.

The -e flag enables interpretation of escape sequences like \n for newline and \t for tab. Without it, those sequences print literally.

The reason to be cautious: echo -e is not consistent across all systems. On some, it works as expected. On others with a POSIX-only echo, it does not. If you need reliable escape sequence handling in a portable script, printf is the safer choice.

In practice, setting execute permission with chmod +x is the standard approach. But knowing this distinction matters when you encounter a script someone else created without proper permissions.

set -e tells bash to exit immediately if any command in the script returns a non-zero exit code. Without it, bash continues to the next line even after a command fails.

This is a very common first line after the shebang in production scripts because it prevents scripts from quietly continuing after an error and doing something destructive with a broken state.

This redirects standard error (file descriptor 2) to wherever standard output (file descriptor 1) is currently going. If you are writing output to a log file, adding 2>&1 means errors go to that same log file instead of printing to the terminal.

Without it, your log file gets stdout but errors disappear or go to the terminal. In automated scripts running via cron, those error messages would go nowhere useful. Combining both streams into one log is standard practice.

A bash script uses #!/bin/bash. A Python script uses #!/usr/bin/env python3 (or the direct path). The distinction matters whenever you are running scripts in an automated environment that does not inspect the extension, because the shebang is the only reliable way the OS knows which interpreter to invoke.

In a Linux admin environment where you have both bash and Python scripts running side by side, mixing up the shebang means the wrong interpreter tries to run the file and fails in confusing ways.

Double brackets are a bash extension that adds pattern matching, regex matching with =~, and cleaner handling of strings with spaces. Single brackets are POSIX-compatible and work in all shells.

Double brackets also do not require you to quote variables as aggressively, which reduces certain classes of bugs. For scripts that will only ever run in bash, double brackets are generally the more robust choice.

PATH is a colon-separated list of directories the shell searches when you type a command. If you type ls, bash looks through each directory in PATH until it finds an executable named ls.

If a command is not in any of those directories, you get "command not found." This is why running your own scripts requires either putting them in a PATH directory or using ./ to run from the current directory. Understanding PATH also helps you diagnose issues where a tool is installed but not accessible.

The chmod command changes file permissions. chmod 755 sets read, write, and execute for the owner (7), and read and execute for group and others (5 each).

This is a standard permission set for scripts and directories. The owner can run and edit the file. Everyone else can run it but not modify it. For a public-facing script or binary, 755 is the typical choice.

An absolute path starts from the root of the filesystem: /etc/passwd. It works regardless of what directory you are in. A relative path is relative to the current working directory: ./config.txt or ../logs/app.log.

Scripts that use relative paths can break silently when run from a different directory than expected. This is a common source of bugs in cron jobs, where the working directory is often different from what the script author assumed. Using absolute paths in scripts is safer and more predictable.

grep searches text for lines matching a pattern and prints the matching lines. It is one of the most used commands in bash scripting for filtering output and parsing files.

A basic example: searching the /etc/passwd file for a specific user. If you need a deeper look at how grep integrates into real scripting workflows, the article on how bash uses grep for text processing covers it well.

The -q flag makes grep quiet (no output, just exit code). Using it inside an if statement is clean and efficient.

A single > overwrites the file completely each time. Double >> appends to the file, preserving whatever was already there.

In log-writing scripts, you almost always want >>. Using > in a log script accidentally wipes your entire log every time the script runs. That mistake has caused real production pain for many people.

/dev/null is a special file that discards everything written to it. Redirecting output there silences it completely.

Use it when you want a command to run silently without cluttering the terminal or log. Common in scripts where you run a check and only care about the exit code, not the output: grep -q "pattern" file 2>/dev/null. It also silences error messages for commands that might fail but where the failure is expected and acceptable.

The test command evaluates conditions and returns an exit code. The [ ] syntax is a shorthand alias for test. They are functionally equivalent.

So if test -f /etc/hosts and if [ -f /etc/hosts ] do the same thing. The bracket syntax is more readable in scripts, which is why it is the one you see in practice. Understanding that [ is actually a command (and needs a space before the closing ]) explains a class of errors beginners hit when they write [condition] without spaces.

A regular shell variable is only available in the current shell session. An environment variable has been exported and is available to all child processes spawned by that shell. The export command promotes a shell variable to an environment variable.

This matters in scripting because a child script does not inherit the parent's shell variables unless they have been exported. Scripts that expect a variable to be available and it is not will either error out or use an empty value silently, depending on the script.

The source command (written as source filename or . filename) runs a script in the current shell rather than in a subprocess. Variables set inside the sourced file are available after it finishes, in your current session.

This is how configuration files and shell profile scripts like ~/.bashrc work. When you run source ~/.bashrc, the new settings take effect immediately in your current shell. If you ran it as a normal script with ./bashrc, the changes would only apply to a subprocess and disappear when that subprocess exited.

A bash function groups reusable commands under a name you can call multiple times. You define it with the function name followed by parentheses and a block wrapped in braces.

Functions make scripts shorter and easier to maintain. Instead of repeating the same twenty lines in three places, you write them once and call the function. That is how professional scripts are structured.

The case statement matches a variable or expression against a list of patterns and runs the matching block. It is cleaner and more readable than a chain of if-elif when you are testing a single variable against multiple fixed values.

If you are writing a script with a menu that accepts options like "start", "stop", "restart", a case statement handles that naturally. The same logic written as if-elif gets long and repetitive fast.

A heredoc lets you feed multiple lines of text to a command without creating a separate file. You open it with <<EOF and close it with EOF on its own line.

Common in scripts that generate config files, send formatted emails, or pass blocks of SQL to a database. It keeps the content inline with the script rather than requiring an external template file.

Use double parentheses for arithmetic: result=$((5 + 3)). This is cleaner than the older expr command and handles standard operators including addition, subtraction, multiplication, division, and modulo.

One important note: bash integer arithmetic only. It does not handle decimal numbers natively. For floating point math you need a tool like bc.

-z tests whether a string is empty (zero length). -n tests whether a string is non-empty. These are used constantly for validating arguments and variables.

A script that does not check whether required variables are set before using them will either throw confusing errors or silently do something wrong. -z checks are your first line of defense against that.

The pipe connects commands so the output of one becomes the input of the next. It is one of the core ideas that makes Linux so powerful for text processing and automation.

Real example: ps aux | grep nginx | grep -v grep shows all running nginx processes without showing the grep command itself. This kind of pipeline is used constantly in monitoring and troubleshooting scripts.

Open the crontab editor with crontab -e. Add a line with the schedule in cron format followed by the full path to your script.

Example: 0 2 * * * /home/admin/backup.sh runs the script at 2 AM every day. Using full paths is critical in cron jobs because cron runs with a minimal environment and often does not have your PATH set the way your interactive shell does. Scripts that work fine manually often fail in cron because of this.

When you run a script or use parentheses ( ), bash creates a subshell: a child process with a copy of the current environment. Changes made inside a subshell do not affect the parent shell.

This is why you cannot change the working directory of your terminal by running cd /somewhere inside a script and having it stick after the script exits. The cd happened in a subshell. The parent shell's directory did not change.

The find command searches the filesystem for files and directories matching criteria you specify: name, type, age, size, permissions, and more. It is indispensable for maintenance scripts.

A common example is finding and deleting log files older than 30 days: find /var/log/myapp -name "*.log" -mtime +30 -delete. This kind of cleanup script runs in cron jobs on almost every production Linux server. For more on the find command specifically, the find command guide with examples covers the full range of flags and use cases.

Bash scripting automates anything a human would otherwise do manually in the terminal. It is the backbone of Linux system administration.

Three concrete examples: First, automated backups that compress directories and copy them to a remote server on a schedule. Second, user provisioning scripts that create accounts, set passwords, assign groups, and create home directories with one command instead of fifteen. Third, monitoring scripts that check disk space, CPU load, or service health and send an alert when something crosses a threshold. These are not academic examples. They run on real servers every day.

A hard link points directly to the same inode as the original file. A symbolic link (symlink) points to the file path. Delete the original file and the hard link still works. Delete the original and the symlink breaks.

In scripting, symlinks come up constantly for managing configuration files, versioned binaries, and shared resources. Knowing the difference helps you avoid creating links that silently break when files move or get deleted.

Start with bash -x scriptname.sh. The -x flag enables trace mode, which prints each command as it executes with the actual values substituted in. You see exactly what bash is doing, line by line.

You can also put set -x at a specific point inside the script to turn tracing on only for the part you are investigating, then set +x to turn it off. Adding echo statements to print variable values at key points is the other common approach when you need something quick without full tracing.

An idempotent script produces the same result whether you run it once or ten times. Running it a second time does not create problems, duplicate entries, or undo what the first run did.

This matters because automated scripts often run on schedules or get re-run after failures. A script that creates a user without checking whether that user already exists will error (or worse, corrupt something) on the second run. The directory-creation example earlier shows this principle: check first, act only if needed.

Use the tee command. It reads from standard input and writes to both standard output and a file at the same time.

Example: echo "Backup started" | tee -a /var/log/backup.log prints the message to the terminal and appends it to the log file. The -a flag appends instead of overwriting. This pattern is standard in production scripts where you want visibility on screen during a run and a written record after.

wc counts words, lines, and characters. The most common flag in scripting is -l, which counts lines.

Example use: counting how many lines are in a log file, or counting how many users exist in /etc/passwd with wc -l /etc/passwd. You can also capture the count in a variable: COUNT=$(wc -l < /etc/passwd) and use it in a condition or report.

Phone screens are about signal, not depth. Give the correct answer in two or three clear sentences. Show you know the concept and one real application of it. Save the detailed explanation for when they probe further. Technical rounds give you more time, so there you should naturally extend your answer with a concrete example or edge case without waiting to be asked.

At Level 1, syntax recall matters more than at higher levels. Interviewers expect you to know how to write a basic for loop, a simple if statement, and variable assignment without hesitating. For more advanced flags and options, explaining the concept and saying you would verify the exact syntax with a man page is completely acceptable. What they cannot forgive is not knowing whether the tool exists or what it broadly does.

Yes. Say it directly and without apology: "I know grep has a flag for quiet mode that only returns the exit code. I believe it is -q but I would confirm with the man page." This is exactly what a real engineer does. Interviewers who work in production know that nobody has every flag memorized. What they are watching for is whether you know the tool exists, roughly how to use it, and that you verify before deploying. That is the right instinct.

Sometimes. More often at Level 1 they will give you a partial script and ask you to complete it, or show you a script and ask what it does. Full from-scratch writing tends to show up more in second-round technical interviews. That said, you should absolutely be able to write a basic script from scratch: shebang, variable, if statement, loop, output. If you practice those five building blocks until they feel natural, you will handle whatever they put in front of you.

Be honest and steer toward what you do know. "I have not worked with that specific feature, but based on how bash handles similar things, I would expect..." shows intellectual honesty and reasoning ability. Guessing confidently and being wrong is worse than admitting a gap and showing you can reason adjacent to it. Interviewers remember the candidates who think clearly under uncertainty. They forget the ones who confidently got things wrong.

Yes: show that you think about error handling and real-world usage without being asked. If they ask you to write a script and you add an argument check or a file existence test, that is exactly the kind of initiative they are looking for. It signals that you have thought about what happens when things go wrong, not just when they go right. You do not need to overload the answer. Just one defensive addition goes a long way.