ExamFinch.com My Study

Study guide

3.3c Editors, chmod +x, and Running Scripts

Practice this exam

LPI Linux Essentials Certificate 010-160

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Study Strategy & Blueprint Weights

2 Topic 1: The Linux Community and a Career in Open Source

1.1 Linux Evolution and Popular Operating Systems 1.2 Major Open Source Applications 1.3 Open Source Software and Licensing 1.4 ICT Skills and Working in Linux

3 Topic 2 Part A: Command Line Basics & Getting Help

2.1a Bash Shell, Command Syntax & Variables 2.1b Quoting, History & Safe Command Syntax 2.2 Using the Command Line to Get Help

4 Topic 2 Part B: Directories, Listing & File Operations

2.3 Using Directories and Listing Files 2.4 Creating, Moving and Deleting Files

5 Topic 3 Part A: Archiving & Searching Data

3.1 Archiving and Compression on the Command Line 3.2a Pipes, Redirection, and Basic Regular Expressions 3.2b grep and Text Extraction Tools

6 Topic 3 Part B: Turning Commands into Scripts

3.3a Script Basics: Shebang, Variables, and Arguments 3.3b Loops, Exit Status, and Simple Conditionals 3.3c Editors, chmod +x, and Running Scripts

7 Topic 4 Part A: Choosing an OS, Hardware & FHS Basics

4.1 Choosing an Operating System 4.2 Understanding Computer Hardware 4.3a Where Programs and Configuration Live (FHS Basics)

8 Topic 4 Part B: Processes, Logs & Networking

4.3b Processes, Memory & Logs 4.4 Your Computer on the Network

9 Topic 5: Security and File Permissions

5.1 Basic Security and Identifying User Types 5.2 Creating Users and Groups 5.3 Managing File Permissions and Ownership 5.4 Special Directories and Files

3.3c Editors, chmod +x, and Running Scripts

Key Takeaways Explain This Topic AI

Create and edit scripts with terminal editors such as nano (beginner-friendly) or vi/vim (ubiquitous on servers)

chmod +x script.sh adds the execute permission so the file can run as a program

./script.sh runs an executable script in the current directory using its shebang interpreter

bash script.sh runs the file through Bash explicitly and does not require the execute bit

  • Without execute permission, ./script.sh fails with Permission denied even if the shebang is correct
  • Last updated: July 2026

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

  • Editor Character Typical start
  • nano Simple, on-screen shortcut reminders nano hello.sh
  • vi / vim Classic modal editor on almost every Unix-like system vi hello.sh

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

  • Form Effect
  • chmod +x hello.sh Add execute for user/group/others per umask-influenced defaults (common teaching form)
  • chmod u+x hello.sh Add execute for the owner only

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 :

Shell finds ./hello.sh as an executable file.

Kernel reads the shebang #!/bin/bash .

Bash runs the remaining lines.

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

Method Execute bit required? Shebang used?

  • ./script.sh Yes Yes—kernel uses shebang
  • bash script.sh No Bash runs the file directly; shebang optional for this call

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.