# Unity CLI v1.0.0-beta.5 ### Fixed - Declining a module's license terms, or being told to pass `--accept-eula` in a non-interactive shell, no longer suggests you "Run `unity bug` to report this issue". Neither is a fault in the CLI: one is your decision and the other tells you the flag to add. The message, the exit code (6), and the `--format json` envelope are unchanged. - Routine situations no longer read like CLI bugs. `unity modules ` on an editor you haven't installed, and `unity install-path --set` / `unity editors install-path --set` with a path that's absolute-but-missing, invalid, or inside the Hub's own directory, all stopped suggesting you "Run `unity bug` to report this issue". Nothing is wrong with the CLI in those cases, so it just tells you what it found. The message, the exit code (6), and the `--format json` envelope are all unchanged, so scripts that branch on them keep working. - A failing build, and a second install of an editor that's already installing, stopped reading like CLI bugs too. `unity build` on a project whose build fails, and any `unity install` that loses the race for the install lock, no longer suggest you "Run `unity bug` to report this issue" — your build failing is your project's state, and waiting on another install is just the situation. For a CI build driver a red build is an everyday outcome. The message, the exit code (6), and the `--format json` envelope — including the `BUILD_FAILED` error code — are unchanged. An Editor that *crashes* mid-build is treated differently — see the next entry. - When the Editor is killed by a signal, `unity build`, `unity test`, and `unity run` now say so instead of reporting a wrong exit code. A crashed Editor (a segfault, say) was reported as "exited with code 1", because a signal death is encoded as 128 + the signal number and the CLI collapsed that to 1 before printing it. You now get "stopped with signal SIGSEGV", naming the actual signal. A crash is also kept distinct from an ordinary failure: your build or tests failing is your project's state, but an Editor that dies is a real fault and still says so. An Editor that exits normally with a code is unaffected and still reports that code, and the exit code (6) is unchanged throughout. `SIGILL`, `SIGTRAP`, `SIGFPE`, and `SIGBUS` deaths are recognized too, where previously they surfaced as a bare number like 132. - `unity --help` shows the Unity logo again. The branded header was missing from all three landing screens (`unity --help`, `unity -h`, and bare `unity`, plus `unity help`), which is where it's meant to appear. Everything else about it is unchanged: subcommand help like `unity install --help` still has no logo, and the header still stays out of the way when you pipe the output, pass `--quiet` or `--no-banner`, or ask for a machine-readable format. - zsh tab completion works. `unity completion zsh` produced a script that defined the completer but never told zsh about it, so pressing Tab after `unity` fell back to plain filename completion with no error to explain why. The script now registers itself however you load it, and the install steps printed at the top of it point at the `$fpath` method zsh expects. Save it once and Tab starts completing commands, subcommands, and flags: ```sh mkdir -p ~/.zsh/completions unity completion zsh > ~/.zsh/completions/_unity ``` Then make sure your `~/.zshrc` has `fpath=(~/.zsh/completions $fpath)` followed by `autoload -Uz compinit && compinit`. bash, fish, and PowerShell completion are unaffected. - The `--proxy` help text now shows its credentialed example as `http://:@host:8080`, with the username and password in angle brackets, so it's clear those two parts are yours to substitute. In Spanish the username in that example had also been mistranslated to the verb "usar", which no longer happens: the URL examples now live in code and are no longer translatable.