Shell nesting level, and inherited environment variables

[Just Another Joe]

Using TCC 13. My tcstart.btm from earlier versions (4DOS, 4NT) set the prompt colour based on the shell nesting level %_shell. This has not worked in quite some time, because now %_shell is always zero, and now I'm wondering how to work around this. Any ideas would be appreciated.

I tried setting an environment variable %SHELL_LEVEL, and then incrementing it in tcstart.btm, but it seems that any environment variable I set in one TCC session, whether at the prompt or in a batch file, is not inherited by another TCC session. Is this intended? Workaround?

 

[vefatica]

If the shells are indeed nested (one TCC is the parent process of another) then the child TCC should have an incremented _SHELL and inherit the environment of the parent.

v:\> ver

TCC  13.04.63  Windows 7 [Version 6.1.7601]

v:\> set SHELL_LEVEL=0

v:\> echo %_shell
0

v:\> %comspec

TCC  13.04.63  Windows 7 [Version 6.1.7601]
Copyright 2012 JP Software Inc.  All Rights Reserved
Registered to Vincent Fatica - 5 System License


v:\> echo %_shell
1

v:\> echo %SHELL_LEVEL 
0  ............................... inherited, I didn't increment it

v:\> exit

v:\> echo %_shell
0

v:\>

 

[Steve Fabian]

As Vince reported, when calling a deeper shell, _SHELL is indeed incremented. The reason it does not appear to be implemented in your environment is that there is virtually never a benefit from a deeper shell, instead, one would use additional top-level shells.

If you want to set prompt colors differently for each parallel TCC session, Vince's plugin 4utils.dll ha command GV and function @GV which uses volatile environment variables. These can be used for the purpose in TCSTART.BTM.

 

[rconn]

The whole concept of shell levels is a obsolete leftover from the MS-DOS & Windows 95 days. The only reason the variables are still there is because a few users have a (delusional) belief that they're somehow still meaningful, and complained loudly when I tried to remove them.

So TCC will increment the _SHELL variable when it detects that it has been started from a parent TCC process, but:

1) There's seldom (never?) any reason to start TCC from TCC (unless you're piping output), and
2) There's no logical / physical / spiritual relationship between parent & child processes anyway.

 

[Just Another Joe]

Thanks for the replies, all. It seems to have touched a sore spot with Rex. No offense intended.

You are correct, I rarely use nested shells these days, but rather parallel shells. The important thing to me is not the relationship, but that I would like to change the prompt colour in sequence with each new shell; in addition, the prompt actually begins with the shell number (%_shell), so I can see it at a glance (eg. 2|D:\path>). This all worked perfectly in the old days; it hasn't worked in a long time (in fact, I actually remember reading [probably in the "What's New" section] about the behaviour of %_shell changing), but I'm only now working on it, because of a related reason (below).

When I start a new shell (from a shortcut), it inherits the current alias list, function list, command history, and directory history (because of shralias), but it doesn't inherit the environment. This is important because the first shell, which runs when Windows starts, runs a startup script which sets several environment variables (some of them dynamic), which I would like to be available system-wide (to all shells). Is there some way to make the environment available in the same manner as the above lists, or must I use GV for this (thanks for the pointer to GV, I will check it out)?

 

[Steve Fabian]

One approach is to make the variables to be shared in the registry (default, system, user, or volatile). But it is not recommended, because it propagates to all programs. Personally my TCSTART.BTM loads over 200 variables every time a new TCC instance is started. Using the SET /R takes it is imperceptible, and anyway, my session last many hours. Most are "based", i.e., they are of the form %mstr\..., subdirectories of the "master" directory (often C:\). There isn't any other way to share environmental variables.

 

[vefatica]

Thanks for the replies, all. It seems to have touched a sore spot with Rex. No offense intended.

You are correct, I rarely use nested shells these days, but rather parallel shells. The important thing to me is not the relationship, but that I would like to change the prompt colour in sequence with each new shell; in addition, the prompt actually begins with the shell number (%_shell), so I can see it at a glance (eg. 2|D:\path>). This all worked perfectly in the old days; it hasn't worked in a long time (in fact, I actually remember reading [probably in the "What's New" section] about the behaviour of %_shell changing), but I'm only now working on it, because of a related reason (below).

When I start a new shell (from a shortcut), it inherits the current alias list, function list, command history, and directory history (because of shralias), but it doesn't inherit the environment. This is important because the first shell, which runs when Windows starts, runs a startup script which sets several environment variables (some of them dynamic), which I would like to be available system-wide (to all shells). Is there some way to make the environment available in the same manner as the above lists, or must I use GV for this (thanks for the pointer to GV, I will check it out)?

With SHRALIAS, there's no true inheritance. Simply, all instances use the same lists.
If I understand correctly, you can do what you want with a single "global" variable ... in one of the system environments (but as Steve said, all processes will get it) or in a "private" registry entry (as @GV allows). Create a variable (maybe GSET ShellNum=0) and then in TCSTART.BTM use it to build a prompt and increment it. If (just for example) you have 7 colors (0,1,...,6) ...

iff %_pipe == 0 .and. %_transient == 0 then
set colorindex=%@eval[%@gv[ShellNum]%%7]
REM set the prompt according to colorindex
REM ...
gset ShellNum=%@inc[%@gv[ShellNum]]
endiff

In addition you'll always have a count of how many interactive TCC's you started. :)

 

[Just Another Joe]

Thanks. What's the problem with using a variable in a system environment, and allowing other programs to see it -- is it because then another program may change it?

Vince, I've installed 4utils (thank you for making it available!), and perhaps I'm just dense, but I'm having difficulty in understanding some of the commands/functions/variables just from the included .txt file; is more full documentation available anywhere?

Now here is a strange issue: since installing 4utils (and 4console, 4threads, and sysutils, all x64 versions), now whenever I open a TCC window, it opens to the same size as always, but it now will not use the bottom line of the window, i.e. the window always scrolls up so that the prompt is on the line second from the bottom, and the bottom line is blank. TCC 13 on Win 8.1 Pro 64. Is this a known issue?

Edit: I removed all of the plugins from the plugin directory, and the anomalous behaviour went away; the window once again uses the bottom line.

 

[vefatica]

The TXT file is the only documentation. I'll be glad to help here.

That last line thingy (in 4CONSOLE) is mainly for me (because I don't like reading text on the last line of the console). You're the first to complain about it (or even notice it). I just uploaded a new 4CONSOLE (32 & 64) without that "feature".

 

[vefatica]

And there's no problem at all using the system (or user) environment. Subsequently started apps will get the variable, but unless you give it a poorly chosen name, they will just ignore it.

Now that I think of it, you probably can't write to the system environment (SET /S) unless you are elevated (or actually logged in as admin!!!). So if you don't want to use GSET/@GV, you should use SET /U. 4UTILS has @GEV to facilitate reading variables from the S, U, V, and D environments.

v:\> help @GEV
@GEV[name[,s|u|v|d]] = value of [registry] environment variable

 

[Just Another Joe]

All is working well now, with global variables. Thanks for all the help.

Vince, thanks so much for so speedily making an updated version available. I haven't had a chance to even use it yet!