Interested in opportunities to match modern application UX in cron and find.
For example, the interactive crontab -e editor is an awkward way to configure scheduled jobs. It assumes that /tmp is always available (at least with a vi editor), which is not always the case, in certain environments and scenarios. It doesn't play well with modern, IaC provisioning, in other words, ordinary text configuration files. Also, the contents of -e are relative to the user privilege context (root/sudo vs non-root user). That is more accident prone than direct text files, which tend to be housed in directories that convey more context about job ownership (/etc vs $HOME). Allow cron configuration files to have a (.cron) file extension. This helps text editors and linters to correctly identify cron job configuration files, without having to resort to modeline tricks. While I would heartily recommend a cloud scheduler such as Google Cloud for many kinds of tasks, there are still many uses for humble cron, and so I think it deserves some more polish. -- In find, support for units other than days (s, m, h, d, w for seconds, minutes, hours, days, weeks) encourages safer, more intuitive commands. Mental math to convert from the high level goal unit to the accepted unit damages productivity and reliability. I don't expect the wording of man pages / help usage menus to be covered by POSIX, but I do want to point out that the meaning of -atime, -mtime, and -mmin are not explained very well today by either GNU or macOS implementations. As a user, I want the explanations written in terms of time windows, with explicitly open or explicitly closed bounds on each side. The documentation for these flags is cumbersome to interpret, and so experimentation with a test environment of the particular implementation is necessary to identify the actual behavior. The macOS and presumably BSD implementations of find document the signededness, explicitly accepting optional negative (-) or optional plus (+), but not the GNU implementations. Regardless, less than (<), less than or equal to (<=), greater than (<), and greater than or equal to (>=) would be a more intuitive syntax.
