# 10. The shell

Your login shell is **nushell**. Its pipelines carry structured data rather
than lines of text, so `ls | where size > 10mb | sort-by modified` is a whole
pipeline and not an awk exercise.

bash is untouched at `/bin/sh` and `/bin/bash`. Nothing that runs a shell
script cares which login shell you use, so the `curl | sh` pattern and every
system script behave exactly as they would anywhere else. If you want bash
back:

    chsh -s /bin/bash

## What is already wired up

- **starship** draws the prompt.
- **zoxide** tracks directories you visit, so `z alloy` lands in that project
  from anywhere.
- **direnv** loads a directory's `.envrc` when you enter it and unloads it when
  you leave. After editing an `.envrc`, run `direnv-reload`.

All three are live at first login with nothing to set up.

## Aliases

A short list, in `~/.config/nushell/aliases.nu`:

| Alias | Runs |
|---|---|
| `ll`, `la` | `ls -la`, `ls -a` |
| `..`, `...`, `....` | Up one, two, three directories |
| `gs` `gd` `ga` `gc` `gp` `gl` | git status, diff, add, commit, push, log |
| `vim`, `vi` | `hx` |
| `du` | `dua interactive` |
| `top` | `btm` |

It is meant to stay short. If the file grows past about thirty lines, the next
alias probably has not earned its place.

## Config

| File | Holds |
|---|---|
| `~/.config/nushell/env.nu` | Environment: `EDITOR`, cursor theme, paths |
| `~/.config/nushell/config.nu` | Shell behaviour |
| `~/.config/nushell/aliases.nu` | The list above |
| `~/.config/starship.toml` | Prompt |

Note that nushell is not bash: `export FOO=bar` is `$env.FOO = "bar"`, and
command substitution is `(...)` rather than backticks. Its own book covers the
differences, and the migration is smaller than it looks because scripts keep
running under bash.

## Becoming root

    run0 <command>

`run0` is systemd's, and it is what Alloy documents instead of `sudo`. It
authenticates through polkit rather than by setuid, and it runs the command in
a fresh session rather than in your shell's.

`sudo` still exists; nothing removes it. Alloy just does not build habits
around it.

## Secrets

Two different jobs, and they get confused for each other constantly:

- **gnome-keyring** is the Secret Service provider. It is what programs call
  when they need to store a credential. You do not use it directly; it is there
  so applications that expect it work.
- **gopass** is where you keep your own logins. It uses an age identity for
  encryption and git for syncing, so a store is a git repository of ciphertext
  and a concurrent edit is a merge conflict rather than a silently duplicated
  file.

Alloy provisions neither with any content. `gopass init` sets up a store when
you want one, and the age identity that decrypts it should never live in the
repository it decrypts or travel with it.

`gopass show -c` copies a password to the clipboard, and Alloy keeps that copy
out of the clipboard history that `Mod+Shift+V` reads. That is not automatic
anywhere else. It works here because gopass is pointed at `alloy-secret-copy`,
which marks the selection private, and the watchers skip anything so marked. Nothing to configure, and the reason it is worth knowing is
the limit: this keeps passwords out of the history *on disk*, and any program
running as you can still read the clipboard while the password is on it. Paste
it and move on rather than leaving it there.

That identity lives on the machine, under `~/.config/gopass/age/`. Run `gopass
config` to see the paths your install is actually using rather than trusting
this page. It matters because it is the one part of the store that is not in
git: clone the repository onto a new machine and you have every password in
ciphertext and no way to read any of it. Copy the identity across yourself, by
hand, over a channel that is not the one carrying the store. Chapter 14 covers
the case where the machine is already gone.