众所周知的是,UNIX的cron运行作业时,无论是日常的月或日的一周的比赛,如果两者都具有明确的价值,而不是一个星号通配符规定:
0 0 * * 1 # every Monday
0 0 1 * * # every month's first day
0 0 1 * 1 # every Monday *and also* every month's first day
0 0 1 * 1-7 # every day
0 0 1-31 * 1 # every day
Run Code Online (Sandbox Code Playgroud)
请注意这些常见示例*在月份字段中的所有内容。
POSIX 规范实际上是这样说的crontab(强调我的):
可以通过两个字段(月中的某天和一周中的某天)指定天数。如果月、月日、星期几都是<星号>字符,则匹配每一天。如果将月份或月份中的某一天指定为元素或列表,但星期几为 <星号>,则月份和月份中的日期字段应指定匹配的日期。如果月份和月份中的某天都指定为 <asterisk>,但星期几是元素或列表,则只有指定的星期几匹配。最后,如果将月份或月份中的某一天指定为元素或列表,并且将星期几也指定为元素或列表,则与月份和月份中的某一天或星期几匹配的任何一天,应匹配。
这似乎宣布了下述时间表将匹配任何一个月或一天的一周:
0 0 * 1 1 # every month's every Monday *and also* every day in January
0 0 * 1-12 1 # every day
0 0 1 1 1 # every month's every Monday *and also* 1 January
Run Code Online (Sandbox Code Playgroud)
据我所知,没有共同的现代或历史的cron实现真正做到这一点,包括SVR4的cron(这一定是第一个到比赛日的日或一周中某一天的)及其后代的OpenSolaris和Illumos的作为以及Vixie cron及其后代Cronie和FreeBSD、OpenBSD、NetBSD、DragonFly BSD和macOS cron,以及BusyBox crond。
相反,所有这些实现总是需要匹配月份字段,而不管任何字段采用什么形式,并且仅根据月份日期和星期几字段是否更改它们的月份日期匹配逻辑包含*或显式值列表:
0 0 * 1 1 # every Monday in January
0 0 * 1-12 1 # every Monday
0 0 1 1 1 # every Monday in January *and also* 1 January
Run Code Online (Sandbox Code Playgroud)
(或者在 BusyBox 的情况下,基于字段是包含完整值范围还是严格子集,而不管使用的语法)
POSIX 规范中描述的行为是否真的在任何地方实现?如果提交缺陷报告,描述是否是规范中可能被纠正的错误?为什么它目前以这种方式表达背后是否有故事?
Digital Unix v4(又名OSF1)实现了这个(此处存档的手册页):
\n\n\n您可以在两个字段中指定执行命令的日期\n(一个月中的某一天和一周中的某一天)。您可以指定这两个字段,或者\n您可以仅指定一个字段。若要仅使用一个字段来指定日期,\n另一字段应包含星号 (*)。如果使用这两种方法,\n只要满足任一规范,就会执行该命令。
\n
Solaris本身也是如此,尽管手册页的文本不够清晰(并且一直如此),但示例 3 清楚地说明了预期的行为:
\n\n\n示例 3 指定月份和星期的天数
\n此示例在每个月的第一天和第十五天以及每个星期一运行命令:
\n0 0 1,15 * 1
\n
Dilloncrond将其解释* * 2 * mon为“该月的第二个星期一”,这虽然有用,但也是非标准的。\n @thanasisp链接的问题中的答案此时阅读起来很有用。“或”行为至少来自System V R2 (约 1985 年)。
我发现在阅读 Open Group 文档时需要注意
\ncrontab 参考中的文本标记[UP] \xe2\x8c\xa6 ... \xe2\x8c\xab表明用户可移植crontab -e实用程序部分的可选行为(对于 ),“输入文件”部分没有任何此类标记。
\n\n最后,如果月份或月份中的某一天被指定为元素或列表,并且星期几也被指定为元素或列表,则与月份和月份中的某一天或星期几匹配的任何一天,应匹配。
\n
我强调了“应”这个词,这毫无疑问:
\n\n\n将
\n对于符合 POSIX.1-2017 的实现,描述强制的功能或行为。应用程序可以依赖功能或行为的存在。
\n对于应用程序或用户,描述强制的行为。
\n
但是,作为系统管理员,我倾向于考虑规范抽象,它不可能是错误的(除非它错误到无法实现)。错误(如果有的话)是在实现中,如果它不符合所声明的规范(对于那些POSIXLY_CORRECT为了理智或利益而扭曲规范的实现者来说,这可能是通常的出狱之举。用户期望)。
| 归档时间: |
|
| 查看次数: |
226 次 |
| 最近记录: |