jingham added a comment. We shouldn't lightly change options that are commonly used. But we haven't made a strong statement about this the way we do for API. I'm more concerned about people having to rewrite/build and distribute their code to accommodate a new lldb than having to learn a new character for a not very commonly used option.
I think it's more common to run `env FOO=Bar` or set the env-vars. And building up complex "process launch" commands doesn't seem like the best way to use lldb in a scripted manner. So this seems like a pretty benign change to me. I would really like it if wherever we are introducing a scripted plugin to lldb, we pass its arguments in the same way. Since we're passing in dictionaries as the most flexible way to muster configuration info into the script interpreter, so --key --value are the most natural options, and so -k and -v... I'd really rather not have this be different across commands. OTOH -v doesn't really scream "environment" and we don't use that as an option anywhere else, so it seems more natural to change --environment's short option. Might be good to change it to -E not -V. -e wasn't free because we use it for stderr everywhere, but -E is free and makes more sense. But it might be worthwhile to bring this up on lldb-dev to see if anybody has reasons not to do this that I haven't thought about? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D95100/new/ https://reviews.llvm.org/D95100 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
