On Thu, May 24, 2018 at 06:05:52AM -0000, Christian Ehrhardt wrote:
> 2. a "uvt-kvm purge <guest>" command that will remove the files it would create for a guest of that name - with big warnings - that would avoid everyone having to learn which paths to look for
IIRC, uvtool doesn't do any name guessing at destroy time currently.
"purge" would be the only command that follows this kind of heuristic.
I agree that it would be useful to follow this kind of heuristic in your
use case, but I'm not sure that it's appropriate to do this kind of
guessing in a top level subcommand. I'd like uvtool to be more robust in
the default case.
What if we gave destroy a --force/-f option to cause it to do things
even if some aspects of what it might do are already gone, and a
--guess-names option to make it follow the heuristic you suggest?
A downside is that -f --guess-names is tedious to type. Suggestions
welcome.
On Thu, May 24, 2018 at 06:05:52AM -0000, Christian Ehrhardt wrote:
> 2. a "uvt-kvm purge <guest>" command that will remove the files it would create for a guest of that name - with big warnings - that would avoid everyone having to learn which paths to look for
IIRC, uvtool doesn't do any name guessing at destroy time currently.
"purge" would be the only command that follows this kind of heuristic.
I agree that it would be useful to follow this kind of heuristic in your
use case, but I'm not sure that it's appropriate to do this kind of
guessing in a top level subcommand. I'd like uvtool to be more robust in
the default case.
What if we gave destroy a --force/-f option to cause it to do things
even if some aspects of what it might do are already gone, and a
--guess-names option to make it follow the heuristic you suggest?
A downside is that -f --guess-names is tedious to type. Suggestions
welcome.