Governing the Shortcut: Configuration, Extension, and Consequence
The Fuck becomes most useful when it fits a user's commands, but that fit is not free. This chapter asks how to govern the shortcut: which rules and evidence paths to enable, what a custom rule is allowed to do, and how to review a correction that chains several commands before retrying the original. The practical outcome is a conservative operating policy that treats configuration as control over scope and authority, not as a collection of harmless preferences.
Configuration is policy, not a menu
The settings surface looks broad because The Fuck sits between a failed command and a live shell. A user can choose or exclude rules, change their ordering, decide whether confirmation is required, set waiting limits, control how much history is inspected, alter colors and debugging output, choose whether repaired commands enter history, and tune slow-command, instant-mode, and executable-search behavior. Each choice changes a different part of the evidence-to-repair loop. The useful question is not “Which options are available?” but “Which uncertainty and authority am I willing to accept in this environment?”
The project combines settings from a user configuration file, environment variables, and command-line arguments, with later sources taking precedence. That arrangement supports different scopes of control. A stable preference can define the normal rule set. A shell session can change the policy for a particular environment. A one-off invocation can turn on debugging or change the interaction mode without rewriting the durable configuration. The same precedence also creates a debugging obligation: when behavior differs from expectation, the effective setting may come from a higher-priority source than the file a person inspected.
Rule scope is the first policy decision. Enabling the normal catalog offers broad coverage, but it also means more modules can inspect each failure and more candidates can appear. Selecting a smaller set makes behavior easier to reason about and can reduce interactions among rules. Excluding a rule is useful when a particular command family is too risky or too noisy for the user's work. There is no universal winner. Broad coverage suits a general interactive environment; narrow coverage is easier to audit when commands affect production systems, credentials, repositories, or shared files.
Priority is a second policy decision. Changing it does not make a candidate more correct; it changes which rule's answer is encountered first and how alternatives are ordered. A user might prefer a conservative structural repair over a forceful workaround, or an application-specific parser over a generic close match. That preference belongs in priority and rule selection, but it should remain visible as a preference. Reordering candidates is not the same as validating them.
Latency settings expose a third decision. Shorter waits make the correction gesture return quickly, but they increase the chance that The Fuck will receive no output for a slow command. Longer waits improve the chance of obtaining evidence while holding the prompt longer. The configured list of slow commands is an explicit compromise rather than a measurement of every command's runtime. Similarly, enabling instant or logged capture can avoid a rerun but introduces terminal and persistence assumptions. A configuration that feels fast may be drawing its speed from less complete evidence or more elaborate setup.
History and cache settings shape what the system remembers. Recording a repaired command can make a successful correction available to later history-based matching, while leaving the original command in the record may preserve a more faithful account of what the user first attempted. The choice depends on whether history is primarily a working memory or an audit trail. Memoization and the persistent cache can reduce repeated environmental work; the persistent cache uses dependency modification times to decide when stored values should be refreshed.