Overview
Mac and Unix Terminal Basics. This written companion follows the same sequence as the narrated video. It explains the workflow and validation steps; it does not supply a complete production application or claim a live deployment was performed.
Know which machine you are using
A terminal is the application that displays a shell, while the shell interprets commands. Opening Terminal on your Mac does not automatically connect to Ubuntu. Check the username, hostname, and working directory before changing files. After SSH connects, commands run on the server until you exit that session. Keep local and remote windows clearly labelled. This simple habit prevents uploading the wrong file or changing permissions on the wrong machine.
Practise in a disposable directory
Create a dedicated practice directory inside your own home folder. Confirm the path before creating files so the examples stay separate from important work. The print command writes a short line into a new text file. The single greater-than symbol replaces an existing destination, so use it only when replacement is intended. Practise with disposable files first. Learning what each operation changes is more useful than memorizing a long command without understanding its effects.
Navigate using paths
An absolute path identifies a location from the filesystem root, while a relative path starts at your current directory. The home directory is different from the root directory. Use print working directory whenever the location is unclear. Listing with hidden entries helps explain why configuration files beginning with a dot may not appear in a normal listing. Tab completion reduces typing mistakes, and quoting a path keeps spaces from being interpreted as separate arguments.
Read text without changing it
Use read-only tools before reaching for an editor. Cat displays a small file, while a pager is more comfortable for longer content. Head and tail show the beginning and end. Reading a configuration file does not require changing it, and many diagnostic tasks should start that way. Be selective when sharing output because logs and configuration can contain personal data or secrets. Capture only the relevant redacted lines when asking for help.
Copy and rename deliberately
Copy creates another file, while move can rename a file or move it elsewhere. Check the destination first because an existing file may be replaced. A trailing directory path and a new filename express different intentions, so read the command from source to destination before running it. Inspect the result afterward. For important data, keep a separate backup rather than assuming that a copied file on the same disk protects against disk failure.
Understand deletion and wildcards
Terminal deletion usually does not use the graphical Trash, so treat it as a real removal. Start by inspecting the exact disposable file, then use interactive removal while learning. A wildcard can match more files than expected, especially in a different working directory. Do not practise recursive deletion against broad system paths. When you need to remove a directory tree, first understand its contents and confirm that no required data is nested inside it.
Use pipes and redirection
A pipe connects one command's standard output to another command's standard input. It lets simple tools work together without creating a temporary file for every step. Appending with two greater-than symbols differs from replacing with one. Standard error is another stream, so not every diagnostic message follows the same pipe. Build pipelines one step at a time and inspect the intermediate output before trusting a filtered result to drive a change.
Search before editing
Search within a small known directory rather than scanning an entire machine by default. Grep finds matching text and can show line numbers, while find selects filesystem entries by properties such as name and type. Quote wildcard patterns intended for find so the shell does not expand them first. Review matches before editing. A search result is evidence of a matching string, not proof that the file is the active configuration used by a running service.
Inspect permissions and ownership
File permissions control access for the owner, group, and other users. Understand the ownership shown by a detailed listing before changing permissions. A private notes or key file may need owner-only access, while directories also need traversal permission to reach their contents. Making everything writable is not a reliable fix for an ownership problem. Apply the narrow change required by the workflow and verify that the intended user can perform the operation afterward.
Use administrative privileges intentionally
Sudo runs an authorized command with another identity, commonly the system administrator. It does not make an incorrect command correct. Read the operation and destination before adding elevated privileges. A password prompt may display no characters while you type; that is normal. Prefer ordinary user access for application work and elevate only for the specific system change. If permission is denied, investigate ownership and the intended policy instead of immediately making a broad recursive change.
Check processes and resource use
A process is a running program, and resource tools help distinguish a slow application from a full disk or busy machine. Start with read-only inspection and identify the relevant process before stopping anything. Disk capacity and the size of one directory answer different questions. Avoid killing an unfamiliar system process simply because it appears near the top of a list. Record what changed and verify the affected application after any deliberate restart.
Understand environment variables
Environment variables influence how a program starts and finds dependencies. The path variable contains directories searched for commands, so an unexpected executable can come from a different installation than you intended. Use command lookup to identify what will run. Do not print every environment value during a tutorial recording because it may expose credentials. Keep temporary project settings separate from permanent shell configuration and verify changes in a new terminal session.
Learn from the local manual
The manual installed on your machine describes the version you actually have. Use it to check options before copying a command written for another operating system. You can search within a manual page and leave the pager with the usual quit key. Error messages often identify an unsupported option or missing argument. Treat those messages as useful evidence and compare the local command with the documented example rather than repeatedly guessing a new flag.
Expect macOS and Linux differences
Many command names exist on both macOS and Ubuntu, but their options are not always interchangeable. macOS commonly includes BSD-derived utilities, while Ubuntu commonly supplies GNU versions. Package managers and service managers also differ. Confirm the operating system and read the local manual for scripts that modify files. Do not install random replacements just to make an unfamiliar command run before understanding why the example assumes a different platform.
Edit a small configuration safely
Learn an editor with a harmless practice file before using it on a remote system configuration. Keep a copy of the previous version and make one small change. Read the saved result, since leaving the editor does not necessarily mean the file was saved. Configuration formats have their own syntax and validation tools. For system services, validate the changed configuration before reloading so a typing error does not interrupt an otherwise working connection.
Understand exit status and cancellation
Commands report an exit status in addition to printed output. Zero generally indicates success, while a nonzero value indicates another outcome defined by that program. Capture the status immediately because the next command replaces it. Control C requests interruption of a foreground process, but a partially completed operation may still have changed data. Read the result and inspect the affected files instead of assuming interruption rolled everything back automatically.
Verify the server identity
SSH identifies the server with a host key and identifies you with a separate authentication method. On the first connection, compare the host fingerprint with a trusted provider console or another independent source. A key collected from the same untrusted network path is not independent verification. If the host key changes later, investigate whether the server was legitimately rebuilt. Do not automatically remove the warning simply to make the connection proceed.
Create a readable SSH alias
A host entry in the local SSH configuration keeps the connection details together. Give it a memorable alias and specify the correct username and private-key file. Use that alias with both SSH and file-transfer commands. Restrict access to the configuration file when it contains sensitive operational details, and avoid committing personal connection settings into a public repository. Test the alias before replacing commands in a deployment workflow that other people rely on.
Upload a file with SCP
Run the upload command on the machine that holds the source file. Read it from source to destination: a local file is copied to a path on the remote account. Begin with a small disposable file and inspect it on the server before uploading a large project. The destination may overwrite a file with the same name. Modern OpenSSH SCP uses SFTP for transfer, so avoid assuming that every legacy remote-shell wildcard example behaves identically.
Download and verify a file
To download, reverse the source and destination roles. Choose a clear local filename so you do not unintentionally replace an existing file. For a transfer that needs integrity verification, calculate a checksum for the corresponding source and destination and compare the values. A matching checksum confirms identical bytes, not that the contents are safe or came from the right publisher. Authentication and trusted source selection remain separate parts of the workflow.
Diagnose access failures by layer
Different errors point to different layers. A timeout often involves routing, filtering, or an unavailable destination. A refused connection usually means the address responded but the expected service did not accept it. Permission denied points toward authentication or account policy. Use verbose client output and relevant server logs together. Redact sensitive details before sharing diagnostics, and avoid changing firewall, key files, and server configuration simultaneously because that makes the cause harder to identify.
Test recovery before calling setup complete
A secure configuration is useful only if the intended workflow remains available and recoverable. Finish with a fresh key-authenticated login, a small round-trip file transfer, and an inspection of public listeners. Confirm the services you intended to expose and verify a backup restore in an isolated location. Record the commands and observed outcomes. Do not describe a server as impossible to compromise; the goal is a maintained, understandable system with explicit access boundaries and a workable recovery plan.
References and next steps
For help implementing or operating the project, see CodeKits development services.