I’m currently working on a grav port of my former WP Plugin wp-caldav2ics which can be found on GitHub.
I’ve managed to get it to work for me, but there is still an issue that would prevent it to work for others, if their php executable on the server is other than /usr/local/bin/php (as it is for me, currently hardcoded as ‘#!/usr/local/bin/php’).
the weird thing is: if I use the shebang ‘#!/usr/bin/env php’ for the file jobs/create_calendars.php (which actually does the real job) from the commandline, all is ok.
but when it is called from the grav scheduler via $scheduler->addCommand() as described in the docs, it fails with
/usr/bin/env: 'php': No such file or directory
in the log, so, obviously, the shebang which should find the correct php path, does not work here.
This is where I’m stuck ATM, maybe someone here has an idea how to solve this.
as an addition, I just want to state that it is far less work to create a nice grav plugin backend via blueprints as in Wordpress 
so, well, after some more investigations, I got this eventually solved 
- although not the
/usr/bin/env: 'php': No such file or directory
issue, but with some code from the grav Scheduler itself I could determine the System’s actual php Path and used that to create a correct shebang for the external php script called by the Scheduler.
Not that elegant, but, ATM, WORKSFORME .
After update your change will be gone if you changed Grav’s system file. Maybe it would be better to create a Pull Request with a fix/improvement
well, I thought about that, yes - in fact the original job file from the plugin is never changed/overwritten, but, in case the standard shebang does not match the system’s php path, a copy of the job file with corrected shebang is created and used from then on.
this happens upon save of the configuration in the admin.
I know it would be better to do this just once upon Installation or update, but I didn’t find any grav hook or event which would allow that.
so, it is now necessary to just save the configuration in admin once again, in case of an update which brings a changed jobfile (which is unlikely, ATM).
and, yes, you’re right w.r. to a pull request, but unfortunately, I don’t have a fix currently.