jingham added a comment. In D76470#1934146 <https://reviews.llvm.org/D76470#1934146>, @friss wrote:
> In D76470#1933910 <https://reviews.llvm.org/D76470#1933910>, @jingham wrote: > > > Is there any command-based way to see the entire environment that a process > > will get when it launches? By populating target.env-vars with the > > inherited environment there was a way to mostly do that, but I don't see > > that anymore. It seems a shame not to be able to see that... > > > No, there is no way to do this, but it's not really a regression. If you do > `settings show target.env-vars` today before running then you won't see what > is going to be passed. Only after the first run will it be populated. This > was a surprise to me and I find it highly inconsistent. Maybe I can add > another property that would get updated with the computed environment. Do we > have anything like read-only properties? No, but I don't think I'd do this with a property anyway. You are asking the target to compute the result of the various settings that affect the environment of a process it might launch. That sounds more like the result of a command ("target show-environment" or something like that.) If we knew how to get the environment from a running process, the same command could show the current environment in a running process, which would sometimes be handy. I agree the behavior before was pretty unhelpful, so I don't think you need to add a new command to access this in this change set. But we should put it on our list of things to do. > > >> Also, it does seem weird to me that unset-env-vars would override setting a >> target.env-var explicitly. What I'm likely to do is say: environment >> variable 'PUT_HERE_TO_ANNOY_JIM' is always getting set, and I don't want it >> to be when I'm debugging, so I put: >> >> settings set target.unset-env-vars PUT_HERE_TO_ANNOY_JIM >> >> in my .lldbinit and then after a couple month of debugging happiness, I >> forget that I put it there. >> >> Then for some reason in a debugging session I want to set it. So I do: >> >> (lldb) env PUT_HERE_TO_ANNOY_JIM="Okay, This One Time..." >> >> But then when I run my process, it doesn't get set. Now I have to go back >> and remember that I had done the unset thing... >> >> It really seems to me the automatic unsets should happen before the explicit >> sets. And given the only way you get anything before the automatic sets is >> the inherited environment, it doesn't make sense to me to apply the unsets >> if inherit is off. > > This is pretty far-fetched to me, but I also don't really care. I'm fine with > having `env-vars` override `unset-env-vars`. If a variable FOO exists in lldb's environment with the value BAR, and then I have done `env FOO=BAZ`, when the process launches, FOO will be BAZ, not BAR. So it would be inconsistent to have env-vars override the values of lldb environment variables, but not the entries in unset-env-vars. So I do think that way makes more sense. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D76470/new/ https://reviews.llvm.org/D76470 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
