@david_chisnall@infosec.exchange
Post #2535078
2026-01-08 08:21 UTC
@nblr@chaos.social The original yacc had a limitation that it couldn’t complete a parse if the last token was a valid token and required a white space character afterwards. This ended up being incorporated in specifications in a bunch of places. It’s undefined behaviour in C to not end a file with a new line because early C compilers couldn’t handle it. I presume the crontab rule in POSIX is the same. Modern yacc implementations don’t have this limitation and so there’s little reason not to accept things with missing terminating newlines (in both cases, the program is free to accept non-conforming inputs). At the very least, there’s no excuse for not raising an error.
Replies (2)
-
@mgedmin@floss.social 2026-01-08 09:53
@david_chisnall@infosec.exchange @nblr@chaos.social i've seen this justified as 'the file could be truncated, and it could lead to badness', if e.g., a command like 0 0 * * * rm -r /tmp/daily-debug-logs/ got truncated after the first / (ignoring the modern --preserve-root behaviour of rm for simplicity). Not complaining loudly to the logs when cron detects a malformed crontab is a crime if still true.
-
@feld@friedcheese.us 2026-01-08 19:52
@david_chisnall@infosec.exchange @nblr@chaos.social is this the reason why git will complain "No newline at end of file" as well? Like a hint that you're in for a bad time if you don't have one?