Shell CGI scripts: bash and sh for simple web tasks

When shell CGI is appropriate

Shell CGI scripts are appropriate when the task does not involve user input at all, for example serving a dynamically generated server-status page that reads system statistics, or returning a JSON response built from the output of a known-safe system command. In these cases the simplicity of a short shell script is a genuine advantage over the overhead of loading a Perl or Python interpreter.

As soon as any user-supplied data (query string, form POST, HTTP headers) enters the script, the risk calculus changes sharply. Shell quoting rules are complex and easy to get wrong; command injection through untreated user input is extremely common in shell scripts. If you need to handle user input, use Perl or Python where taint mode, parameter parsing libraries, and explicit escaping functions make the job tractable.

Printing headers from a shell CGI script

A shell CGI script prints the Content-Type header to stdout with a double newline: printf 'Content-Type: text/html\n\n'. Using echo can work but varies between shells and OSes in how it handles newlines and the -e flag; printf is portable and predictable. The body follows immediately after.

Error messages from shell commands go to stderr, which the web server typically logs rather than sending to the browser, so you will not see command errors in the response unless you redirect them explicitly. During debugging, redirect stderr to stdout (2>&1) after the headers to see what went wrong, and remember to remove that redirect in production.

Reading GET parameters in a shell script

GET parameters arrive in the QUERY_STRING environment variable as a URL-encoded string like 'name=hello+world&age=30'. Decoding this in pure shell requires replacing + with space and decoding %XX sequences, which is error-prone without a library. A practical approach is to call a Python or Perl one-liner to do the decoding: VALUE=$(python3 -c "import urllib.parse,os; print(urllib.parse.parse_qs(os.environ.get('QUERY_STRING',''))['fieldname'][0])"). This is awkward enough to suggest that if you need more than one or two simple parameters, switching to a Python or Perl script is cleaner.