[thayne]

I wouldn't say that the PATH is ambiguous, but cron does have some problems with PATH:

- the default value is missing some values you would expect, like /use/local/bin and /usr/sbin for root.

- on some distributions (for example Arch Linux) the man page doesn't even say what the default path is, or recommend setting it.

- if you need to add something to the path for a single script, you either need to wrap it with a call to env, set it in a wrapper script, or set the path before the entry and reset it afterwards

- you can't use ~ or $HOME in the path, you have to write out the full absolute path. Which is particularly annoying for user crontabs.

Sure, it isn't too hard to work around those, but IMO systemd timers are a better experience, especially since the default uses the same path as all your other services.

[thomashabets2]

> - the default value is missing some values you would expect, like /use/local/bin and /usr/sbin for root.

What do you mean by "you would expect", that doesn't also apply to systemd timers? /opt/foo/bin is not in the path. Would you expect that?

And if this is an objective problem, can we just change the cron default PATH?

> - on some distributions (for example Arch Linux) the man page doesn't even say what the default path is, or recommend setting it.

Send a PR. This doesn't seem like an inherent problem.

> - if you need to add something to the path for a single script, you either need to wrap it with a call to env, set it in a wrapper script, or set the path before the entry and reset it afterwards

Or on the line, right?

    * * * * * FOO=bar $HOME/bin/foo.sh

The line can get long, but is this really a problem?

> - you can't use ~ or $HOME in the path, you have to write out the full absolute path. Which is particularly annoying for user crontabs.

This is incorrect. You can definitely use $HOME in user crontabs.

I'm still not seeing something that warrants a rewrite. (except what you did not mention, which is the ability to run "trigger this now" as a missing feature)

[thayne]

> What do you mean by "you would expect"

I mean it should include things that are usually on the path, like /usr/local/bin. And for the root user it should include sbin.

I don't really expect /opt/foo/bin to be there, but if you want to have it available by default everywhere then you can just add it to systemd once, rather than having to remember to add it to crontab as well.

> Or on the line, right?

Oh you're right. I forgot cron evaluates the command with the shell (which has its own set of issues...)

> This is incorrect. You can definitely use $HOME in user crontabs.

You can in the command itself, because that is evaluated by a shell, but not when setting an environment variable. From the Ubuntu crontab(5) manpage:

> The value string is not parsed for environmental substitutions or replacement of variables or tilde(~) expansion

Maybe it depends on the cron implementation though. The cronie documentation doesn't say either way.

[thomashabets2]

> I mean it should include things that are usually on the path, like /usr/local/bin. And for the root user it should include sbin.

So changing the default PATH for cron requires a green field rewrite? You would expect /usr/local/bin. cron doesn't include it. It seems like a disagreement on default settings. I would agree with you about what the default should be, but I don't understand how this has anything to do with cron either as code or architecture.

This seems a bit like /sbin being missing in the default PATH for the root user's regular shell being a reason to rewrite bash to systemd shell.

[thayne]

> So changing the default PATH for cron requires a green field rewrite?

I never claimed that.

It's just one of many reasons why I think systemd timers are easier to use.