cron: Consume blanks in system crontabs before options. #456
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
Details:
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.
eborisch
added a commit
to eborisch/cron
that referenced
this pull request
Feb 19, 2021
Changes / issue described in freebsd/freebsd-src#456.
|
Bugzilla link: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253699 |
|
Resolved by upstream commit. |
|
Re-opening for tracking until MFCed. |
|
The fix has been MFCed to stable/13 |
hardenedbsd-services
pushed a commit
to HardenedBSD/hardenedBSD
that referenced
this pull request
Feb 10, 2023
This adds the full set of jemalloc functions that FreeBSD's libc exposes, including some (the `*allocm` family) that are gone from newer versions of jemalloc and the `*allocx` family that replaced them. These are not necessarily efficient implementations but they should allow snmalloc to replace jemalloc without any ABI breakage (in the loosest possible sense). Jemalloc provides a very generic sysctl-like mechanism for setting and getting some values. These are all implemented to return the not-supported error code. This may break code that expects that they will succeed. In particular, these APIs are used to register custom backing-store allocators and to manage caches and arenas. These concepts don't map directly onto snmalloc and attempting to do so would almost certainly not provide the same performance characteristics and so it's better to `LD_PRELOAD` jemalloc (or explicitly link to it) for programs that gain a significant speedup from this.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Details
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<space><space>-n truewill fail, as the shell will try to execute (' -n true'), while an entry like:
* * * * * username<space>-n trueworks as expected (executes 'true').
Working cases (with or without this change)