Bug 253699 - cron: Fix options parsing in system crontabs.
Summary: cron: Fix options parsing in system crontabs.
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
Depends on:
Reported: 2021-02-19 18:23 UTC by eborisch+FreeBSD
Modified: 2021-02-19 18:23 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description eborisch+FreeBSD 2021-02-19 18:23:20 UTC
Pull request up on GitHub; comment copied here.


This change makes the state consistent between user and system crontabs
before processing options:  blanks have been consumed and the next
get_char() returns '-' or the start of the command.


On system crontabs, multiple blanks are not being consumed after reading the
username. This change adds blank consumption before parsing any -[qn] options.
Without this change, an entry like:

  * * * * * username  -n true  # Two spaces between username and option.

will fail, as the shell will try to execute (' -n true'), while an entry like:

  * * * * * username -n true   # One space between username and option.

works as expected (executes 'true').

For entries without options, this is not an issue, as the leading blanks are
ignored by the shell when executing the command.

For entries with only one blank character between the username and options,
this is also not an issue, as the next get_char() returns '-' and option
processing occurs.

For user crontabs, this is not an issue as the preceding (day of week or
@shortcut) processing consumes any leading whitespace.