Command-line launching

Launch a command from a script or another terminal, and keep its shell and output in Terminalis. Command-line launching is available on macOS in Terminalis 3.5.0 and later.

Install the command #

Create a symlink to the executable inside your installed app:

mkdir -p "$HOME/.local/bin"
ln -s /Applications/Terminalis.app/Contents/MacOS/Terminalis "$HOME/.local/bin/terminalis"
export PATH="$HOME/.local/bin:$PATH"

Adjust the app path if you installed Terminalis somewhere else. Add the PATH line to your Bash or Zsh startup configuration so new shells can find the command. For Fish, use:

fish_add_path ~/.local/bin

The symlink continues to point to the app after an update. Check the installed version and options without opening a window:

terminalis --version
terminalis --help

Launch a terminal #

terminalis --command 'npm run dev'
terminalis -c 'npm run dev' -d . -t work -n 'Web server'

Terminalis reuses the running app or starts it when needed. Each invocation creates a persistent terminal, brings the app forward, opens the requested tag page, and selects the new tab. The command runs once in the normal interactive shell. Its terminal and shell stay open afterward for output and further interaction. An open dialog keeps its draft; terminal focus waits until the dialog closes.

Without --cwd, the command runs in your home directory. Use --cwd . to run in the caller's current directory. Relative paths resolve from the caller's directory, ~ is supported, and the directory must already exist. The command returns to that directory even if shell startup files change directories while initializing.

Without --tag, the terminal is always Untagged, regardless of the page currently selected in the app. A supplied tag is one local tag: an exact existing tag is reused, or a new tag is created. Without --name, Terminalis generates its usual adjective–noun name. Repeating a name creates another terminal; it does not reuse an existing terminal.

The new profile stores no attached command or environment overrides and has Start on app launch disabled. Restarting Terminalis does not rerun the CLI command. The command remains in normal history.

Options #

Terminal-creation options require --command. Running terminalis without arguments opens or activates the app normally. Blank commands, unknown options, invalid directories, and malformed environment assignments are rejected before a terminal is created.

Quoting and shell syntax #

Quote command text so your caller's shell passes it to Terminalis without expanding it first:

terminalis -c 'printf "%s\n" "$HOME"'
terminalis -c 'printf "first\n" | sort > output.txt' -d .
terminalis -c 'pwd
printf "finished\n"' -d .

Pipes, redirects, variable expansion inside the command, and multiline syntax follow the shell running inside Terminalis. Use commands that shell understands; a Bash-specific script may need to invoke Bash explicitly when your normal shell is Fish.

Command environment #

Pass each additional variable explicitly. This works the same way whether Terminalis is already running or launches for the request:

terminalis -c 'npm run dev' --env NODE_ENV=development --env PORT=3001
terminalis -c 'printf "%s\n" "$MESSAGE"' -e 'MESSAGE=literal $HOME and $(date)' -e EMPTY=
terminalis -c 'printf "%s\n" "$PORT"' -e PORT=3000 -e PORT=3001

Each assignment splits at its first =. Empty values and further = characters are allowed; the last assignment wins when you repeat a name. Names must be valid shell-variable names, and the TERMINALIS_* namespace is reserved. --env KEY does not look up a value in the caller.

Values are literal after the caller's shell has expanded the arguments. In the second example, $HOME and $(date) remain text in MESSAGE; Terminalis does not evaluate them again. Single quotes also preserve spaces and double quotes. To deliberately copy a caller variable, expand it in the caller, for example --env "MESSAGE=$MESSAGE".

Explicit values override the normal shell environment for this command only. They are not saved in the profile or applied to later commands or other terminals. Bash, Zsh, and Fish support these overrides; other shells reject requests containing them. This literal-value behavior differs from saved environment references. Native shell history can retain the invocation, including explicit values.

Arbitrary caller exports are not automatically forwarded. A cold launch uses a deliberate app environment: the OS account's home, login name and shell, a system PATH, a UTF-8 locale, a temporary directory, and the resolved configuration selection. Normal login-shell startup files still establish the terminal environment. A warm request uses the running app's normal shell setup and adds only the explicit overrides for its command.

Submission and exit status #

Exit 0 acknowledges delivery to the terminal. It does not wait for command completion, promise successful shell parsing, or report the command's eventual exit status. A long-running server can keep running after the CLI returns; inspect its status and output in Terminalis.

If the error reports uncertain delivery, the command may still run. Inspect its terminal before deciding what to do; never automatically retry execution after that outcome. Terminalis does not automatically replay an uncertain request. A new CLI invocation is a new request and can run the command again. Duplicate-delivery protection lasts only for the running app's lifetime.

If profile creation succeeded before submission failed, the terminal remains available while the app is running. Intentional quitting can interrupt queued or preparing requests without an extra quit guard; a lost response can therefore produce an uncertain-delivery error.

Development builds #

From a source checkout, start the development app and invoke its exact debug executable with the same separate configuration directory:

npm run tauri:dev

In another terminal, from the same repository:

TERMINALIS_CONFIG_DIR=~/terminalis-demo ./src-tauri/target/debug/Terminalis \
  --command 'pwd' --cwd . --tag cli-check

Requests route by user, resolved configuration directory, and development or release build channel. Keep development and installed-app configuration directories separate: automatic protection against both channels writing the same configuration is postponed. See Local configuration and data for the configuration override and storage locations.