Commands & shells

A rule runs one command. Cronch’s job is to run it the way you’d run it yourself, and to record what happened.

​

The command

Type the command, or the path to a script, exactly as you would in a terminal. Cronch hands it to the shell you choose (below) to interpret — so pipes, redirects and arguments work as usual.

​

The shell

When you create a rule, Cronch has already scanned your machine and listed the shells that are installed:

• Windows — PowerShell, pwsh, cmd, Git Bash and WSL, when present.
• macOS — zsh, bash, sh and fish, when present.

You also get two special choices:

• Custom… — point at any shell binary and give the argument template to use. The template must contain {cmd}, which Cronch replaces with your command (the default is -c {cmd}).
• Direct (no shell) — run an executable straight, with no shell involved. The command line is split into program and arguments without shell interpretation — handy when you want to avoid a shell’s quoting rules entirely.

​

Working directory

By default, jobs run from your home directory. Set a Working directory on the rule to run from somewhere specific — useful for scripts that expect to be run from their project folder.

​

Environment variables

Jobs inherit your real login environment, so scheduled commands see the same PATH you’d have in a terminal, and tools like node, python and git are found. (This matters most on macOS, where jobs launched at login can otherwise get a stripped-down PATH.) You can add extra variables per rule — one KEY=VALUE per line — for anything a specific job needs, like an API token or a config flag.

​

Overlap: when a run isn’t finished yet

If a rule comes due while its previous run is still going, its overlap policy decides what happens: Set it per rule, so each job gets the behaviour that fits it.

​

Next