Welcome to the New World

The hook#

This adventure is self-paced: 66 sessions, in order. Three sessions a week gives you a suggested 22-week route; one a day gives you 66 days. Choose the days yourself. For a route that includes every side quest, roughly 100 days can be a planning target, with more time wherever the work needs it. The week labels are map coordinates, not a clock chasing you. Finish the quest's evidence before moving on, whether that takes one sitting or several.

Welcome to the New World. You are here because you chose to be here, and that already makes you different from most people.

In every isekai story the main character gets pulled into another world and has to work out the rules from nothing. No tutorial. No map. A strange place, a few starter items, and the choice to either stand there or start walking. Today you are that character. The terminal is the new world. The blinking cursor is the spot where you spawned. By the end of this session you will have your first skills unlocked, a working developer environment on your machine, and two folder trees you built by typing, not clicking.

You open your eyes. There is no sky, only a dark window with a short line of text and a small blinking rectangle. Nothing happens. The rectangle keeps blinking. It is, you slowly realise, waiting for you.

Here is the plan. First we set up a professional development environment on your computer: the same tools working developers open every morning, nothing watered down. Then we learn to talk to the machine. You type a line, the computer answers. That is genuinely all the terminal is: a conversation. You will learn the shape every command has, your first six commands, and how to make folders and files from the command line and open them in VS Code. Then you build. A camp, a base, a journal entry written one line at a time.

I do not care if you have never opened a terminal before. I do not care if you have decided this is not for you. That is old-world thinking. In this world the only stat that matters is whether you show up and do the work. Day one. Right now.

The practice boxes on this page are browser-based shell simulators. Press Run in terminal to replay the example, or type a supported command at the prompt. Commands such as mkdir, ls, and cat work against temporary files inside that box. They do not run a real Bash process or access your computer. The simulator supports a subset of shell behavior; it cannot install packages, launch VS Code, run arbitrary programs, or verify your installed tools. Its tool versions are example responses. Rerunning an example or reloading the page resets its virtual files. Use these boxes to rehearse, then repeat the exercises in your real terminal.

The idea#

What the terminal is. A text-based way to talk to your computer. Instead of clicking icons and dragging folders, you type commands and read answers. The graphical desktop is the passenger seat: comfortable, limited, built so you cannot reach the controls. The terminal is the cockpit.

Three words get used for this, and people lose a week worrying about the difference. The terminal is the window, the app you open: Terminal.app or iTerm2 on a Mac, Windows Terminal or Git Bash on Windows, GNOME Terminal or Konsole on Linux. The shell is the language spoken inside that window, the program that reads what you type and does it: Bash on most Linux machines and in Git Bash, Zsh on every Mac since 2019. The console is just another word people use for the same experience. For everything you will do in this programme, you interact with the window and the shell at the same time and never need to tell them apart. The terminal is the window; the shell is the interpreter inside it. Done.

Why developers live here. Four reasons, and the fourth is the real one.

Speed. Once you know the words, typing is faster than clicking. The classic day-one demo: make a folder, put ten files in it, open the whole thing in your editor. About five seconds. Now do it with the mouse: right-click, New Folder, type the name, double-click into it, right-click, New File, type the name, ten times, then find the editor and drag the folder onto it. Try it here.

mkdir speed-demotouch speed-demo/01.txt speed-demo/02.txt speed-demo/03.txt speed-demo/04.txt speed-demo/05.txt speed-demo/06.txt speed-demo/07.txt speed-demo/08.txt speed-demo/09.txt speed-demo/10.txtls speed-democode speed-demo

Power. Some things can only be done from the terminal. Connecting to a server, running a build, installing packages, most of Git: either terminal-only or so much faster there that nobody does it any other way.

Automation. Anything you can type, you can save in a file and run again. The boring work you did by hand on Monday is a script by Friday.

Servers. Every server in the world runs on the command line. There is no desktop on the machine that serves your bank's website, no icons, no mouse. When you deploy something to a server of your own in Unit 6, this is the only interface that will exist. Every developer job posting assumes you can do this, because every developer does.

The anatomy of a command. This is the single most useful idea on the page, so slow down for it. Every line you will ever type into a shell has the same shape:

command [options] [arguments]. The command is the first word: what to do. ls, mkdir, echo. Options, also called flags, say how to do it and start with a dash: -p, -la, --version. Arguments say what to do it to: a file name, a folder name, a piece of text. Square brackets mean optional. Spaces separate the pieces, which is the first thing that will bite you: a folder called my website is, to the shell, two arguments called my and website. Hold that thought; it comes back in Where it breaks.

Once you can name the three slots, an unfamiliar command stops being a spell and becomes a sentence. mkdir -p projects/isekai/unit-01 reads: make a directory, with parents, at this path. And when the options confuse you, the manual is one command away: man ls opens the page for ls, ls --help prints the short version, and explainshell.com will take any line you paste and label every piece.

Your first six commands. Not flashy. Essential. Like learning to walk before you can run.

• echo makes the terminal say something back. echo "Hello World" prints Hello World. It sounds useless until you learn, in about twenty minutes, that it is also how you write text into files.
• pwd is print working directory: "where am I right now?" You are always somewhere; the shell always has a current folder, and pwd names it. On a Mac that is /Users/yourname; on Linux and WSL it is /home/yourname.
• whoami answers "who am I logged in as?" with your username. Combined with echo and $(...), which runs a command and pastes its answer into the line, you get your first bit of real shell: echo "My name is $(whoami) and I am a developer now".
• date prints the date and time.
• clear wipes the screen. The text is gone from view, not from history. Ctrl+L does the same.
• history prints everything you have typed, numbered. Your own breadcrumb trail.

echo "Hello World"echo "My name is $(whoami) and I am a developer now"pwdwhoamidateecho $SHELLhistoryclearecho "Level 1 complete"

Press Run, watch, then type at the prompt yourself. Press the up arrow: your last command comes back, ready to run again or edit. echo $SHELL is a bonus: SHELL is a variable the system set for you, the dollar sign reads it, and the answer tells you which shell you are talking to. On this page it is Bash. On your Mac it will say /bin/zsh, and everything in this session works identically in both.

The things people believe on day one that are not true. "The terminal is only for hackers and Linux people": every professional developer on every operating system uses it daily; it is the standard tool, not the fringe one. "Terminal, shell and console are three things to learn separately": one experience, covered above. "The desktop can do everything the terminal can": connecting to servers, build scripts, Git, package management, are terminal-only or dramatically faster there. And the one that actually stops people: "if I type the wrong command I will break my computer." You will not. Most commands are safe. The genuinely dangerous ones, rm -rf and anything with sudo, require intent, and we will treat them with respect when they arrive. A typo produces an error message, not a disaster. You will see that happen on purpose further down.

The demonstration#

Two walkthroughs. The first sets up your machine. The second builds something with the commands you just met.

Walkthrough 1: setting up your dev environment. You need three tools: Git (version control, Session 1.3), Node.js (JavaScript outside the browser, Unit 4), and VS Code (the editor you will write everything in). The installs differ by operating system; the verification at the end is the same for everyone. These commands run on your computer, in your real terminal, so they are shown here as plain code, not as a page terminal.

macOS. Open Terminal (Applications › Utilities › Terminal, or press Cmd+Space and type "terminal"). Install Homebrew, the package manager that installs everything else, by pasting the one line from brew.sh; it looks like this and asks for your password once:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Then install Git and confirm your shell:

brew install gitecho $SHELL

For Node, go to nodejs.org/en/download, choose the LTS release (24 or newer), download the macOS installer and run it. Node is the one tool that moves fast enough that you want the official current build, not whatever a package manager happens to have cached.

Download VS Code from code.visualstudio.com, open it, press Cmd+Shift+P, type Shell Command: Install 'code' command in PATH, and run it. That one step is what lets you type code . in a terminal and have the editor open on that folder.

Windows. Open PowerShell as Administrator and run wsl --install, then restart. That gives you WSL2, a real Ubuntu Linux inside Windows, which is where the rest of this programme happens. Pick a username and password when Ubuntu first opens. Install Windows Terminal from the Microsoft Store if it is not already there. Then, inside the Ubuntu terminal, update the system and install Git:

sudo apt update && sudo apt upgrade -ysudo apt install git -y

Do not install Node with apt; Ubuntu's copy is years out of date and Unit 4 needs a current one. Install it the way nodejs.org/en/download shows for Linux, with nvm, the Node version manager. Two lines, then close and reopen the terminal before the third:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash

nvm install --ltsnode --version

The first line downloads and installs nvm; the second installs the current LTS release of Node (24 or newer) and makes it the default. Install VS Code from the same site, and in VS Code install the WSL extension so the editor opens your Linux files directly.

Linux. Open your terminal (Ctrl+Alt+T on most distributions) and run the same apt lines for Git and the same two nvm lines for Node. For VS Code, download the .deb from the website and sudo dpkg -i code_*.deb.

Everyone: verify. Three commands, one per tool. Each prints a version number if the tool is installed and command not found if it is not. Run them on your machine; here they are on the page's machine.

git --versionnode --versioncode --versionwhich git node codeecho $SHELL

Your numbers will differ from these and that is fine; what matters is that a number comes back at all, and that node --version starts with v24 or higher (if it says v12 or v18, Node came from apt; go back to the nvm lines). which is the fourth command here and it answers "where does this program live?": the shell found git in /usr/local/bin, which is how it knew what to run when you typed the word. If code --version says command not found on a Mac, you skipped the Shell Command step above.

Take a ten-minute break here if you are following along in real time. In isekai anime even the hero rests at the inn.

Walkthrough 2: files and folders from the command line. Five new commands and two symbols. Press Run and read each answer as it appears.

mkdir makes a directory, which is the old and correct name for a folder. mkdir -p makes a nested path in one go, creating every parent that is missing. touch creates an empty file, or several if you give it several names. ls lists what is in a folder: on its own, the current one; with an argument, that one. cat prints a file's contents to the screen. And echo with a > sends its text into a file instead of onto the screen.

mkdir -p my-website/css my-website/js my-website/imagestouch my-website/index.html my-website/css/style.css my-website/js/app.js my-website/README.mdls my-websitels my-website/csscat my-website/README.mdecho "# My Website" > my-website/README.mdecho "This is my first project." >> my-website/README.mdcat my-website/README.mdtree my-websitecode my-website

Read what happened. One mkdir -p built four folders, because my-website did not exist and -p made it on the way to css. One touch made four files in three different folders. The first cat printed nothing, because README.md was empty, and printing nothing is the correct answer, not a failure. Then the two arrows: > wrote the heading into the file, >> added a second line under it, and the second cat shows both. tree draws the result; it is not installed everywhere, so if your machine says command not found, ls -R (recursive) shows the same information as a list. Finally code my-website opens the folder in VS Code. On this page that is as far as it goes; on your machine the editor appears with the file explorer showing exactly the tree you just built. Put the terminal and VS Code side by side and look at them together once. The folders in the explorer are the folders you typed. There is no magic between them.

The camp. Here is the same set of commands used to build something bigger, which you will rebuild yourself in a moment. Read the picture first: the commands on the left produce the tree on the right, and each slash in a path is one branch.

cd ~mkdir -p isekai-camp/inventory/weapons isekai-camp/inventory/armor isekai-camp/inventory/potionsmkdir -p isekai-camp/quests/main-story isekai-camp/quests/side-questsmkdir isekai-camp/journalls isekai-camptouch isekai-camp/inventory/weapons/wooden-sword.txt isekai-camp/inventory/armor/cloth-shirt.txt isekai-camp/inventory/potions/health-potion.txttouch isekai-camp/quests/main-story/learn-the-terminal.txt isekai-camp/journal/day-01.txtecho "Day 1: I woke up in a terminal." > isekai-camp/journal/day-01.txtecho "I learned echo, pwd, whoami, mkdir, and touch." >> isekai-camp/journal/day-01.txtecho "I am starting to think I might actually be able to do this." >> isekai-camp/journal/day-01.txtcat isekai-camp/journal/day-01.txtls -R isekai-campcode isekai-camp

Three things to notice. cd ~ first: cd changes directory (the whole of next session is about moving around), and ~ is shorthand for your home folder, so the line means "go home before you build", which is a habit worth keeping. The journal is written with one > and two >>: the first line creates the file, the next two add to it. And ls -R at the end walks the whole tree and prints every folder with its contents, which is how you check your work without opening anything. Eight directories, five files, and one journal entry that is already true.

Where it breaks#

Your turn#

The quest#

By the start of Session 1.2, have on your machine:

• A verified environment: git --version, node --version and code --version all print a number in your real terminal.
• isekai-camp built to the tree, with a three-line day-01.txt you have read with cat.
• dev-environment-practice built to the requirements, with session-01.txt, commands-learned.txt and the HTML skeleton written entirely with echo, and screenshots/tree.txt holding the ls -R output.
• One honest sentence added to the bottom of day-01.txt, with >>, about how the first day felt.

Next session starts from the same home directory and builds new folders beside these two, so leave isekai-camp and dev-environment-practice exactly where they are.

Side quests#

Two pages in the library frame the adventure you are beginning. Read them in this order; they are short, and they are about you rather than the shell.

Before next session#

Finish the independent lab if you did not finish it here; the folder must be on your machine, fully built, before Session 1.2. Budget one to two hours.

Then open a terminal once a day for no reason. pwd, ls, cd into something, ls again, cat a file you made. Five minutes. The point is not to learn anything new; it is to stop noticing the window. After a week it is just a place you go.

Next time: Your Status Screen. We learn to move around the whole filesystem: absolute and relative paths, cd in every direction, the flags that make ls tell the truth, pipes that chain commands together, and permissions, which is why a file sometimes refuses you. Your status screen is about to get a lot more detailed. Nothing to read ahead. Start the next session with the base camp built.

You just completed your first day in the new world. You have a working environment. You can talk to the machine. You can create things with it. That is not nothing. That is everything.