https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271582
Xin LI <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|[email protected] |[email protected] Resolution|--- |Works As Intended Status|New |Closed CC| |[email protected] --- Comment #12 from Xin LI <[email protected]> --- I completely understand the frustration here. It is admittedly counter-intuitive that a valid-looking text file fails silently just because it misses an invisible character at the very end. From a UX perspective, it feels like cron is being unnecessarily pedantic. However, after reviewing the history and safety implications, I think we should keep the behavior as-is. The strict requirement for a trailing newline (\n) isn't just about adhering to POSIX standards; it acts as a critical safety check against truncated files. cron often runs with high privileges (root), and we must assume that a crontab file could be partially written due to a system crash, power loss, or a full disk during the edit. Consider this scenario: Intended command: A user writes a cleanup job: 0 0 * * * rm -rf /tmp/garbage The Failure: The disk fills up or the system crashes while the file is being written, truncating the last few characters. The Result: The file on disk ends up as: 0 0 * * * rm -rf / (EOF) If we modify the parser to be "tolerant" and execute the line without a confirming newline, cron would wake up and execute rm -rf /, potentially destroying the system. By insisting on the newline, we treat it as a "commit marker". It confirms that the author finished the thought and the write was successful. If the newline is missing, cron assumes the file is corrupted or incomplete and safely refuses to run the command. While I agree this is a friction point for users, the risk of executing partial commands—especially delete operations—is too high to relax the check. -- You are receiving this mail because: You are the assignee for the bug.
