Command line
glaze up
Apply a profile: create the session, the windows and the panes, then attach.
up is the command you run most and think about least, which is how it should be. It reads a profile, builds the session and puts you in it. The interesting bits are the edges: what happens when the session already exists, what the log shows and when up will not attach you to anything.
$ glaze up # apply ./.glaze and attach
$ glaze up --detached # create the session and do not attach
$ glaze up --clear # first kill an existing session with the same name
$ glaze up --profile-path ./gig.glaze
$ glaze up --var district=watson --var fixer=wakako
Flags
| Flag | Description |
|---|---|
--detached | Create the session and do not attach to it. |
--clear | First kill an existing session that has the same name. Glazier refuses when it runs inside that session, because the kill would also end Glazier. |
--keep-on-failure | Keep the partly built session when up fails, so that you can examine it. Run glaze up --clear to build it again. |
--debug | Print each command that Glazier sends to the tmux socket, and the text of each pane and session command. Env values show as <redacted>. |
--command-timeout | Stop the wait for the commands of a pane after this duration, for example 5m. The default value 0 waits with no limit. See Commands. |
--socket-path | The path to a custom tmux socket. See Custom sockets. |
--socket-name | The name of a custom tmux socket. |
--profile-path | The path to a .glaze file. See Profile resolution. |
--var key=value | Set a variable. The flag is repeatable. See Variables. |
--var-file <path> | An HCL file of variable values. |
An existing session
up creates the windows and the panes only for a new session. When a session with the same name already runs, up does not change it. Outside tmux, up attaches to it. Use --clear to kill the session first and build it again from the profile.
Glazier refuses --clear from a pane inside that session. Run it from another session or from outside tmux.
Why not rebuild by default? Because an up against a session you are sitting in would add a second copy of every window on each run, and a tool that does that is not a tool you keep. Leaving the live session alone is boring. Boring is the point.
Secrets in the log
A command or a hook can contain a secret from a variable. At the default log level, up shows only how many commands it runs in each pane. With --debug, it also shows the text of each command and hook, so check --debug output before you share it. Glazier never shows an env value: the log and the error messages show <redacted>. tmux gets each env value as a command argument, so another user on the same host can see it with ps for a moment.
A renamed window
A hook or an option in your tmux.conf can rename a window after Glazier creates it, for example set-hook -g after-new-window 'rename-window x'. up then shows a warning with the declared name and the new name. Glazier does not rename the window back, because your configuration can rename it again.
Attach rules
Outside tmux, up attaches your terminal to the session. In a pane of the same tmux server, up switches your client to the session. In a pane of a different tmux server, for example with --socket-name, up does not attach, because that would put one tmux client inside another. It shows the command that attaches to the session instead. Without a terminal, for example in a script, up does the same and warns: use --detached to skip the warning.
When the session ends during the build
A pane command can end the shell of the last pane, and tmux then closes the session before up is complete. up reports that the session ended, exits with code 1 and does not roll back, because there is nothing left to remove. For every other failure, up removes the session that this run created. See Clean-up after a failed up.