Possible Bug? Launching 4nt.exe Goes Hairwire

[noahcoad]

Possible Bug? Launching 4nt.exe Goes Haywire

I'm running on a completely new WinXP SP3 image trying to launch 4nt.exe v9.02.154 by this command line:
\\noahc-sys\tools\batch\GrabTools.bat\..\4NTBootStrapper.bat\..\..\tcmd\4nt.exe

It is a valid command syntax, but 4nt takes awhile to load then goes wacky and loads itself many times. If you specify /c <BATCHFILE>then 4nt spits out other strange text. Launching with a more direct path like \\noahc-sys\tools\tcmd\4nt.exe works just fine. But the syntax above is important to support when launching 4nt from cmd.exe and chaining batch files together, for example %0\..\..\tmcd\4nt.exe.

Is this a bug? Could it please get fixed? thanks, I'm a big fan of the product. http://msmvps.com/blogs/coad/archive/2005/02/19/36473.aspx

-Noah Coad, Microsoft Visual Studio Program Manager

(p.s. there are no spaces in that top command, even though the forum site makes it look like there is a space in .bat, but mixed quoted versions are also valid and should be supported, like "\\noahc-sys\tools\batch\GrabTools.bat"\..\4NTBootStrapper.bat\"..\..\tcmd\4nt.exe")

 

[samintz]

Noah,

That has got to be the weirdest syntax I've ever seen. What are you
trying to do? Why the second instance of 4nt.exe in parentheses?

When you chain a batch file, why can't you just CALL your next batch file
or invoke the script directly? Why do you need to specify the executable
again?

-Scott

noahcoad <> wrote on 07/14/2009 05:35:28 PM:

> I'm running on a completely new WinXP SP3 image trying to launch
> 4nt.exe v9.02.154 by this command line:
> \\noahc-sys\tools\batch\GrabTools.btm\..\4NTBootStrapper.bat\..\..
> \tcmd\4nt.exe (file://\\noahc-sys\tools\batch\GrabTools.btm\..
> \4NTBootStrapper.bat\..\..\tcmd\4nt.exe)
>
> It is a valid command syntax, but 4nt takes awhile to load then goes
> hairwire and loads itself many times. If you specify /c <batchfile>
> then 4nt spits out other strange text. Launching with a more direct
> path like \\noahc-sys\tools\tcmd\4nt.exe (file://\\noahc-
> sys\tools\tcmd\4nt.exe) works just fine. But the syntax above is
> important to support when launching 4nt from cmd.exe and chaining
> batch files together, for example %0\..\..\tmcd\4nt.exe.
>
> Is this a bug? Could it please get fixed? thanks, I'm a big fan of
> the product. http://msmvps.com/blogs/coad/archive/2005/02/19/36473.aspx
>
> -Noah Coad, Microsoft Visual Studio Program Manager
>
>
>
>

 

[noahcoad]

I find it to be a common pattern that I'm calling a batch file on a remote system from computers without 4nt installed, so the .bat is launched with cmd.exe, the batch checks to see if it is in a 4nt environment by launching my '4nt boot loader' which locates and runs 4nt then calls back to the original batch so that is it running under 4nt. One of the things I'm using this for is to set up Hyper-V and Virtual PC images with base OS installations on them, so I keep 4nt on a central network share.

In this case, the first batch file does something like this at the very beginning that works fine for cmd.exe:

if %$==$ (
call %0\..\4NTBootStrapper.bat %0 %*
goto end )

The 4NTBootStrapper.bat excerpt looks like this:

set tccpath=%0\..\..\tcmd\4nt.exe
if exist "%tccpath%" %tccpath% /c %*

Thus effectively calling back to the original batch file after 4nt is loaded. What ends up getting called on the command line is below. It is a valid path and cmd.exe resolves it just fine, but 4nt then takes a long time to load and goes haywire.

The reason for using %0 is that if %~dp0 is used on a UNC share, cmd.exe takes quite a while to resolve. The case where you get mixed quotes (which are valid syntax) is cmd.exe puts quotes around %0 for network shares or when the first batch file being called has a space in the name or path. The reason the directory can't just be changed first is that cmd.exe doesn't support changing the current directory to a network path, so the full path to the 4NTBootLoader.bat must be specified, and same with the path to 4nt.exe

Noah,

That has got to be the weirdest syntax I've ever seen. What are you
trying to do? Why the second instance of 4nt.exe in parentheses?

When you chain a batch file, why can't you just CALL your next batch file
or invoke the script directly? Why do you need to specify the executable
again?

-Scott

noahcoad <> wrote on 07/14/2009 05:35:28 PM:

 

[samintz]

If 4NT is stored on a common network share then you should know ahead of
time what its absolute path is. And the first line of your script can
just relaunch under 4NT using that path.

For example:
if NOT "4"=="%@eval[2+2]%" (
echo Relaunching under TCC...
tcc /c %0
goto :EOF )
echo Howdy from %ComSpec
...rest of batch script

The COMSPEC environment variable will be set to the path of TCC. Why do
you need the overly complicated mechanism you are using?

-Scott



noahcoad <> wrote on 07/15/2009 03:28:37 AM:

> I find it to be a common pattern that I'm calling a batch file on a
> remote system from computers without 4nt installed, so the .bat is
> launched with cmd.exe, the batch checks to see if it is in a 4nt
> environment by launching my '4nt boot loader' which locates and runs
> 4nt then calls back to the original batch so that is it running
> under 4nt. One of the things I'm using this for is to set up Hyper-
> V and Virtual PC images with base OS installations on them, so I
> keep 4nt on a central network share.
>
> In this case, the first batch file does something like this at the
> very beginning that works fine for cmd.exe:
>
> if %$==$ (
> call %0\..\4NTBootStrapper.bat %0 %*
> goto end )
>
> The 4NTBootStrapper.bat excerpt looks like this:
>
> set tccpath=%0\..\..\tcmd\4nt.exe
> if exist "%tccpath%" %tccpath% /c %*
>
> Thus effectively calling back to the original batch file after 4nt
> is loaded. What ends up getting called on the command line is
> below. It is a valid path and cmd.exe resolves it just fine, but
> 4nt then takes a long time to load and goes haywire.
>
> The reason for using %0 is that if %~dp0 is used on a UNC share,
> cmd.exe takes quite a while to resolve. The case where you get
> mixed quotes (which are valid syntax) is cmd.exe puts quotes around
> %0 for network shares or when the first batch file being called has
> a space in the name or path.
>
>
>
> ---Quote (Originally by samintz)---
> Noah,
>
> That has got to be the weirdest syntax I've ever seen. What are you
> trying to do? Why the second instance of 4nt.exe in parentheses?
>
> When you chain a batch file, why can't you just CALL your next batch

file

> or invoke the script directly? Why do you need to specify the

executable

> again?
>
> -Scott
>
> noahcoad <> wrote on 07/14/2009 05:35:28 PM:
> ---End Quote---
>
>
>

 

[noahcoad]

TCC is known to be in a relative path to the bootstrap batch, but it is not in a single permanent location. It is a network of laptops that are in the field. One system is used to setup several others, then that is taken to another network, or the original isn't available so one of the children becomes the new source.

Still it goes back to my point that TCC has provided excellent compatibility with cmd.exe so shouldn't TCC support launching using acceptable cmd.exe syntax?

If 4NT is stored on a common network share then you should know ahead of
time what its absolute path is. And the first line of your script can
just relaunch under 4NT using that path.

For example:
if NOT "4"=="%@eval[2+2]%" (
echo Relaunching under TCC...
tcc /c %0
goto :EOF )
echo Howdy from %ComSpec
...rest of batch script

The COMSPEC environment variable will be set to the path of TCC. Why do
you need the overly complicated mechanism you are using?

-Scott



noahcoad <> wrote on 07/15/2009 03:28:37 AM:



file


executable

 

[samintz]

I just went to the forum and re-read your original post there. Apparently, an extra reference to file: inside of parens got added which prompted my original "weird syntax" comment. You can see it in the quote of my reply.

You are invoking a BAT file, then appending a relative path to the %0 parameter. So the final name is a combination of subdirs and file names.

"\\server\share\sub1\mybat.BAT\..\NewBat.BAT" is valid syntax in CMD even though mybat.BAT is a file name and not a subdir name?

That weird syntax works correctly when not using UNC's. I.e. C:\TC10\foo.bat will work correctly. But "\\usmaysamintzl2\c$\TC10\foo.bat" does not.

I tested with this simple script:

if NOT "4"=="%@eval[2+2]%" (echo launching... & %0\..\tcc /c %0 & goto :EOF)
echo Howdy from %ComSpec%

When launched from a UNC, TCC ignores the /C switch and keeps launching copies of itself. According to ProcessExplorer, the command line is:

[LEFT]\\usmaysamintzl2\c$\tc10\foo.bat\..\tcc /c \\usmaysamintzl2\c$\tc10\foo.bat
[/LEFT]

-Scott

 

[samintz]

The anomaly can be seen even more simply by:

\\usmaysamintzl2\c$\tc10\foo.bat\..\tcc

It causes TCC to be repeatedly launched.

-Scott

samintz <> wrote on 07/15/2009 05:14:39 PM:

> I just went to the forum and re-read your original post there.
> Apparently, an extra reference to file: inside of parens got added
> which prompted my original "weird syntax" comment. You can see it
> in the quote of my reply.
>
> You are invoking a BAT file, then appending a relative path to the %
> 0 parameter. So the final name is a combination of subdirs and file

names.

>
> "\\server\share\sub1\mybat.BAT\..\NewBat.BAT" is valid syntax in CMD
> even though mybat.BAT is a file name and not a subdir name?
>
> That weird syntax works correctly when not using UNC's. I.e. C:
> \TC10\foo.bat will work correctly. But
> "\\usmaysamintzl2\c$\TC10\foo.bat" does not.
>
> I tested with this simple script:
>
> Code:
> ---------
> if NOT "4"=="%@eval[2+2]%" (echo launching... & %0\..\tcc /c %0 & goto

:EOF)

> echo Howdy from %ComSpec%
> ---------
> When launched from a UNC, TCC ignores the /C switch and keeps
> launching copies of itself. According to ProcessExplorer, the
> command line is:
>
>
> Code:
> ---------
> \\usmaysamintzl2\c$\tc10\foo.bat\..\tcc /c

\\usmaysamintzl2\c$\tc10\foo.bat

> ---------
> -Scott
>
>
>
>

 

[noahcoad]

Yup, you see the problem clearly, so what can be done to fix it? Is there a way to file a bug report?

The anomaly can be seen even more simply by:

\\usmaysamintzl2\c$\tc10\foo.bat\..\tcc

It causes TCC to be repeatedly launched.

-Scott

samintz <> wrote on 07/15/2009 05:14:39 PM:



names.


:EOF)


\\usmaysamintzl2\c$\tc10\foo.bat

 

[samintz]

Just reporting it here does that. It wouldn't surprise me if Rex releases
a fix in a day or two.

In the meantime, use %~dP0 to get the base drive and path. It may be slow
for you but at least it doesn't blow up.

%0\..\4NTBootStrapper.bat\..\..\tcmd\4nt.exe

becomes:

%~dP0..\tcmd\4nt..exe

-Scott

noahcoad <> wrote on 07/15/2009 06:41:02 PM:

> Yup, you see the problem clearly, so what can be done to fix it? Is
> there a way to file a bug report?
>
>
>
> ---Quote (Originally by samintz)---
> The anomaly can be seen even more simply by:
>
> \\usmaysamintzl2\c$\tc10\foo.bat\..\tcc
>
> It causes TCC to be repeatedly launched.
>
> -Scott
>
> samintz <> wrote on 07/15/2009 05:14:39 PM:
>
>
>
> names.
>
>
> :EOF)
>
>
> \\usmaysamintzl2\c$\tc10\foo.bat
> ---End Quote---
>
>
>

 

[noahcoad]

Think the fix could be made in a v9 update? I only own v9 (and before). And using %~dP0 is VERY slow, like up to 30sec to resolve, and it has to be chained a few times too, adding up quick. Well I hope Rex gets it fixed. How would I know when it is fixed and in which build? thanks for discussion

Just reporting it here does that. It wouldn't surprise me if Rex releases
a fix in a day or two.

In the meantime, use %~dP0 to get the base drive and path. It may be slow
for you but at least it doesn't blow up.

%0\..\4NTBootStrapper.bat\..\..\tcmd\4nt.exe

becomes:

%~dP0..\tcmd\4nt..exe

-Scott

noahcoad <> wrote on 07/15/2009 06:41:02 PM:

 

[rconn]

noahcoad wrote:

> Think the fix could be made in a v9 update? I only own v9 (and before). And using %~dP0 is VERY slow, like up to 30sec to resolve, and it has to be chained a few times too, adding up quick. Well I hope Rex gets it fixed. How would I know when it is fixed and in which build? thanks for discussion

Your somewhat unusual syntax is tripping over a workaround I had to add
for a Windows bug. I'm going to have to add a workaround for the
workaround, which will probably take a day or two.

Rex Conn
JP Software