Use Long Options in Scripts

Original Article ↗ Hacker News Discussion ↗

Benefits of long options and formatting style

  • Long options are seen as more self-explanatory, easier to grep in man pages, and less prone to typos.
  • Many recommend:
    • Prefer long options in scripts.
    • Put each option on its own line for readability and easier git blame.
    • Use -- to separate options from dynamic arguments for safety.
  • Some also advocate clearer command names and multi-line invocations to reduce “cryptic one-liners”.

Portability vs GNU-isms

  • Major caveat: POSIX does not specify long options; many BSDs and BusyBox utilities only support short options, and GNU tools often have extra, non-portable options.
  • Examples:
    • BSD/macOS sed, rm lack GNU-style long options.
    • Some cases (e.g., base64 --decode) are actually more portable with long options across GNU/BSD.
  • For truly portable scripts or when targeting BusyBox/embedded systems, several commenters insist short options are the only reliable choice.
  • Others solve this by pinning toolchains via Nix or similar reproducible dev environments so they can safely use long options and newer features.

Shell execution and injection safety

  • Strong warning against mixing string interpolation with shell commands (e.g., system("cmd {user_input}")), calling it “SQL injection on steroids”.
  • Recommended patterns:
    • Use array/list-based exec APIs so arguments go directly to execve without going through a shell.
    • If you must use sh -c, treat the script as fixed and pass user data via positional parameters ("$1", $@) rather than string concatenation.
  • Some propose language features/macros that handle escaping for POSIX shells, though others note this is shell-specific and incomplete.
  • There is back-and-forth on when this really matters: some say “never send untrusted input to the shell”, others argue requirements change and trusted inputs can become untrusted.

ARG_MAX and huge argument lists

  • A few mention the ARG_MAX limit: expanding globs over millions of files can exceed it.
  • Suggested approaches: avoid giant argument lists (use stdin/list files, xargs-style patterns) rather than bolting on fragile length checks and eval.

Readability vs density; learning vs memorization

  • One camp: optimize scripts for novice readers and maintainers; long options and clarity beat terseness.
  • Opposing camp: long options are verbose GNU-isms; people should learn the short flags, and over-optimizing for “obviousness” leads to mediocre software.
  • Some note that long options can turn compact one-liners into multi-line blocks, reducing how much logic fits on screen at once.