Done Secondary shells should not search for - but reuse - the current configuration file.

[djspits]

The OP (tue, 15 oct) was heavily modified by the author (wed, 23 oct) in an attempt at more normality in the discussion.

I am (re)considering the response I received to my original posting. I am of the opinion that it shouldn't be necessary to write an in-depth - technically and historically correct - analysis, just to make a suggestion. Since we don't have access to the source code we are always a step behind anyway. Frankly, I do not care why certain functionality exists. If existing functionality doesn't work, works differently than advertised or works in a counter-intuitive way, I think my contribution should be taken seriously and as friendly attempt to contribute to the quality of the product.

So, considering the current behavior of tcc.exe, when starting a shell (any kind), TCC executes the search for the default configuration file unless the /@... option is passed to tcc.exe. if the specified file does not exist, tcc initializes with the built-in default values and empties the envar _ininame. This silent failure can only be diagnosed by checking that single envar. I can see no reason why a user would *not* want to be warned if there is some problem with locating or accessing that pivotal configuration file. The resulting problems can be very time-consuming to diagnose.

Next, if the user starts a *secondary* shell, tcc re-executes the aforementioned search although a 'tried and tested' configuration file is already in use and its specification is in '_ininame'. If the user does not explicitly repeat the /@ option, tcc will silently revert to a default configuration file if one can be found, or to built-in values if one cannot. This seems counter-intuitive to me. There was very probably a good reason why the user took the trouble of specifying an alternate configuration. (E.g. the defaults don't exist, yet.) There is no reason to assume that this reason has disappeared.

I suggest that,
- tcc issues a warning when a configuration file cannot be found or accessed or is empty
- when starting secondary shells, TCC should reuse the primary's inifile and not re-execute the search
- there is ample room for improvement of the Help file to explain the inner workings of (sub)shell initialization.

The burden should be on the user to specify something only if they want to use an alternate configuration file, not merely to continue using one that is already in use.

 

[vefatica]

Primary shells all inherit their environment from the top-level process which is always Explorer.exe.

That's not exactly true. A processes inherits the environment of its parent process. For me, that's never Explorer. I start TCC from AutoHotKey hot keys, from PowerPro buttons, and from DevStudio buttons (external tools). In each case TCC inherits the respective environment.

As for the suggestion, I haven't figured out exactly with it is. In order to "reuse the current configuration file" I suppose TCC must search for it ... yes/no? What exactly are you suggesting?

You can have alternate INI files and specify one on TCC's command line. I believe the syntax is "TCC @path\alternate.ini". IIRC, as the target of a shortcut you must use "/@path\alternate.ini" (to work around an Explorer quirk).

 

[rconn]

The fundamental issue here is that Windows has no concept of a "secondary shell."

TCC has some hacks that fake a parent / child relationship, but they were added because some users couldn't let go of 4DOS, not because they have any meaning in Windows.

 

[djspits]

That's not exactly true. A processes inherits the environment of its parent process. [...] In each case TCC inherits the respective environment.

It is exactly true. What you're seeing in each respective environment is the primary environment (inherited by your utility) plus its changes (which we call a secondary environment) passed on to TCC. There is no tertiary or somesuch. If it ain't primary it's secondary. If you made a spawning chain of your utilities you would see an additive effect. Until ... you started a new primary shell (in the world of TakeCommand with START /I ) and then all these additions would be gone again.

You can have alternate INI files and specify one on TCC's command line. I believe the syntax is "TCC @path\alternate.ini". IIRC, as the target of a shortcut you must use "/@path\alternate.ini" (to work around an Explorer quirk).

Yes, you can have alternate configuration files. If the name or the location is something other than the standard you must pass it on the command-line in order to prevent TCC from using a standard one.

As for the suggestion, I haven't figured out exactly with it is. In order to "reuse the current configuration file" I suppose TCC must search for it ... yes/no? What exactly are you suggesting?

The current configuration file is what _ininame points to. Secondary shells don't need to repeat the search. They already have a configuration file. In fact the repeated search is a nuisance because you have to keep forcing each shell to use your specific one. If you forget to do so, you land in the wrong configuration which might kick off the wrong TCStart batches, for example.

 

[djspits]

The fundamental issue here is that Windows has no concept of a "secondary shell." TCC has some hacks that fake a parent / child relationship, but they were added because some users couldn't let go of 4DOS, not because they have any meaning in Windows.

Let's try to clarify the wording and agree on a single interpretation.

The concepts of primary/secondary- and parent/child processes are used frequently in Microsoft's own documentation. The concepts exist. They are used. We cannot deny that.

I already conceded in previous discussions that processes in Windows differ from processes in e.g. Linux. I could summarize the differences here but that would distract. Certainly, the concept of parent - child relationship between Windows' processes only refers to 'who asked for the creation of who', not to ownership. Anyway, this relationship has nothing to do with my original posting.

So, back to primary en secondary shells. I concede again, if you insist, that there are no functional differences. However there are differences in the data. I am referring to the environment of course.

[to be continued...]

 

[vefatica]

Yes, you can have alternate configuration files. If the name or the location is something other than the standard you must pass it on the command-line in order to prevent TCC from using a standard one.

I finally figured out that that's what you were saying. But I can't see it happen. As far as I can tell, TCC passes the current settings.

TCMD.INI contains "ANSI=Yes" and "ErrorColors=Bright Red on Black". I copied TCMD.INI to v:\TCMD.INI.ALT, changed those to "ANSI=No" and "ErrorColors=Bright Whi on Black" and, from Start\Run issued

d:\tc25\tcc.exe @v:\tcmd.ini.alt

TCC started without ANSI and with no ANSI and with Bright Whi on Black error messages. From the TCC prompt I issued

d:\tc25\tcc.exe

It apparently passed on the current INI settings (and did not search for an INI file) because the subshell also had no ANSI and Bright Whi on Black error messages.

I also tried it in a pipe. From the TCC started with TCMD.INI.ALT ...

dir | echo ^e[32mfoo^[0m

and

dir | cd goo

The result: ANSI was off and error messages were Bright Whi on Black (not coming from the default INI file).

So, if what I quoted is what you meant, and I'm not testing correctly, please tell me how to see it happen.

 

[vefatica]

P.S., My default INI file in TCC's home directory. According to the help, that's the first place TCC looks for an INI file.

 

[rconn]

TCC puts the INI settings into shared memory, and "secondary" (not really) TCC processes read the shared memory to get their .INI values.

 

[rconn]

Let's try to clarify the wording and agree on a single interpretation.

The concepts of primary/secondary- and parent/child processes are used frequently in Microsoft's own documentation. The concepts exist. They are used. We cannot deny that.

I already conceded in previous discussions that processes in Windows differ from processes in e.g. Linux. I could summarize the differences here but that would distract. Certainly, the concept of parent - child relationship between Windows' processes only refers to 'who asked for the creation of who', not to ownership. Anyway, this relationship has nothing to do with my original posting.

So, back to primary en secondary shells. I concede again, if you insist, that there are no functional differences. However there are differences in the data. I am referring to the environment of course.

[to be continued...]

Aside from child pipe processes (where TCC inherits the INI data from shared memory, not from reading TCMD.INI, and where having a separate TCMD.INI would likely cause mayhem), I have yet to see a case where a "secondary" shell makes any sense.

Can you give me an example of why you would want to use secondary shells (especially ones that sometimes inherit INI directives and sometimes don't)?

 

[vefatica]

Aside from child pipe processes (where TCC inherits the INI data from shared memory, not from reading TCMD.INI, ...

My tests above suggest if I issue %COMSPEC at the TCC prompt, or if TCC uses a new instance in a pipe, them I get a "child" process (as above, with inherited/shared INI settings)). Is that correct?

In contrast, if I issue "start %comspec" I get one with fresh INI settings.

All that seems good to me.

 

[rconn]

My tests above suggest if I issue %COMSPEC at the TCC prompt, or if TCC uses a new instance in a pipe, them I get a "child" process (as above, with inherited/shared INI settings)). Is that correct?

In contrast, if I issue "start %comspec" I get one with fresh INI settings.

All that seems good to me.

That's correct (aside from the part about the new instance being a "child" process …).

 

[djspits]

That's correct (aside from the part about the new instance being a "child" process …).

All that seems good to me.

I have rewritten my suggestion. Looking forward to your constructive remarks.