Open files, URLs, and applications

The open command connects shell work to Mac applications. It can open a file with its default app, open a URL, or choose an application. Behind it sits Launch Services, the same system that decides what happens when you double-click something in Finder.

Examples:

open report.pdf
open https://localhost:4321/
open -a "Visual Studio Code" project

The first line opens the PDF in whatever app owns PDFs, Preview on most Macs. The second opens your dev server in the default browser. The third overrides the default: -a opens the item with a specific application, here a project folder handed to an editor.

Two more variants earn their place in automations:

open .
open -R ~/Projects/acme/media/acme-2026-08-03.png

open . shows the current directory in Finder, the fastest bridge from a terminal session to the GUI. open -R reveals the file in a Finder window and selects it, which is the polite way for an automation to finish: the user sees exactly what was produced, already selected.

Verification is direct: the right app comes to the front with the right content. For scripting, check the exit status too:

open missing.pdf
# The file /Users/flavio/missing.pdf does not exist.
echo $?
# 1

A non-zero exit lets your script stop instead of carrying on without the document it was supposed to show.

Opening is a user-visible side effect. Validate every path and URL first, especially when input comes from another program or downloaded data. open launches whatever it is given: a URL pointing somewhere hostile, a file whose extension hides what it really is. In an automation, an unexpected open is your machine acting without you. Allow only the schemes you expect, like https: and paths inside your project, and refuse everything else before the command runs.