Terminal and command line for developers

Almost every development tool — Node.js, npm, Git, Docker — works from the command line first. In a graphical interface you click buttons; in a terminal you type short text commands and the computer answers in text. It is faster, more precise and easy to repeat: the same sequence of commands can be saved to a file and run again.

Three words get mixed up. MDN separates them like this: a terminal is the window program that starts a shell and connects to it; the shell is your session with its own settings, and it parses and runs commands; the command line is the line where the cursor blinks. In practice “terminal” and “command line” are used interchangeably, and that is fine.

Linux always ships a terminal, usually with bash. On macOS the default shell has been zsh since version 10.15 (per Apple Support); the commands in this lesson work the same way there. Windows opens PowerShell by default; for familiar Unix commands people install Git Bash — part of Git for Windows, it emulates bash — or a full Linux through WSL, which MDN recommends.

The key difference in PowerShell: its commands (cmdlets) pass .NET objects to each other, not text. For convenience it has aliases with familiar names: ls, cd, cat, rm call native PowerShell commands. You can check what an alias stands for like this:

PS> Get-Command ls, cd, pwd, cat, rm, cp, mv | Select-Object Name, Definition

Name Definition
---- ----------
ls   Get-ChildItem
cd   Set-Location
pwd  Get-Location
cat  Get-Content
rm   Remove-Item
cp   Copy-Item
mv   Move-Item

The shell is always “in” some directory — the current working directory. At startup it is your home directory. pwd shows where you are, ls shows what is around, cd moves to another directory. mkdir -p creates a directory together with any missing parents.

$ pwd
/home/ubuntu
$ mkdir -p projects/hello/src
$ cd projects/hello
$ pwd
/home/ubuntu/projects/hello
$ ls
src
$ cd src
$ pwd
/home/ubuntu/projects/hello/src
$ cd ..
$ cd ../..
$ pwd
/home/ubuntu
$ cd /home/ubuntu/projects/hello/src
$ cd ~
$ pwd
/home/ubuntu

• An absolute path starts at the root /: /home/ubuntu/projects/hello/src leads to the same place wherever you are.
• A relative path starts from the current directory: cd src works only if src is right here.
• .. is the parent directory, . the current one, ~ your home. cd with no arguments also takes you home.
• The Tab key completes a file or directory name once you have typed the beginning: fewer typos, less typing.
• Windows paths use backslashes (C:\Users\name), while Git Bash shows the same drive as /c/Users/name.

touch creates an empty file, cp copies, mv moves or renames: a rename is a move into the same directory under a new name. rm deletes a file, rmdir deletes only an empty directory, and rm -r deletes a directory with everything inside. ls -l gives a detailed listing: permissions, owner, size and date.

$ cd ~/projects/hello
$ touch README.md
$ echo 'console.log("hello")' > src/index.js
$ cat src/index.js
console.log("hello")
$ cp src/index.js src/index.backup.js
$ mv src/index.backup.js old.js
$ ls -l . src
.:
total 8
-rw-r--r-- 1 ubuntu ubuntu    0 Oct 11 22:02 README.md
-rw-r--r-- 1 ubuntu ubuntu   21 Oct 11 22:02 old.js
drwxr-xr-x 2 ubuntu ubuntu 4096 Oct 11 22:02 src

src:
total 4
-rw-r--r-- 1 ubuntu ubuntu 21 Oct 11 22:02 index.js
$ rm old.js
$ rmdir src
rmdir: failed to remove 'src': Directory not empty
$ rm -r src
$ ls
README.md

• Before deleting, run pwd and ls with the same path — make sure you see exactly what you are about to remove.
• For manual work use rm -i: the shell asks for confirmation for each file.
• Do not copy commands with rm -rf and sudo from the internet until you understand every part.
• Run risky experiments in a separate test directory or in a container.

When you type node index.js --port 3000, the first word is the program name and the rest are arguments: the program receives them as a list and decides what to do with them. Flags usually start with one dash (-l) or two (--port). If the name has no slash, the shell looks for the program in the directories listed in the PATH environment variable — in order, until it finds an executable file. That is how POSIX describes it; on Linux and macOS the directories in PATH are separated by colons, on Windows by semicolons.

$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$ command -v bash ls
/usr/bin/bash
/usr/bin/ls
$ type cd
cd is a shell builtin
$ node --version
bash: node: command not found
$ echo $?
127

command -v shows which file will run, and type identifies shell built-ins: cd is not a program but part of the shell itself. The exit status is stored in $?: 0 means success, any other number is an error. POSIX assigns 127 to “command not found” and 126 to “found but not executable”. A command not found message nearly always means one of two things: the program is not installed, or its directory is not in PATH (restarting the terminal after installation often helps).

Environment variables are name=value pairs a process inherits from its parent at startup. They pass settings to programs without changing code: the mode, the port, the database address. A plain shell variable is visible only to the shell itself; export makes it part of the environment of child processes. Writing APP_ENV=test command sets the variable for that one command only.

$ echo $HOME
/home/ubuntu
$ GREETING=hello
$ echo $GREETING
hello
$ bash -c 'echo "child: [$GREETING]"'
child: []
$ export GREETING
$ bash -c 'echo "child: [$GREETING]"'
child: [hello]
$ APP_ENV=test bash -c 'echo "APP_ENV=$APP_ENV"'
APP_ENV=test
$ echo "after: [$APP_ENV]"
after: []
$ unset GREETING

In PowerShell environment variables are available as $env:NAME. Microsoft's documentation notes that such a change affects only the current session and is inherited by child processes; for a permanent value you put the variable in your PowerShell profile or system settings. PowerShell has no APP_ENV=test command form — set the variable on a separate line.

PS> $env:APP_ENV = "test"
PS> pwsh -NoProfile -c '"child: [$env:APP_ENV]"'
child: [test]
PS> Remove-Item Env:APP_ENV
PS> "[$env:APP_ENV]"
[]
PS> $env:PATH -split ";" | Select-String nodejs
C:\Program Files\nodejs

Every program has three standard streams: input (stdin, number 0), output (stdout, 1) and errors (stderr, 2). By default output and errors go to the screen. The pipe | connects one command's output to the next command's input — as POSIX puts it, the standard output of command1 is connected to the standard input of command2. This is how small utilities combine into the tool you need: grep filters lines, wc -l counts them, sort sorts them.

$ printf 'GET /\nPOST /api/lead\nGET /about\nGET /api/health\n' > access.log
$ grep api access.log
POST /api/lead
GET /api/health
$ grep api access.log | wc -l
2
$ grep api access.log > api.txt
$ echo 'GET /api/price' >> api.txt
$ cat api.txt
POST /api/lead
GET /api/health
GET /api/price
$ ls missing.txt
ls: cannot access 'missing.txt': No such file or directory
$ echo $?
2
$ ls missing.txt 2> errors.txt
$ cat errors.txt
ls: cannot access 'missing.txt': No such file or directory
$ mkdir demo && cd demo && echo "created and entered"
created and entered
$ cd ~
$ ls missing.txt && echo "never printed" || echo "ls failed, exit code $?"
ls: cannot access 'missing.txt': No such file or directory
ls failed, exit code 2

>, >>, 2>, |, && and || also work in PowerShell 7 — the last two arrived in version 7. But PowerShell pipelines carry objects, so instead of grep and wc you use Select-String and Measure-Object. A classic beginner mistake is > instead of >>: one extra angle bracket silently wipes the file.

On Linux and macOS every file has permissions for three classes: the owner, the group and everyone else. Each class gets read (r), write (w) and execute (x). In ls -l output the first character is the type (d for a directory, - for a file), followed by three triplets of permissions. You can run a script as ./build.sh only if it has the x bit; otherwise the shell answers Permission denied.

$ printf '#!/usr/bin/env bash\necho "Build started in $(pwd)"\n' > build.sh
$ ls -l build.sh
-rw-r--r-- 1 ubuntu ubuntu 51 Oct 11 22:02 build.sh
$ ./build.sh
bash: ./build.sh: Permission denied
$ chmod +x build.sh
$ ls -l build.sh
-rwxr-xr-x 1 ubuntu ubuntu 51 Oct 11 22:02 build.sh
$ ./build.sh
Build started in /home/ubuntu
$ chmod 600 build.sh
$ ls -l build.sh
-rw------- 1 ubuntu ubuntu 51 Oct 11 22:02 build.sh

The digits are octal: r = 4, w = 2, x = 1, summed for each class. The first line of the script, #!/usr/bin/env bash (the shebang), tells the system which program should run it. Without the x bit you can still run a script explicitly: bash build.sh.

Let us put it all together: create a project directory, initialise npm, write a script that reads its arguments and an environment variable, and run it three ways. You need Node.js installed. In Node.js command-line arguments are available as process.argv and environment variables as process.env.

const name = process.env.USER_NAME ?? "world";
const args = process.argv.slice(2);
console.log(`Hello, ${name}!`);
console.log(`Arguments: ${args.join(" ") || "none"}`);

$ node --version
v24.18.0
$ npm --version
11.16.0
$ mkdir -p ~/projects/hello-cli && cd ~/projects/hello-cli
$ npm init -y > /dev/null
$ ls
package.json
$ node index.js
Hello, world!
Arguments: none
$ node index.js --port 3000
Hello, world!
Arguments: --port 3000
$ USER_NAME=Asel node index.js
Hello, Asel!
Arguments: none
$ npm pkg set scripts.start="node index.js"
$ npm start -- --verbose

> hello-cli@1.0.0 start
> node index.js --verbose

Hello, world!
Arguments: --verbose

The double dash in npm start -- --verbose is a boundary: npm does not parse anything after it and passes it to the script, as the npm run documentation describes. The same scenario in PowerShell 7:

PS> New-Item -ItemType Directory hello-cli -Force | Out-Null
PS> Set-Location hello-cli
PS> npm init -y > $null
PS> node index.js --port 3000
Hello, world!
Arguments: --port 3000
PS> $env:USER_NAME = "Asel"
PS> node index.js
Hello, Asel!
Arguments: none
PS> Remove-Item Env:USER_NAME
PS> npm pkg set scripts.start="node index.js"
PS> npm start -- --verbose
> hello-cli@1.0.0 start
> node index.js --verbose
Hello, world!
Arguments: --verbose

The next step is Git: it runs in the same terminal, and confident navigation between directories is needed from the very first command.