Declined CMDLINE and CMDLINE2

[vefatica]

I'm not sure what to suggest. I have been doing some programming involving environments, and I've looked at the environments of many programs.

Here, TCC runs a logon script which, among other things, starts PowerPro and AutoHotKey. I start almost everything from one of those two programs or from TCC itself. And almost every program I run has CMDLINE and/or CMDLINE2 set; the ones started by PowerPro and AutoHotKey get ancient (from login time) values for those variables. In any case, they're meaningless to those programs.

How about a way to keep CMDLINE and CMDLINE2 from being inherited by executables?

 

[Joe Caverly]

A couple of things (not tested).

Start /I - Inherit the default (startup) environment, rather than the current environment.

Set /m - If a variable name is specified, change it to the original value when TCC started.
If no name is specified, revert the entire environment to the original environment when TCC started.

Joe

 

[Charles Dye]

I seem to recall that you could disable the CMDLINE variable by prefixing an @ sign to the command line. I don't think this trick will work with CMDLINE2, though.

 

[vefatica]

I seem to recall that you could disable the CMDLINE variable by prefixing an @ sign to the command line. I don't think this trick will work with CMDLINE2, though.

Yeah, but all the time!

 

[rconn]

You probably have LOTS of variables that are meaningless to PowerPro & AutoHotKey -- why should CMDLINE and CMDLINE2 be treated differently?

 

[AnrDaemon]

And almost every program I run has CMDLINE and/or CMDLINE2 set; the ones started by PowerPro and AutoHotKey get ancient (from login time) values for those variables. In any case, they're meaningless to those programs.

There's always variables which are meaningless to a given program.
Why would any given one should be an exception?