Developer tools · Crontab generator
Percent signs, quotes and variables: why cron lines break silently
· Why it matters
cron shell validation
A crontab line is not a shell line, and a few characters mean something else there. This post explains the percent sign rule, variable assignment limits and quoting, so commands do what they did in the terminal.
A filename failure after the fifth field cannot be diagnosed by this expression parser
If a generated backup filename is empty, the timing expression may still be correct. `0 3 * * *` selects 03:00 every day; characters after the fifth field never enter ToolAcre’s parser. A command-side failure should not be “fixed” by changing the minute or hour unless the preview itself contradicts intent.
Separate the line before diagnosis. Paste the first five fields into the generator, read the description and note upcoming times. Test the remaining command with the actual cron implementation and shell. This division prevents calendar syntax and command syntax from being debugged as though they were one language.
Percent-sign command semantics are not implemented or tested here
The workbook stated a special percent-sign transformation. No corresponding lexer exists in `cron.js`; its field reader accepts digits, supported names and punctuation used by ranges, lists and steps. The UI also stops parsing after the expression box. It cannot demonstrate what happens to percent characters in a deployed command.
Because cron implementations and complete-file parsers can differ, this article does not universalize that rule from an unverified outline. Consult the target manual and reproduce with harmless input. A browser schedule explanation is not evidence about stdin construction, newline conversion or command payload handling.
Escaping advice requires target-specific evidence and is omitted
Backslash escaping likewise belongs to the command grammar. ToolAcre cannot tell whether one layer consumes a backslash before another, and it never invokes a shell to observe the result. Publishing a copy-ready escaped line would therefore exceed the source evidence and could be wrong for a different target.
Move complex command construction into a separately tested script when that is appropriate for the environment, but validate that approach there. Keep the expression stable while experimenting. The only defensible claim from this repository is that five timing fields can be copied independently from whatever command follows.
Variable assignments are not accepted expression input
A `KEY=value` line does not have five schedule fields and is rejected by this parser. There is no assignment model, expansion engine or environment table in the tool. Whether a real crontab accepts assignments and how it interprets their values must be proven from that system.
This distinction protects portability discussions. ToolAcre accepting `JAN` as a month name says nothing about `$HOME` in a configuration line. Both may appear in one crontab file, but only the calendar expression belongs to the implemented grammar reviewed for these articles.
Quotes and shell selection belong beyond the generator boundary
Quotes are ordinary characters only after the schedule boundary, which ToolAcre never crosses. Its exact-five-fields rule treats extra whitespace tokens as an invalid expression rather than trying to discover a quoted command. The copied placeholder line is output convenience, not a full-line validator.
Shell selection is also absent. There is no `spawn`, `exec` or command interpreter in the source path. Test quoting under the executable environment that will actually receive it, and avoid claiming the generator has approved a line merely because the timing prefix remains valid.
Worked boundary: validate 0 3 * * * independently from a date-stamped command
For a date-stamped backup requirement, first validate `0 3 * * *`. The tool should describe 03:00 every day and display candidates in the chosen zone. Preserve that verified fragment. Then build a harmless command-side test that demonstrates the desired filename under the target scheduler.
Two independent checks produce clearer evidence: one screenshot or assertion for calendar intent, another captured output for command transformation. If the filename is wrong but the candidate time is right, the schedule requires no edit. If both are wrong, address each language with its own documentation.
What this does not cover — the environment and PATH problems covered in their own post
Environment and path behavior also remain outside the generator, so this article does not redirect those topics into another unsupported workaround. It reports the boundary instead: the route constructs five-field expressions, plain-language descriptions, warnings and future wall-clock candidates.
A complete cron deployment needs more evidence than that. Treat special characters, variables and executable resolution as host-side concerns. The generator’s refusal to parse them is useful because it prevents a narrow calendar tool from silently pretending to understand command semantics.
Takeaway: know the characters cron owns — and keep the schedule correct with the generator while you fix the command
Cron lines can contain two grammars separated by position. ToolAcre implements the first grammar only, ending after day of week. Percent signs, quotes and variables may matter later, but they cannot change what `0 3 * * *` means inside this parser.
Keep those questions separate in reviews and incident notes. Verify schedule intent in the browser, then verify command behavior on the target with non-sensitive data. That produces evidence rather than folklore and avoids laundering a workbook claim into a guarantee the code never made.