﻿# Unix basics: logging in, files and permissions

> Logging in to the course server over SSH, finding your way in the file system with absolute and relative paths, and creating, editing (in vim), copying and deleting files. Ends with permission bits – rwx for user, group and others, in letters and in octal.

Source: https://laszlonemes.com/university/computer-systems/unix-basics · Author: László Nemes

Session 1 · Computer Systems

Logging in to the course server over SSH, finding your way in the file system with absolute and relative paths, and creating, editing (in vim), copying and deleting files. Ends with permission bits – rwx for user, group and others, in letters and in octal.

15 min read `Unix, POSIX, Linux and the shell` `SSH to the course server` `Absolute and relative paths` `ls -l, vim and file commands` `Permissions: chmod and octal` `SMTP, IMAP and POP3`

This session is about getting comfortable in a terminal on a Linux server: logging in, finding your way around the file system, creating and editing files, and reading the permission bits that decide who may do what. None of it is hard, but all of it is used in every later session – a shell script is just these commands written into a file.

The words first, because they get mixed up a lot: Unix, POSIX, Linux, shell. Then we log in and work through the commands with small examples. Type them along – the terminal is learnt with the fingers.

After this session you can

- explain what Unix, POSIX, Linux and a shell are, and how they relate
- log in to the course server over SSH and tell where your commands run
- move around the file system with absolute and relative paths
- create, edit (in vim), copy, move, read and delete files and directories
- read the output of ls -l and set permissions with chmod, in letters or in octal

> **The model in one breath:** the kernel runs the machine, the shell turns what you type into programs the kernel runs, and everything you work with is a file somewhere in one tree that starts at `/`.

## Unix, POSIX, Linux, shell

A short glossary, so we all mean the same thing by the same words. You will meet every one of them in the theory tests as well.

- **Unix** – An operating system developed at Bell Labs from 1969. Files, processes, pipes and permissions – most of the ideas in this course – come from Unix.
- **POSIX** – Portable Operating System Interface: a family of IEEE/ISO standards describing what a Unix-like system must provide – the shell language, the basic utilities, the system APIs. A script written against POSIX runs on any compliant system.
- **Linux** – A free, open-source kernel built along Unix principles and largely POSIX-compliant. Strictly speaking “Linux” is only the kernel.
- **GNU tools** – The free utilities from the GNU Project (ls, cp, grep, bash …) that, together with the kernel, make a usable system.
- **Distribution** – Kernel + GNU tools + a package manager + programs, packaged together: Ubuntu, Debian, Fedora, Arch. Linux, macOS and the BSDs (Berkeley Software Distribution, another Unix family) all follow POSIX closely, so commands carry over.
- **Shell** – A command-line interface to the operating system: you type a command, the shell interprets and runs it. sh was the original Unix shell; bash and zsh extend it. We use bash, the most common one on Linux.
- **Shell script** – A text file of the commands you would otherwise type. Shells grew variables, conditions, loops and functions, so scripts are real programs – but at their core they still just run commands.
- **PowerShell** – Microsoft’s cross-platform automation tool: a shell, a scripting language and a configuration framework in one. Unlike Unix shells, which pass text between commands, it passes structured objects. It is the second half of this course.

Fig. 1 puts the pieces in place. The **kernel** shares the machine’s resources between the running programs, schedules them and gives them a uniform interface to the hardware. The **shell** – the word means the outer layer around the kernel – is the program between you and the kernel. When you type `ls`, the shell asks the kernel to start the `ls` program and shows you what it prints.

> **Fig. 1** · You never talk to the kernel directly. The shell is a program like any other – which is why there can be several of them.
>
> *Diagram:* A Linux system in layers. The hardware is at the bottom; the kernel shares it out between processes; the shell reads what you type and starts programs; programs like ls, cp and vim run as processes on top. You only ever talk to the shell.

## Logging in to the server

The practice sessions run on a Linux server, `szamrend.inf.elte.hu`. You log in with your Neptun code in lowercase as the user name and your faculty (IIG) password. From a terminal – Windows Terminal, PowerShell, the macOS or Linux terminal – the `ssh` command does it; on Windows the PuTTY program is the graphical alternative.

```shell
ssh <neptun-code>@szamrend.inf.elte.hu
# the first time: answer "yes" to accept the server's fingerprint
# the password is not echoed while you type – that is normal
exit            # log out (Ctrl+D does the same)
```

It helps to know what happens here (Fig. 2), because it explains half of the confusion in the first weeks. Your laptop doesn’t run anything: it sends keystrokes over an encrypted connection and prints the text that comes back. A file you create “in the terminal” is created on the server, in your home directory there, and you won’t find it in your laptop’s Downloads folder.

> **Fig. 2** · SSH (Secure Shell) is a remote terminal: your machine is the screen and the keyboard, the server does the work.
>
> *Diagram:* Logging in over SSH. The terminal on your computer only sends your keystrokes, encrypted, to the server and shows the text that comes back. On the server, sshd checks your name and password and starts a bash shell for you; every command runs there, and the files it creates stay on the server.

Good to know

**If you cannot create files**

The server gives every user a disk quota. If `vim` cannot save or `mkdir` fails with “Disk quota exceeded”, read the [disk quota guide](https://laszlonemes.com/university/computer-systems/disk-quota) – it is usually a cache folder you didn’t know about.

### Who and where am I?

Three commands answer the first questions after logging in. `pwd` (print working directory) is the one to type whenever you are unsure where a command will act.

```shell
whoami          # your user name
who             # who is logged in right now, and since when
pwd             # print working directory: where you are
```

```text
$ whoami
student
$ pwd
/home/student
```

### Passwords

`passwd` changes the password of a local Unix account. Many university servers don’t keep passwords locally: they check logins against a central **Kerberos** server. Kerberos is a network authentication protocol that lets machines prove their identity to each other over an untrusted network; an identity in it is a *principal*, written like `primary/instance@REALM`. `kpasswd` changes a principal’s password – including principals that are not local Unix users at all.

```shell
passwd          # change the password of a local Unix account
kpasswd         # change the password of a Kerberos principal
```

## The file system and paths

Windows has drives (`C:`, `D:`); Unix has one tree. It starts at the **root**, written `/`, and every disk, device and even every running process appears somewhere below it (Fig. 3).

> **Fig. 3** · One tree, one root. Your home directory is a branch under /home; the system lives in the other branches.
>
> *Diagram:* The Linux file system is one tree that starts at the root, /. System directories such as /etc, /dev, /usr and /tmp sit next to /home, which holds every user's home directory. Every file has exactly one absolute path from the root, for example /home/student/notes.txt.

| Directory | What lives there |
| --- | --- |
| `/` | the root: the starting point of the whole tree |
| `/home` | the users’ home directories – yours is /home/<your-name> |
| `/etc` | system-wide configuration files |
| `/dev` | files that represent hardware devices (disks, terminals) |
| `/usr/bin` | the commands every user runs: ls, cp, grep … |
| `/usr/share/doc` | documentation; manual pages live under /usr/share/man |
| `/sbin` | commands for the administrator (superuser) and for booting |
| `/lib` | shared libraries the programs use |
| `/tmp` | temporary files, cleaned up regularly |
| `/var` | data that changes while the system runs: logs, mail and print queues, caches |
| `/proc` | a virtual file system: one directory per running process, plus kernel settings |
| `/opt` | optional, add-on application packages |

### Absolute and relative paths

Every file can be named two ways (Fig. 4). An **absolute path** starts with `/` and is read from the root – it means the same file wherever you are. A **relative path** doesn’t start with `/` and is read from the current directory. Three short names help: `.` is the current directory, `..` its parent, and `~` your home directory.

> **Fig. 4** · Same file, two names. The relative one is shorter, but it only works from the directory you are in.
>
> *Diagram:* Two ways to name the same file. You are in /home/student/scripts. The absolute path /home/student/notes.txt starts at the root and works from anywhere; the relative path ../notes.txt starts in the current directory, goes one level up with .., then down to notes.txt.

```shell
cd /etc         # absolute: from the root
cd ..           # one level up, to /
cd              # no argument: back to your home directory
cd ~/lab1       # ~ is your home, so this is /home/student/lab1
cd -            # back to the directory you were in before
```

Common mistake

**Names with spaces**

The shell splits a command line at spaces, so `cd my lab` tries to enter `my` with an extra argument `lab`. Quote the name – `cd "my lab"` – or better, don’t put spaces in file names on a Unix system at all. Use `my_lab` or `my-lab`.

In your assignment

**Don’t hard-code your home directory**

Your assignment script will be run by someone else, from a directory you don’t know. A path like `/home/abc123/lab/data.txt` works on your account and nowhere else. Take file and directory names as arguments, and when you use a relative path, decide consciously what it is relative to.

## Listing files

`ls` lists a directory. Options start with a dash and can be combined: `ls -al` is `ls -a -l`. Every command has a manual page – `man ls`, quit with `q` – and it is the fastest answer to “what was that option?”.

```shell
ls              # the names in the current directory
ls -l           # long format: one entry per line, with details
ls -a           # also the hidden entries (names starting with a dot)
ls -al /tmp     # options combine; a path lists another directory
```

The long format packs a lot into one line (Fig. 5). The first column is the one that matters most in this course: the file type and the permission bits, which we take apart below.

> **Fig. 5** · The columns of ls -l. A file whose name starts with a dot is “hidden” only in the sense that ls leaves it out without -a.
>
> *Diagram:* One line of ls -l, column by column: the file type, the permission bits, the number of hard links, the owner, the group, the size in bytes, the time of the last modification and the name.

## Editing a file with vim

On a server there is no Notepad, so you edit files in the terminal. **vim** is a free, screen-based text editor that is on practically every Unix system. Its one surprising idea is **modes** (Fig. 6): when it opens, the keys are commands, not text. Press `i` before typing, and `Esc` when you are done.

> **Fig. 6** · The only part of vim you need on day one: i to type, Esc to stop typing, :wq to save and leave.
>
> *Diagram:* vim has modes. It starts in Normal mode, where keys are commands. i switches to Insert mode, where keys type text; Esc goes back. A colon opens the command line: :wq saves and quits, :q! quits without saving.

```text
vim notes.txt   opens notes.txt (creates it on save) in Normal mode
i               Insert mode – from now on keys type text
Esc             back to Normal mode
:wq             write (save) and quit
:q!             quit and throw the changes away
```

In `:wq`, `w` stands for *write* (save) and `q` for *quit*. If the letters you type end up in strange places, you are in Normal mode: press `Esc` twice and start again with `i`.

Good to know

**Alternatives**

If you find vim too strange, `nano` is a simpler terminal editor that shows its shortcuts at the bottom of the screen, and the two-panel file manager `mc` has a built-in editor too. Learn the vim basics anyway: it is the editor you can count on finding on any server.

## Copy, move, delete, read

These are the everyday commands. Most of them take a source and a target, in that order – like a sentence: “copy *this* to *that*”.

```shell
mkdir lab1                  # create a directory
mkdir -p lab1/data/raw      # create the missing parents too
cp a.txt b.txt              # copy a.txt to a new file b.txt
cp -r lab1 lab1_copy        # copy a directory with everything in it
mv b.txt lab1/              # move b.txt into lab1
mv a.txt notes.txt          # rename: mv moves a file to a new name
rmdir lab1/data/raw         # remove an EMPTY directory
rm notes.txt                # delete a file – there is no recycle bin
rm -r lab1_copy             # delete a directory and everything in it
```

`mv` both moves and renames, because in Unix those are the same operation: the file gets a new path. If the target is an existing directory, the file goes into it; otherwise the target is the new name.

Common mistake

**rm is final**

There is no recycle bin in the shell. `rm *` deletes every file in the *current* directory, and `rm -r` deletes a whole tree without asking. Before a destructive command, run `pwd` and `ls` with the same pattern first, and add `-i` (`rm -i`) if you want a confirmation for each file.

### Reading files

```shell
cat notes.txt               # print the whole file
more notes.txt              # page by page: Space = next page, q = quit
less notes.txt              # like more, but you can scroll back too
head -n 5 notes.txt         # the first 5 lines
tail -n 2 notes.txt         # the last 2 lines (without -n: the last 10)
```

## Saving and paging output

Everything a command prints can be sent somewhere other than the screen. `>` writes it into a file (replacing what was there), and `|` – the **pipe** – feeds it straight into another command. The example below does the same job both ways: once with a file in between, once without.

```shell
ls -l ~/lab1 > ~/listing.txt    # save the output in a file (overwrites it)
more ~/listing.txt              # read it page by page
ls -l ~/lab1 | more             # same result, no file in between
```

Pipes are the heart of the Unix way of working: small programs, each doing one thing, connected into a chain. We build real pipelines in [Session 2](https://laszlonemes.com/university/computer-systems/processes-filters), and the full set of redirections (`>>`, `2>`, `2>&1`) comes in [Session 3](https://laszlonemes.com/university/computer-systems/shell-scripts).

## Archives and installing tools

To hand in or move a whole directory, pack it into one file. `zip -r` takes the name of the archive first, then what to pack; `-r` (recursive) includes everything below the directory.

```shell
zip -r lab1.zip lab1        # pack the lab1 directory, recursively
unzip -l lab1.zip           # list what is inside
unzip lab1.zip -d restored  # unpack into the directory "restored"
```

If a tool is missing, a **package manager** installs it – `apt` on Ubuntu and Debian. Installing software changes the system for every user, so it needs administrator rights, which you get for one command with `sudo` (*superuser do*): it runs a program with another user’s – by default the administrator’s – privileges.

```shell
sudo apt install zip        # on your own Ubuntu or Debian machine, or in WSL
```

Good to know

**Not on the course server**

On a shared server you are an ordinary user without administrator rights, so don't expect `sudo` to work there – that is the point of it. Use it on your own Linux machine, a virtual machine or WSL (Windows Subsystem for Linux).

## Permissions

Unix is a multi-user system, so every file records an **owner**, a **group**, and what three kinds of people may do with it: the owner (`u`, user), members of the group (`g`), and everyone else (`o`, others). For each of them there are three bits: `r` read, `w` write, `x` execute. That gives the nine letters after the file type in `ls -l` (Fig. 7).

> **Fig. 7** · Each triad is a three-bit number, so a whole permission set fits into three octal digits. 7 = rwx, 6 = rw-, 5 = r-x, 4 = r--, 0 = ---.
>
> *Diagram:* The permission string rwxr-xr-- is three groups of three bits: for the owner, for the group and for everyone else. Each letter has a value – r is 4, w is 2, x is 1 – and each group adds up to one octal digit, so rwxr-xr-- is 754.

`chmod` changes the bits, in either notation. The letter form changes only what you name (`u+x`: add execute for the owner); the octal form sets all nine bits at once. `chown` changes the owner – on a shared server only the administrator can give a file away.

```shell
chmod +x hello.sh           # add execute (for user, group and others)
chmod u+x hello.sh          # add execute for the owner (user) only
chmod go-w report.txt       # take write away from group and others
chmod 644 report.txt        # rw-r--r--  you edit, everyone else reads
chmod 600 secret.txt        # rw-------  only you
chmod 755 hello.sh          # rwxr-xr-x  typical for scripts and directories
chown alice report.txt      # change the owner – needs administrator rights
```

| Octal | Letters | Typical use |
| --- | --- | --- |
| `644` | `rw-r--r--` | ordinary files: you edit, others read |
| `600` | `rw-------` | private files: only you |
| `755` | `rwxr-xr-x` | scripts and directories: everyone may run or enter, only you change |
| `700` | `rwx------` | a private directory or script |

Common mistake

**Execute on a directory**

For a directory, `x` doesn’t mean “run”: it means you may enter it (`cd`) and reach the files inside. A directory with `r` but no `x` lets you see the names but not open anything – a confusing state that usually comes from `chmod 644` on a directory. Directories want `755` or `700`.

In your assignment

**Your script must be executable**

A script is just a text file until it has the `x` bit. Before you submit, run `ls -l` on it and check for `rwx` in the owner triad; if you wrote it on Windows and copied it over, also read [Session 5 on line endings](https://laszlonemes.com/university/computer-systems/files-line-endings) – the invisible `\r` breaks scripts in confusing ways.

## Side note: how e-mail travels

A bit of networking that comes up in the theory part: the protocols behind e-mail. There are two jobs, done by different protocols. **Sending** is SMTP; **fetching** is IMAP or POP3 (Fig. 8).

> **Fig. 8** · SMTP pushes, IMAP and POP3 pull. Your mail app usually speaks both: SMTP to send, IMAP to read.
>
> *Diagram:* How an e-mail travels. SMTP pushes the message from the sender's mail app to an outgoing server and from there to the recipient's server. The recipient fetches it with IMAP, which keeps the mail on the server and in sync on every device, or with POP3, which downloads it to one device.

- **SMTP** (Simple Mail Transfer Protocol) runs over TCP and moves mail from a client to a server and between servers. A session has three steps: the client connects, the message is transferred, the connection is closed. The client sends text commands (`EHLO`, `MAIL FROM`, `RCPT TO`, `DATA`); the server answers with numeric codes (`220` ready, `250` OK, `354` start the message). Servers that pass mail on are *relays*; the last one is the *receiver*.
- **IMAP** (Internet Message Access Protocol) reads mail that stays on the server. Because the server keeps the mailbox, the phone and the laptop see the same folders and the same read/unread state, and a message’s body is downloaded only when you open it.
- **POP3** (Post Office Protocol, version 3) downloads the mail to one client, usually deleting it from the server. It needs the network only for the download – you can read offline – but the mail then lives on that one device.

Because SMTP is plain text, a whole exchange is readable. The client’s lines are marked C, the server’s S:

```text
S: 220 mail.example.org ESMTP ready
C: EHLO laptop.example.org
S: 250 mail.example.org
C: MAIL FROM:<anna@example.org>
S: 250 OK
C: RCPT TO:<ben@example.net>
S: 250 OK
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: Subject: Lab notes
C: (the message, then a line with a single dot)
C: .
S: 250 OK: queued
C: QUIT
S: 221 Bye
```

## Practice

Do these on the server, in order – each builds on the previous one. The hints show the commands that matter; try first, open the hint second.

Task 1

**Find your bearings**

Log in. Print your user name and the directory you are in, list who else is logged in, then list your home directory including the hidden files. Which hidden files are there, and what do you think they are for?

**Commands:**

```shell
whoami
pwd
who
ls -al ~
```

You will see at least `.` and `..`, and usually `.bashrc` (commands bash runs when it starts) and `.bash_history` (the commands you typed before).

Task 2

**Build a small tree**

Create `~/cs/lab1/data` and `~/cs/lab1/scripts` – with as few commands as you can. Go into `scripts`, then get to `data` with a *relative* path, and check where you ended up.

**Approach:**

`mkdir -p` creates the missing parents, and it accepts several paths at once. From `scripts`, `data` is “up one, then down”.

```shell
mkdir -p ~/cs/lab1/data ~/cs/lab1/scripts
cd ~/cs/lab1/scripts
cd ../data          # relative: up to lab1, then down to data
pwd                 # check: /home/<you>/cs/lab1/data
```

**Shorter:**

```shell
mkdir -p ~/cs/lab1/{data,scripts}   # the shell expands {a,b} to two paths
```

Task 3

**Write a file in vim**

In `data`, create `fruits.txt` with vim: five lines, one fruit per line. Save and quit. Then print only the last two lines, and only the first three.

**Approach:**

`vim fruits.txt`, `i`, type, `Esc`, `:wq`. Then:

```shell
tail -n 2 fruits.txt
head -n 3 fruits.txt
```

Task 4

**Copy, rename, move, delete**

Copy `fruits.txt` to `backup.txt`, rename the copy to `fruits_old.txt`, move it into `scripts`, check that it arrived, then delete it.

**Commands (run in data):**

```shell
cp fruits.txt backup.txt
mv backup.txt fruits_old.txt
mv fruits_old.txt ../scripts/
rm ../scripts/fruits_old.txt
```

Task 5

**Save a listing, then skip the file**

Save the long listing of `/etc` into `~/cs/etc_list.txt` and read it page by page. Then get the same paged view without creating a file.

**Commands:**

```shell
ls -l /etc > ~/cs/etc_list.txt
more ~/cs/etc_list.txt
ls -l /etc | more
```

Task 6

**Permissions**

(a) In `scripts`, create `hello.sh` containing the single line `echo "Hello from the server"`. Try to run it with `./hello.sh`, read the error, fix it, run it again. (b) Make `fruits.txt` readable and writable by you only, and check with `ls -l`. (c) Without the computer: what is `rw-r-----` in octal, and what is `751` in letters?

**(a) the run:**

```text
$ ./hello.sh
bash: ./hello.sh: Permission denied
$ chmod u+x hello.sh
$ ./hello.sh
Hello from the server
```

**(b) and (c):**

(b) `chmod 600 fruits.txt` → `-rw-------`. (c) `rw-` = 4+2 = 6, `r--` = 4, `---` = 0, so `640`. `751` is `rwx` `r-x` `--x`.

Task 7

**Pack it up**

Pack the whole `lab1` directory into `lab1.zip`, and list the archive’s content without unpacking it.

**Commands:**

```shell
cd ~/cs
zip -r lab1.zip lab1
unzip -l lab1.zip
```

Task 8

**Look around the system**

Find out where the `ls` program is stored, which Linux distribution the server runs, and what the numbered entries in `/proc` are.

**Commands:**

```shell
which ls             # where the ls program lives
cat /etc/os-release  # which distribution the server runs
ls /proc | head      # numbered directories = running processes
```

Each number in `/proc` is the ID of a running process – the topic of [the next session](https://laszlonemes.com/university/computer-systems/processes-filters).

In your assignment

**On the practical test**

The practical test is solved in this same terminal. Moving around with `cd`, checking with `pwd` and `ls`, and getting in and out of vim should cost you no thought by then – practise them now, while the tasks are easy.

## Summary

- Unix is the original system, POSIX the standard, Linux a kernel, a distribution the whole package; the shell (bash) is the program you type into.
- `ssh <neptun-code>@szamrend.inf.elte.hu` gives you a shell on the server – commands and files are there, not on your laptop.
- One tree from `/`. Absolute paths start at `/`; relative paths start where you are; `.`, `..` and `~` are shortcuts.
- `ls -l` shows type, permissions, owner, group, size, time and name; `ls -a` adds hidden files.
- vim: `i` to type, `Esc` to stop, `:wq` to save and quit, `:q!` to give up.
- `cp`, `mv`, `rm`, `mkdir -p`, `cat`, `head`, `tail`, `more` – and `rm` has no undo.
- Permissions are rwx for user, group and others; r = 4, w = 2, x = 1, so `chmod 755` is `rwxr-xr-x`.
