3.3c Editors, chmod +x, and Running Scripts

Editors, Making Scripts Executable, and How to Run Them

A script that exists only in your head helps nobody. Linux Essentials expects you to create script files with a text editor, mark them executable, and know the difference between ./script.sh and bash script.sh. Stay at awareness-plus-practice depth: you must start an editor and save a file, not memorize every vi keybinding.

Editors you should recognize: nano and vi

nano is friendly for beginners: type normally, then save and exit with the shortcuts shown at the bottom (commonly Ctrl+O write out / save, Ctrl+X exit). Use it when available to draft #!/bin/bash scripts quickly.

vi (and improved vim) appears on minimal servers where nano may be missing. Essentials-level awareness:

• Start with vi file or vim file.
• Press i to enter insert mode and type text.
• Press Esc, then type :wq and Enter to write and quit (or :q! to quit without saving).

You do not need advanced macros for this exam. You do need to know that both editors create the same kind of plain-text script file, and that the shebang must still be the first line when you save.

GUI editors exist on desktop Linux, but the objectives highlight command-line editing because remote servers and exam scenarios assume a terminal.

File permissions and chmod +x

Linux decides whether a file can run as a program using execute permission. Listing a new script often shows something like:

-rw-r--r-- 1 user user  42 Jul 23 10:00 hello.sh

There is no x in the permission string yet—only read/write for the owner and read for others. Running ./hello.sh in this state typically fails with Permission denied.

Add execute permission with chmod:

chmod +x hello.sh

Afterward, ls -l hello.sh should show an x (for example -rwxr-xr-x or -rwx--r-- depending on exact mode). Topic 5 covers octal modes such as 755 in more depth; for scripting, chmod +x is the phrase to wire to “make this script runnable.”

Remember: chmod changes mode metadata; it does not rewrite the shebang. Both pieces matter: correct contents and execute permission for ./ invocation.

Running with ./script.sh

Once the file is executable and begins with #!/bin/bash:

./hello.sh
./greet.sh Ada

The ./ prefix means “this file in the current directory.” Linux does not search . via PATH by default (a security practice). If you omit ./ and type only hello.sh, the shell looks through PATH directories and usually says command not found even though the file sits beside you.

Flow for ./hello.sh:

1. Shell finds ./hello.sh as an executable file.
2. Kernel reads the shebang #!/bin/bash.
3. Bash runs the remaining lines.
4. Positional parameters receive any extra arguments you typed.

Running with bash script.sh

You can also feed the file to Bash explicitly:

bash hello.sh
bash greet.sh Ada

bash script.sh is ideal while drafting: edit, save, test, without chmod yet. Before publishing or scheduling a tool others will call as ./tool.sh, add chmod +x and verify the shebang.

Related forms you may see: sh script.sh runs with sh (may be a smaller shell than Bash—prefer bash when the script uses Bash features). Essentials examples stick to Bash.

End-to-end mini lab

nano backup-echo.sh

File contents:

#!/bin/bash
echo "Backing up $1"
echo "Args given: $#"

Then:

chmod +x backup-echo.sh
./backup-echo.sh /home/ada/docs

Expected idea: message naming /home/ada/docs and argument count 1. If you see Permission denied, re-check ls -l for an x. If you see command not found, you probably forgot ./. If nothing meaningful prints, confirm you saved the file and that echo lines are not commented out.

Comparing the two run styles side by side

# Draft / debug (no execute bit needed)
bash ~/bin/hello.sh

# “Real” program-style run (needs chmod +x and usually a shebang)
chmod +x ~/bin/hello.sh
~/bin/hello.sh
# or, if you cd into that directory:
cd ~/bin
./hello.sh

Absolute or home-relative paths (/home/ada/bin/hello.sh, ~/bin/hello.sh) also work when the execute bit is set—the ./ rule is specifically about relative names that rely on the current directory. In all executable cases, the shebang still selects the interpreter.

Exam traps

• Confusing read permission with execute—reading a script (bash file or cat file) is not the same as ./file requiring x.
• Believing .sh alone makes a file executable—extension does not grant x.
• Forgetting ./ when the script is in the current directory.
• Putting spaces in chmod + x or inventing flags the exam did not teach.
• Assuming vi and nano produce different “kinds” of scripts—they both write plain text; only content and permissions matter at runtime.

Tie the chapter together: edit with nano/vi → shebang + variables + args → loops/$?/if → chmod +x → run ./script.sh (or bash script.sh while testing). That workflow is objective 3.3 in practice.