-
Notifications
You must be signed in to change notification settings - Fork 22
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.
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
what should sr3 --dangerWillRobinson remove do? #827
Comments
One option is forcing a user to explicitly specify |
what if --dangerWillRobinson had an argument... and the argument had to equal the number of configurations being affected.
then it will only proceed if number of configurations that result from expanding poll/a* is exactly 2. |
it would perhaps default to two... since for 1 you don't need the option... |
I like Reid's option of using Should we just just outright ban the use of |
Making --dangerWillRobinson take an argument that has to match has a lot more value... it will stop all mismatch mistakes... I
|
example ... someone says sr3 --dangerWillRobinson remove poll */* they left a space between poll and the * ... with just the specification, it will go through, but if --dangerWillRobinson 5 is there, indicating it should match exactly 5 configurations, then the */* will match 20, and it will refuse. |
have a branch doing it, here is an example: fractal% sr3 status
fractal% sr3 --dangerWillRobinson=1 remove
So since remove and/or cleanup are quite dangerous in practice, force fractal% sr3 status | grep stop | wc -l
fractal%
fractal% sr3 status
It is a lot more difficult to do something dangerous by mistake... |
folks agreed with it... |
This is the sr3 version of "rm -rf /" ... with help, can be recovered, but it's painful... There are no interactive prompts in the entire application... the --dangerWillRobinson is the only thing between a user and oblivion... is this too dangerous should we do something else?
The text was updated successfully, but these errors were encountered: