Language-specific fixes

Nearly every report of "my script sends nothing" has the same cause: your language's runtime holds output in a private buffer when standard output is a pipe rather than a terminal, and websocketd always gives it a pipe. The fix is one flag or one line, and it is different in every language.

Find yours below. Each page opens with the change to make. If you want to know why the runtime behaves this way, read output buffering afterwards; you do not need any of it to apply the fix.

• Stream output from a Python script — Launch the interpreter with python3 -u, or flush after each print, so your script's lines reach the browser as they are produced instead of arriving together at exit.
• Stream output from a Ruby script — Set STDOUT.sync = true at the top of your script so every puts is written immediately instead of collecting in a buffer until the script exits.
• Read input in a Node.js script — Read standard input line by line with readline. Node's output needs no flush, so the Node trap is input: a script that waits for end-of-file never responds at all.
• Stream output from a PHP script — Call flush() after each line, ob_flush() first if output buffering is on, and open the file with the full <?php tag so PHP runs your code instead of printing it.
• Stream output from a C program — Call setbuf(stdout, NULL) at the start of main so every printf reaches websocketd immediately instead of collecting in the C library's buffer.
• Run a .bat, .cmd, or PowerShell script on Windows — Name the interpreter yourself rather than pointing websocketd at the script file, give it a full path, and expect no signal-based cleanup when a client disconnects.