Skip to content

Clarify options and warn about overwriting #791

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
benlangfeld merged 1 commit into from
Apr 24, 2020
Merged

Clarify options and warn about overwriting #791

benlangfeld merged 1 commit into from
Apr 24, 2020

Conversation

@ttilberg
Copy link
Contributor

@ttilberg ttilberg commented Dec 12, 2019 •
edited
Loading

This might help new users select the desired operation, and make it known that some operations are potentially dangerous.

  • Change [identifier] verbage to [schedule]
  • Add notes about overwriting existing crontabs

Today I was exploring this gem for the first time and the existing help page led me to think that -w was the correct option to start with. I ended up overwriting my existing crontab, which was quite unexpected.

I thought it would be helpful to clarify some points in the help banner.

Current banner:

Usage: whenever [options]
    -i [identifier],                 Default: full path to schedule.rb file
        --update-crontab
    -w, --write-crontab [identifier] Default: full path to schedule.rb file
    -c, --clear-crontab [identifier]
    -s, --set [variables]            Example: --set 'environment=staging&path=/my/sweet/path'
    -f, --load-file [schedule file]  Default: config/schedule.rb
    -u, --user [user]                Default: current user
    -k, --cut [lines]                Cut lines from the top of the cronfile
    -r, --roles [role1,role2]        Comma-separated list of server roles to generate cron jobs for
    -x, --crontab-command [command]  Default: crontab
    -v, --version

Banner after this change:

Usage: whenever [options]
    -i, --update-crontab [schedule]  Install the schedule to crontab.
                                       Default: full path to schedule.rb file
    -w, --write-crontab [schedule]   Clear current crontab, and overwrite it with only the given schedule.
                                       Default: full path to schedule.rb file
    -c, --clear-crontab [schedule]   Uninstall the schedule from crontab.
                                       Default: full path to schedule.rb file
    -s, --set [variables]            Example: --set 'environment=staging&path=/my/sweet/path'
    -f, --load-file [schedule file]  Default: config/schedule.rb
    -u, --user [user]                Default: current user
    -k, --cut [lines]                Cut lines from the top of the cronfile
    -r, --roles [role1,role2]        Comma-separated list of server roles to generate cron jobs for
    -x, --crontab-command [command]  Default: crontab
    -v, --version

I'm still a little confused about why there seems to be options for -f and [identifier] which seem to result in similar concepts. If this can be clarified, I think it would also be helpful. I feel that the correct way to specify an alternative schedule should be whenever -i -f 'myschedule.rb'. It would reduce the confusion and complexity of the -iwc options.

Is there anything I've misunderstood about Whenever while making this edit? Any other additions to consider?

Edit: Updated correct "current banner". Sorry, I had one of my previous attempts at cleaning up the banner as the example current banner.

@ttilberg
Clarify options and warn about overwriting
8805cb1 
This might help new users select the desired operation, and make it known that some operations are potentially dangerous.
- Change `[identifier]` to `[schedule]`
- Add note about overwriting existing crontab
@ttilberg
Copy link
Contributor Author

ttilberg commented Dec 12, 2019

This PR is in response to the note I left here: #642 (comment)

@ttilberg
Copy link
Contributor Author

ttilberg commented Apr 20, 2020

@benlangfeld Can you take a look at this and consider merging it? The default behavior if you aren't already familiar how this gem works is very destructive.

@benlangfeld benlangfeld merged commit e916b58 into javan:master Apr 24, 2020
@taketo1113 taketo1113 mentioned this pull request Nov 19, 2025
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@benlangfeld benlangfeld benlangfeld approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@ttilberg @benlangfeld