Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

4NT 9.02 _shell internal variable

Hello, I am new to this Forum, but have been a long time 4NT user. I recently upgraded to 4nt/Tcc version 9.02. I have historically always modified my command prompt to include my nested shell number (option -z, I believe). When I installed version 9.02, this behavior appeared to no longer work.

I ran a quick test by opening up a 4NT window and checked the value of _shell. It was 0, as expected. I then executed "4nt.exe" from the command line to create a nested shell. Again, I checked the value and it was still 0, not 1 as I expected. I then had to perform two "exits" in order to fully close the window - as expected.

Is this a known bug with _shell in 9.02, or am I missing something? (Incidentally, I also checked the value of the new internal variable (_shells) and got the same results.

I am running on Vista.

Thanks for any help.
Greg


UPDATE:
After all of this discussion and investigation, this appears to me to be a bug in 9.02. It looks like when I install on Vista using the default destination folder, the installer puts a SFN into my PATH for my TCMD9 directory. A "Which /A 4nt" command confirms this, giving me a single SFN entry (this happens when I perform the which command at the command prompt from any directory OTHER THAN the TCMD9 directory. If I run "Which" from within the TCMD9 directory, I get two entries - one long and one short, and my shell works in this limited case.). From any directory other than the TCMD9 directory, issuing a second 4nt command at the command prompt then created a second shell, but _shell was not being updated properly.

Solution/Workaround:
1. I ended up putting the LFN equivalent into my PATH ahead of the SFN. I now have two entries for TCMD9 in my PATH (long and short). This way, 4nt tools that need the LFN will find what they need; and 4nt tools that need the SFN will also find what they need. (Long is ahead of Short.)
2. Set ComSpec to be the complete long path to 4nt.exe.
3. I then created an alias: alias 4NT `%ComSpec`
4. And then another alias: alias tcc `%ComSpec`
5. Now when I invoke either 4NT or TCC, the executable 4nt.exe is always launched using the complete path. Proper shell nesting now occurs.

I want to thank all of you for your quick responses and your debugging/checking. You really helped me out a lot. Hopefully, I can return the favor someday.

Greg
 
Do you really still have tools that need the SFN path? I can't imagine
anything needing it now. The only ones I could imagine that would need
it would be the ones that also only ran in 16-bit, using NTVDM, and
those don't even work on Vista any more (as I understand it, not being a
Vista user). Does anything really break if you completely remove the
SFN from the path?

As an aside to Rex, why would the SFN have been placed in the path in
the first place? Or are we dealing with some strange environment of
Greg's, where this would not be seen normally?

________________________________

From: Greg Wells [mailto:]
Sent: Thursday, August 28, 2008 10:50 PM
To: Mickey Ferguson
Subject: RE: [Support-t-416] Re: 4NT 9.02 _shell internal variable

Solution/Workaround:
1. I ended up putting the LFN equivalent into my PATH ahead of the SFN.
I now have two entries for TCMD9 in my PATH (long and short). This way,
tools that need the LFN will find what they need; and tools that need
the SFN will also find what they need. (Long is ahead of Short.)
 
On Fri, 29 Aug 2008 14:00:03 -0500, MickeyF <> wrote:


>Do you really still have tools that need the SFN path? I can't imagine
>anything needing it now. The only ones I could imagine that would need
>it would be the ones that also only ran in 16-bit, using NTVDM, and
>those don't even work on Vista any more (as I understand it, not being a
>Vista user). Does anything really break if you completely remove the
>SFN from the path?
>
>As an aside to Rex, why would the SFN have been placed in the path in
>the first place? Or are we dealing with some strange environment of
>Greg's, where this would not be seen normally?
>
I you're using NTFS and Vista has

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation

you can set it to (REG_DWORD) 1 and go a long way toward never having to deal
with 8dot3 names again.
 
Do you really still have tools that need the SFN path? I can't imagine
anything needing it now. The only ones I could imagine that would need
it would be the ones that also only ran in 16-bit, using NTVDM, and
those don't even work on Vista any more (as I understand it, not being a
Vista user). Does anything really break if you completely remove the
SFN from the path?

As an aside to Rex, why would the SFN have been placed in the path in
the first place? Or are we dealing with some strange environment of
Greg's, where this would not be seen normally?

________________________________

Good questions.
I have a new, clean Vista machine that has only had version 9.02 ever installed on it. As far as the question about SFN, I don't know if I have other tools that need it because I can't see the source code for 4NT. What I DO know is that the installer put the SFN into my PATH, so I kind of have to assume that it needs it that way for some reason.

I suppose I could remove it, but if I do.......when I do know for sure that nothing really breaks?

I hope I have detailed this well enough for the developers to look at this.
Thanks,

Greg
 
One thing I would do is to scan my registry for the SFN string. If you
find it, attempt to determine why it's there.

I would also consider just removing it from the system path, and then
see what, if anything, breaks. My guess is nothing.

________________________________

From: Greg Wells [mailto:]
Sent: Friday, August 29, 2008 2:52 PM
To: Mickey Ferguson
Subject: RE: [Support-t-416] Re: 4NT 9.02 _shell internal variable

Do you really still have tools that need the SFN
path? I can't imagine
anything needing it now. The only ones I could imagine that would need
it would be the ones that also only ran in 16-bit, using NTVDM, and
those don't even work on Vista any more (as I understand it, not being a
Vista user). Does anything really break if you completely remove the
SFN from the path?

As an aside to Rex, why would the SFN have been placed in the path in
the first place? Or are we dealing with some strange environment of
Greg's, where this would not be seen normally?

________________________________

Good questions.
I have a new, clean Vista machine that has only had version 9.02 ever
installed on it. As far as the question about SFN, I don't know if I
have other tools that need it because I can't see the source code for
4NT. What I DO know is that the installer put the SFN into my PATH, so I
kind of have to assume that it needs it that way for some reason.

I suppose I could remove it, but if I do.......when I do know for sure
that nothing really breaks?

I hope I have detailed this well enough for the developers to look at
this.
Thanks,

Greg
 
It's definitely not 4NT / TCC / TCMD doing it. It's possible there's something in the Windows Installer causing it, but I can't reproduce it here (tried it on three Vista machines), and nobody else has ever reported it. So I suspect it's an individual configuration issue.

Rex Conn
JP Software

As an aside to Rex, why would the SFN have been placed in the path in
the first place? Or are we dealing with some strange environment of
Greg's, where this would not be seen normally?
 
rconn wrote:


> It's definitely not 4NT / TCC / TCMD doing it. It's possible there's
> something in the Windows Installer causing it, but I can't reproduce
> it here (tried it on three Vista machines), and nobody else has ever
> reported it. So I suspect it's an individual configuration issue.

But shouldn't TCC / 4NT set the correct shell level nonetheless even
with a SFN path only?

Mit freundlichem Gruß,

Klaus Meinhard
 
There is no such thing as a "shell level" in Windows; that's an obsolete concept that you're carrying over from DOS. I added a hack to return a useless number in %_shell because a few users weren't ready to let go of the idea. This just compares the name of the process that started the current TCC session to see if it's the same as the current session's name. It has no meaning, nor is it useful in any way.

If you're also carrying over the obsolete SFN names from DOS, it won't match an LFN name. I do not consider this to be a bug, so I have no plans to change it.

Rex Conn
JP Software
----- Original Message -----
From: K_Meinhard
To: [email protected]
Sent: Saturday, August 30, 2008 10:36 AM
Subject: RE: [Support-t-416] Re: 4NT 9.02 _shell internal variable


rconn wrote:



Quote:
> It's definitely not 4NT / TCC / TCMD doing it. It's possible there's
> something in the Windows Installer causing it, but I can't reproduce
> it here (tried it on three Vista machines), and nobody else has ever
> reported it. So I suspect it's an individual configuration issue.

But shouldn't TCC / 4NT set the correct shell level nonetheless even
with a SFN path only?

Mit freundlichem Gruß,

Klaus Meinhard
 
On Sat 30-Aug-08 10:54am -0600, rconn wrote:

.> There is no such thing as a "shell level" in Windows;
.> that's an obsolete concept that you're carrying over from
.> DOS. I added a hack to return a useless number in %_shell
.> because a few users weren't ready to let go of the idea.
.> This just compares the name of the process that started
.> the current TCC session to see if it's the same as the
.> current session's name. It has no meaning, nor is it
.> useful in any way.

It used to be meaningful when we had just 4nt. If _shell was zero,
the shell was primary - we knew it didn't inherit the environment and
our constants had to be restored.

See: help shell (what does TC mean - TCMD or TCC or either)?

Now we have both 4nt and tcc (and 4nt can actually mean tcc). To make
things a little more rational, it would be nice if _shell should only
be set to zero if the process starting it was not a process named 4nt
or tcc.

--
Best regards,
Bill
4nt 8.02.106 / tcc 9.02.151 cp 2.11.32 on xp pro sp3
 
I don't much care about _SHELL, but this discussion raise a few questions.

The glossary's definitions of "Primary" and "Secondary" shells seem to be
something out of an MSDOS manual and totally inappropriate today. If the
distinction is meaningful, what does it mean and does the distinction have
anything to do with _SHELL?

Are [Secondary] inifile sections ever read? If so, what are all the
circumstances under which they're read (and all the circumstances under which
they're not read)?

What are all the circumstances under which an instance will inherit current
options (e.g., SETDOS) from another instance and what are the circumstances
under which an instance will get all its settings from an inifile?
 
Rex,


> There is no such thing as a "shell level" in Windows; that's an
> obsolete concept that you're carrying over from DOS. I added a hack
> to return a useless number in %_shell because a few users weren't
> ready to let go of the idea. This just compares the name of the
> process that started the current TCC session to see if it's the same
> as the current session's name. It has no meaning, nor is it useful
> in any way.
>
> If you're also carrying over the obsolete SFN names from DOS, it
> won't match an LFN name. I do not consider this to be a bug, so I
> have no plans to change it.

Please note that it wasn't my problem with shell numbering. Greg Wells
was the original poster.

For him, it seems that the TC installer added a SFN path to the TC
directory, and TCC /4NT doesn't set shell level when started over a SFN
path. Nothing about any of us carrying SFN paths over from DOS.

My opinion in this matter is simple: if its there, it should work,
otherwise remove it.

Mit freundlichem Gruß,

Klaus Meinhard
 
K_Meinhard wrote:
| Please note that it wasn't my problem with shell numbering. Greg Wells
| was the original poster.
|
| For him, it seems that the TC installer added a SFN path to the TC
| directory, and TCC /4NT doesn't set shell level when started over a
| SFN path. Nothing about any of us carrying SFN paths over from DOS.
|
| My opinion in this matter is simple: if its there, it should work,
| otherwise remove it.

I disagree. Removing anything that has no meaning in the current version,
but was meaningful in prior versions would cause failure of existing batch
programs designed for the earlier versions.

Regarding _shell, I have not used it for years.

An internal variable to indicate whether or not exiting the current shell
would result in destruction of its window would be useful.

I would like to know the answer to Vince's question about the inheritance
rules applicable to the different versions of JPsoft command processors as
they apply to new instances

- created from the OS (using desktop or quick launch shortcuts, RUN dialog,
etc)
- created from a JPsoft shell using the START command (new window)
- created from a JPsoft shell without using the START command (same window)
- created from another program running in the window of a JPsoft shell by
calling the ANSI-C "system()" function

--
Steve
 
Simple answer to the "inheritance" question (which is also completely meaningless in Windows, since Windows has no concept of inheritance per se).

If TCC was started by a parent TCC shell, then _shell is incremented. In any other case, it will not be.

If TCC detects a shared memory area (that will be created by the first TCC instance), it will inherit the .INI directives from that shell. This does not make it a "child" shell, just simplifies (and speeds up) subsequent shell initialization.

The obsolete [Secondary] section (another DOS leftover) will be read in the above instance (shared memory detected). It has nothing to do with _shell.

The glossary is obsolete and I would have removed it a couple of versions ago -- but Steve complained so much that I left it in for now. It is ^not* being updated, and since that seems to cause a disturbance now I'll go ahead and remove it permanently.

Rex Conn
JP Software

----- Original Message -----
From: vefatica
To: [email protected]
Sent: Saturday, August 30, 2008 3:33 PM
Subject: RE: [Support-t-416] 4NT 9.02 _shell internal variable


I don't much care about _SHELL, but this discussion raise a few questions.

The glossary's definitions of "Primary" and "Secondary" shells seem to be
something out of an MSDOS manual and totally inappropriate today. If the
distinction is meaningful, what does it mean and does the distinction have
anything to do with _SHELL?

Are [Secondary] inifile sections ever read? If so, what are all the
circumstances under which they're read (and all the circumstances under which
they're not read)?

What are all the circumstances under which an instance will inherit current
options (e.g., SETDOS) from another instance and what are the circumstances
under which an instance will get all its settings from an inifile?
 
> For him, it seems that the TC installer added a SFN path to the TC
> directory, and TCC /4NT doesn't set shell level when started over a SFN
> path. Nothing about any of us carrying SFN paths over from DOS.

There's no evidence that the TCMD installer did it, just a possibility that Windows Installer decided to do it on his system for some unknown reason.

The installer apparently has never done that on anybody else's system. It's certainly not reproducible here, there is nothing in the TCMD installer code that would do that.

So the question here is whether I should add code for a hypothetical case which may happen on one system, in order to more closely model an obsolete variable which doesn't actually serve any purpose. Thus far, I don't see the advantage.

Rex Conn
JP Software
 
> An internal variable to indicate whether or not exiting
> the current shell would result in destruction of its
> window would be useful.

I'm a little dubious about the usefulness, but you can do that with trivial UDF. (I think that one of the plugins already does this.)


> - created from the OS (using desktop or quick launch shortcuts,
> - created from a JPsoft shell without using the START command
> (same window)
> - created from another program running in the window of a JPsoft
> shell by calling the ANSI-C "system()" function

See my answer to Vince -- that's all irrelevant. The only thing that matters is whether there's an existing TCC shell that created the shared memory for the .INI inheritance.

Rex Conn
JP Software
 
On Sun, 31 Aug 2008 11:08:39 -0500, rconn <> wrote:


>If TCC detects a shared memory area (that will be created by the first TCC instance), it will inherit the .INI directives from that shell. This does not make it a "child" shell, just simplifies (and speeds up) subsequent shell initialization.

That shared memory is "by console" ... right? ... sessions started in another
console (START, shortcut, et c.) get their own settings. It seems to be that
way and that seems good.

I said before I don't use _SHELL but a reasonable definition might be "(the
number of times I must EXIT before the console disappears) minus 1". Perhaps
it's actually that way now.
 
On Sun 31-Aug-08 12:54pm -0600, vefatica wrote:

.> I said before I don't use _SHELL but a reasonable
.> definition might be "(the number of times I must EXIT
.> before the console disappears) minus 1". Perhaps it's
.> actually that way now.

[Note: herein 4nt is 8.02.106 and tcc is 9.02.151.]

It is not. For example, suppost I'm in 4nt (my only 4nt or
tcc session) and type:

start c:\util\tcmd9\tcc

This opens a new 4nt console and starts tcc. The value of
_shell in that tcc is 0. It takes two exits to close that
window.

Of course if I had started as usual with:

start /c c:\util\tcmd9\tcc

I would still have 3 sessions (the second 4nt would
be transient) and one exit in tcc would close tcc, the
transient 4nt and the window.

--
Best regards,
Bill
4nt 8.02.106 / tcmd 9.02.151 cp 2.11.32 on xp pro sp3
 
On Sun, 31 Aug 2008 15:25:01 -0500, BillMc <> wrote:


>For example, suppost I'm in 4nt (my only 4nt or
>tcc session) and type:
>
> start c:\util\tcmd9\tcc
>
>This opens a new 4nt console and starts tcc. The value of
>_shell in that tcc is 0. It takes two exits to close that
>window.

That's bizarre. Here, that's a brand new instance (of 4NT, TCC, CMD, whatever);
it takes one EXIT to close it. Is "start" an alias for you? START should only
start a new instance of the current command processor when used with an internal
command.
 
On Sun 31-Aug-08 4:24pm -0600, vefatica wrote:
.> On Sun, 31 Aug 2008 15:25:01 -0500, BillMc <> wrote:

.>> For example, suppost I'm in 4nt (my only 4nt or tcc
.>> session) and type:
.>>
.>> start c:\util\tcmd9\tcc
.>>
.>> This opens a new 4nt console and starts tcc. The value
.>> of _shell in that tcc is 0. It takes two exits to close
.>> that window.

.> That's bizarre. Here, that's a brand new instance (of
.> 4NT, TCC, CMD, whatever); it takes one EXIT to close it.
.> Is "start" an alias for you? START should only start a
.> new instance of the current command processor when used
.> with an internal command.

No, `start' is not an alias, but I actually execute:

start tcc

where `tcc' IS an alias.

alias tcc=`myprompt9&c:\util\tcmd9\tcc&myprompt`

That solves the mini mystery :-)

--
Best regards,
Bill
4nt 8.02.106 / tcmd 9.02.151 cp 2.11.32 on xp pro sp3
 
rconn wrote:


> So the question here is whether I should add code for a hypothetical
> case which may happen on one system, in order to more closely model
> an obsolete variable which doesn't actually serve any purpose. Thus
> far, I don't see the advantage.

The main advantage may be what Steve has already outlined: compatibility
for older batches, and an indicator for how many times you have to EXIT
before the console window closes.

Note that in the original scenario (SFN path to TCMD, CD is outside TCMD
dir), each invocation of TCC / 4NT starts a new instance of TCMD in the
same console window, not another console window (or tab in TCMD). You
have to exit each new shell before the window closes.

My feeling is that %_shell should correctly display this "shell-level"
with _any_ technically correct path (it works as expected withg a LFN
path). A user might change the path for legacy applications. The fact
that it has come up the first time now doesn't mean it won't do so
again.

I have no personal preference here. If it is too much work to correct
this, delete %_shell altogether or document the LFN limitation.

Mit freundlichem Gruß,

Klaus Meinhard
 
It's definitely not 4NT / TCC / TCMD doing it. It's possible there's something in the Windows Installer causing it, but I can't reproduce it here (tried it on three Vista machines), and nobody else has ever reported it. So I suspect it's an individual configuration issue.

Rex Conn
JP Software

As an aside to Rex, why would the SFN have been placed in the path in
the first place? Or are we dealing with some strange environment of
Greg's, where this would not be seen normally?


Thanks, Rex. I feel much more confident now that I can just remove the SFN from my Path.

Greg
 

Similar threads

Back
Top