Wrong flag is set for weekly definition

[nerg4l]

As far as I know @weekly means 0 0 * * 0

At the moment DOW_STAR flag is set for this definition, but it should be DOM_STAR (M instead of W).

cron/entry.c

Lines 147 to 158 in 3ce0c3a

	} else if (!strcmp("weekly", cmd)) {
	set_element(e->minute, FIRST_MINUTE, LAST_MINUTE,
	FIRST_MINUTE);
	set_element(e->hour, FIRST_HOUR, LAST_HOUR,
	FIRST_HOUR);
	set_range(e->dom, FIRST_DOM, LAST_DOM,
	FIRST_DOM, LAST_DOM, 1);
	set_range(e->month, FIRST_MONTH, LAST_MONTH,
	FIRST_MONTH, LAST_MONTH, 1);
	set_element(e->dow, FIRST_DOW, LAST_DOW,
	FIRST_DOW);
	e->flags |= DOW_STAR;

I noticed the same "bug" in cronie-crond/cronie#52 a few years ago.

[vixie]

please have a look at #25

are the flags on the other @ macros all correct?

[nerg4l]

0 0 1 1 * --> @yearly and @annually
Day of week star --> DOW_STAR

0 0 1 * * --> @monthly
Day of week star --> DOW_STAR

0 0 * * 0 --> @weekly
Day of month star --> DOM_STAR

0 0 * * * --> @daily and @midnight
I don't know if DOW_STAR and/or DOM_STAR flags should be added or not

0 * * * * --> @hourly
Hour star --> HR_STAR

Edit: I had to change the @xyz to formatted code. I accidentally referenced a bunch of GitHub users.

[vixie]

<<I don't know if DOW_STAR and/or DOM_STAR flags should be added or not>>

right. i can see from the code which flags are currently set by which @ macros. the purpose is to remember, in the entry in memory, whether a wildcard was used for that time domain. this is to implement some of the odd semantics of posix cron where the meaning of some time domains depends on whether others were wildcarded or not. so your original report at top of thread may not have been a real bug, depending on whether we want @mumble to work exactly as if * had been specified for some time domain, or whether we want it to behave as though first-to-last (lowest value to highest value) had been specified, which would not trigger wildcard semantics in the interpretation of that entry in memory. so what i'm asking for here is not which flags are set by each @ macro, but rather, which ones ought to be set in order to avoid violations of the law of least astonishment.

[nerg4l]

It took me while to understand your message. Unfortunately, English is not my main language.

First of all, you are correct. My original report is not a "real" bug. The current implementation handles it correctly.

I checked how a job is "found", and there are two cases regarding day-of-week and day-of-month handling.

1. One of them has a star symbol and the other does not.
2. Both or neither of them has the start symbol.

As long as, these apply, every rule is handled correctly. Also, when both of them are starts, it does not matter if || or && is used between because both of them is true.

cron/cron.c

Lines 317 to 319 in 3ce0c3a

	((e->flags & (DOM_STAR|DOW_STAR)) != 0
	? (thisdom && thisdow)
	: (thisdom || thisdow))