I've noticed subtle differences in execing a batch file on MS Windows with or without prepending the call with the command interpreter, cmd.exe. Here's an example:
(portal_01024) 2 % cd c:/iskv/portal_01024 (portal_01024) 3 % glob * config cti dist help resource resource_cti start_portal.bat (portal_01024) 4 % exec -- start_portal.bat Unable to access jarfile c:\iskv\21c_winbk_\bin\csvstart.jar <==== batch starts, but somethings going wrong internally Das System kann den angegebenen Pfad nicht finden. (portal_01024) 6 % exec -- cmd.exe /c start_portal.bat & <==== this works the same way as if i call the batch from outside of tcl 4660 (portal_01024) 7 % exec -- [auto_execok start_portal.bat] <==== didn't help Unable to access jarfile c:\iskv\21c_winbk_\bin\csvstart.jar Das System kann den angegebenen Pfad nicht finden.
Don't know what's going on yet.
If I use auto_execok xyz.BAT, it gives back ./xyz.BAT, which makes not much sense, since Batches are always interpreted by the command interpreter, cmd.exe, on windows, and ar not executable by themselves. exec bat and exec auto_execok are basically the same and both don't work for me in all cases, since the environment of the BAT is then different than if called via cmd.exe.
Thru a simple echo and pause, I discovered the difference which leads to an error:
(portal_01024) 24 % exec -- start_portal.bat c:\iskv\PORTAL~1 <============ without cmd.exe /c, the system uses SHORT FILENAMES..... WHY????????? Druecken Sie eine beliebige Taste . . . Unable to access jarfile c:\iskv\21c_winbk_\bin\csvstart.jar Das System kann den angegebenen Pfad nicht finden. (portal_01024) 25 % exec -- cmd.exe /cstart_portal.bat c:\iskv\portal_01024 Druecken Sie eine beliebige Taste . . . (portal_01024) 26 %
Unfortunally, there's no way to retrieve a long from a short filename, so I cannot work around this...
APN Does file attribute -shortname/-longname not help ?
MHo No, as the called BAT is a Windows Batch procedure, not a tcl script. The thing is, that the called BAT sees a short filename as it's own name (%~dp0) in one case, and a long filename in normal cases. That is something that's out of the tcl scripters scope, in this case.
MHo Addition: One can simply reproduce the (I think) wrong behaviour:
1. Create a simple batch file which resides in a folder with "long file name" components (that is, subfolder names longer that 8.3) like this:
@echo (((This is the folder from where I get called: %~dp0)))
2. Execute this batch from a cmd.exe windows, this gives:
(((This is the folder from where I get called: d:\Home\Hoffmann\pgm\tcl\usr\Src\menue\batchExecTest\)))
3a. Execute the batch from within tclsh via exec, method 1 - somethings going wrong:
% exec -- ./batch1.bat (((This is the folder from where I get called: d:\Home\Hoffmann\pgm\tcl\usr\Src\menue\BATCHE~1\)))
3b. Execute the batch from within tclsh via exec, method 2 - result is correct:
% exec -- cmd.exe /cbatch1.bat (((This is the folder from where I get called: d:\Home\Hoffmann\pgm\tcl\usr\Src\menue\batchExecTest\)))
I hope it's not that command.com, the 16bit MSDOS command processor is called in case 3a.....