Top 50 Bash Script Basics Interview Questions for Beginners (Part 4/8)

The shebang is the first line of a script, written as #!/bin/bash. It tells the operating system which interpreter should run the rest of the file. Without it, the system falls back to your current shell, which may not behave the way your script expects.

#!/bin/bash points directly at the bash interpreter and gives you access to bash-only features like arrays and certain string operations. #!/bin/sh often points to a lighter shell such as dash on many distros, which does not support all bash syntax.

The script will still run in most cases if you call it with bash script.sh, since you are explicitly telling the shell which interpreter to use. But if you try to run it directly as ./script.sh, it uses your default shell to guess, which can lead to unexpected errors on systems where that default is not bash.

Yes. Bash is usually at /bin/bash, but on some systems, especially certain BSD or minimal container images, it might live somewhere else like /usr/local/bin/bash. This is why some scripts use #!/usr/bin/env bash instead, which searches the PATH for bash rather than hardcoding a location.

It makes the script more portable. Instead of assuming bash is at one fixed path, env looks through the PATH variable and finds whichever bash is available first. This matters a lot in environments where bash is installed in a non-standard location, like some macOS setups or virtual environments.

No. The shebang must be the very first line of the file, with nothing above it, not even a blank line or comment. If anything comes before it, the kernel treats the file as plain text and the special shebang parsing is skipped entirely.

Technically none is required. Linux does not care about file extensions the way Windows does, it reads the shebang line to decide how to run the file. Using .sh is just a convention that helps humans and editors recognize the file type.

You can use touch to create an empty file, like touch myscript.sh, then open it in an editor to add content. You can also just open a new file directly in an editor like nano or vim and save it with your chosen name.

Shebang line first, then a short comment block describing what the script does, then variable declarations, then the actual logic. Following this order every time makes scripts easier to read for anyone who opens them after you.

Production scripts get read and edited by other people, sometimes years later. A predictable layout means whoever touches it next does not have to reverse engineer your logic from scratch, which saves real time during incidents.

Linux blocks execution of a file unless the execute bit is set for the user trying to run it. Creating a file gives it read and write permission by default, but not execute permission, so you have to add it manually.

Run chmod +x myscript.sh. This adds the execute bit for the owner, group, and others depending on how you write the command. You can check it worked with ls -l, which shows an x in the permission string.

chmod +x adds execute permission relative to the file's current state. chmod 755 sets an absolute permission state, meaning read, write, and execute for the owner, and read and execute for the group and others, completely overwriting whatever permissions existed before.

You can run it with ./myscript.sh if it has execute permission and you know the path, or you can run it with bash myscript.sh without needing execute permission at all, since you are explicitly launching a new bash process to read the file.

Because you are not asking the system to execute the file directly, you are asking the bash program to read the file as input, similar to how a text editor only needs read permission to open a document. Execute permission is only enforced when the kernel is asked to run the file itself.

Bash searches the PATH variable to find commands, and your current directory is usually not part of PATH for security reasons. The ./ tells bash explicitly to look in the current directory instead of searching PATH.

Running a script with source myscript.sh or . myscript.sh runs it inside your current shell session rather than spawning a new subshell. Any variables it sets stay available in your terminal afterward, which is not the case with normal execution.

When you want a script's exported variables, functions, or aliases to persist in your current terminal session. A common real example is sourcing a configuration file like .bashrc after editing it, so changes apply immediately without opening a new terminal.

They need execute permission for the owner, which is the first x in a permission string like -rwxr--r--. Read permission alone is not enough for direct execution using ./.

No, this is a security risk on any real system. If a script is writable by everyone, any local user or compromised process could alter its logic before it runs, especially dangerous for scripts run by cron or root.

Anything after a # symbol on a line is treated as a comment and ignored by bash, except when it is part of the shebang. Comments can sit on their own line or trail after a command on the same line.

Not natively with dedicated syntax like some languages. A common workaround is a here-document assigned to nothing, or simply prefixing each line with #. Most sysadmins just stick to single-line comments for clarity anyway.

Just write name=value with no spaces around the equals sign. Bash is strict about this, spaces will make it interpret the line as a command instead of an assignment.

Prefix the variable name with a dollar sign, like $name or the safer ${name}. The curly brace form is useful when the variable name could get confused with surrounding text.

They usually produce the same output, but ${name} clearly separates the variable name from anything written right after it. For example ${name}_backup is unambiguous, while $name_backup would try to look for a variable literally called name_backup.

Yes. Name and name are treated as two completely different variables in bash. This is a common source of quiet bugs for people coming from languages that are more forgiving about casing.

Lowercase names are conventionally used for local or script-specific variables, while uppercase names like PATH or HOME are reserved for environment variables. Following this convention avoids accidentally overwriting an important system variable.

By default bash treats it as an empty string rather than throwing an error, which can silently break logic further down the script. This is exactly why many production scripts start with set -u, which forces bash to error out on unset variables.

Without quotes, bash performs word splitting and globbing on the value, which can break things badly if the variable contains spaces or special characters. Quoting keeps the value intact as a single string exactly as it was set.

Yes, using readonly name after it has a value. Any attempt to change it after that point produces an error, which is a small but useful safeguard for constants inside longer scripts.

The echo command is the simplest way, for example echo "Backup complete". It writes text to standard output, which by default shows up right in the terminal.

Put the variable inside the same echo string, like echo "Hello, $username". Double quotes allow variable expansion, so the actual value replaces the variable name in the output.

printf gives you formatting control that echo does not, like fixed decimal places or column alignment, and it behaves more consistently across different shells. It is closer to what you would expect from printf in C, which some engineers find more predictable.

Use the read command, for example read name pauses the script and stores whatever the user types into the variable name. You can pair it with a prompt using read -p "Enter name: " name.

An exit code is a number a script returns when it finishes, where 0 means success and any nonzero number means some kind of failure. Other scripts, cron jobs, and monitoring tools rely on this number to decide what to do next.

Use exit followed by a number, like exit 1 for a general error. If you never call exit explicitly, the script returns the exit status of the last command it ran.

The special variable $? holds it, and you have to check it right after the command since it gets overwritten by the next command you run. This is a common thing to forget when debugging.

Exit code 127 usually means "command not found." It is a strong hint that a typo exists somewhere, or a required program is not installed or not in the PATH.

Yes, echo just prints text a human can read, while exit sets a numeric code that other programs and scripts can check automatically. A script can echo a friendly error message and still exit with a proper failure code for automation to catch.

Leftover debug echo statements clutter real output and can confuse anyone reading logs later. It is better to remove them or wrap them behind a debug flag before the script goes anywhere near a production server.

It prints Hello, Linux Teck. The variable assignment has no spaces around the equals sign so it works correctly, and the double quotes let bash expand ${name} inside the echo string.

The spaces around the equals sign break the assignment. Bash reads name as a command it tries to run with arguments = and Linux, which results in a "command not found" error.

The permission string shows no x anywhere, meaning execute permission is missing for everyone including the owner. Running ./script.sh will fail with permission denied until chmod +x script.sh is run.

If run as a regular user without permission to write into /root, mkdir fails and echo $? prints a nonzero number, commonly 1. If run as root or a user with proper access, it would print 0 since the folder creation succeeded.

Use read to capture input into a variable, then echo it back inside a greeting string using double quotes so the variable expands correctly.

#!/bin/bash
read -p "Enter your name: " name
echo "Hello, ${name}! Welcome."

Run the file creation command directly inside an if condition, so success or failure is checked immediately rather than relying on a separate $? lookup that could be overwritten later.

#!/bin/bash
if touch report.log; then
    echo "File created successfully"
    exit 0
else
    echo "File creation failed"
    exit 1
fi

A clean header uses comment lines right after the shebang, listing the essentials any future reader needs before touching the logic below it.

#!/bin/bash
#
# Script: backup_check.sh
# Purpose: Verify daily backup completed
# Author: Ops Team
# Date: 2026-07-06
#

Chain the chmod and execution with a double ampersand so the second command only runs if the first one succeeds.

chmod +x deploy.sh && ./deploy.sh

Assign the value first, then mark it readonly so nothing later in the script can accidentally overwrite it.

backup_path="/var/backups"
readonly backup_path

No, at least not the way it is intended to. There is a blank line before the shebang, which means the shebang is no longer the first line of the file, so the kernel will not treat it as a special interpreter directive.

Write the shebang line first even before thinking about logic, since forgetting it is one of the easiest things to overlook under pressure. Then talk through your plan out loud before typing, it buys you thinking time and shows structured thinking.

Immediately check for invisible differences, spacing around equals signs, execute permissions, or a stray blank line before the shebang. Saying you would compare with cat -A to reveal hidden characters is a strong practical answer.

Briefly mentioning them shows you are already thinking ahead of your current level, which interviewers generally like. Just be ready to explain what they do in simple terms if asked, do not drop the term and move on without substance. Note: be sure to point out that using set -e can sometimes bypass your own custom error checking blocks, like an if block testing a command's result, because it terminates the script the instant a command fails, before your script even reaches that next line.

Say so plainly and explain how you would find out, like checking the man page or testing it in a sandbox terminal. Interviewers trust people who admit gaps honestly far more than people who guess confidently and get it wrong.

Yes, more than people expect, because exit codes are the foundation of how scripts get chained together in real automation. Even a junior role expects you to know what $? means and why 0 matters.

It is a warning sign to interviewers, since it suggests the script was copied rather than understood. Always be ready to explain every single line you write, even the ones that feel routine like the shebang or a quoting choice.