Bug: Batch File Parameters/.exe vs. .bat

Please report any bug you find.

Bug: Batch File Parameters/.exe vs. .bat

Postby metzgerron » May 12, 2012, 2:55 pm

Problem with Batch File Parameters / Command Line

There seems to be a difference in the way a native .bat file
interprets the command line parameters compared to the way
the ExeScript .exe - .bat file interprets the command line
parameters. This is easily seen when using an argument that
references a file using Relative notation, such as ..\*.*

In a native batch file, the arguments passed in %0 %1 %2 ...,
reference to the current directory.

Consider this scenario:

Current Directory: F:\Tools\ExeScript\Test
Executable Location: F:\Tools\ExeScript
Executable Name: Test.exe or Test.Bat
Work Directory: Windows temp
Command line: ..\Test.Bat ..\*.*
or Command line: ..\Test.exe ..\*.*

Suppose the trivial batch file, Test.Bat:

@rem ----- ExeScript Options Begin -----
@rem ScriptType: console,invoker
@rem DestDirectory: temp
@rem Icon: none
@rem OutputFile: F:\Tools\ExeScript\test.exe
@rem 32Bit: yes
@rem ----- ExeScript Options End -----
@echo off
echo [CmdCmdLine]=[%CmdCmdLine%]
echo [%%^0 %%*]=[%0 %*]
echo [%%^1]=[%1]
echo [%%~f^0]=[%~0]
echo [%%~x^0]=[%~x0]
echo [%%~f^1]=[%~f1]
dir "%~1"

Executed natively, or from
Project>Run source raw/uncompiled,

F:\Tools\ExeScript\Test>test.bat ..\*.*
[CmdCmdLine]=[C:\windows\system32\cmd.exe /c test.bat ..\*.*]
[%0 %*]=[test.bat ..\*.*]



Volume in drive F is REMSERVICES
Volume Serial Number is 28A0-5C58

Directory of F:\Tools\ExeScript

05/12/2012 05:45 PM <DIR> .
05/12/2012 05:45 PM <DIR> ..
03/25/2005 08:00 AM 35,840 choice.exe
05/13/2010 10:26 PM 237,392 signtool.exe
05/06/2012 03:35 PM <DIR> Test
2 File(s) 273,232 bytes
3 Dir(s) 34,632,040,448 bytes free
Press any key to continue . . .

This is what I expect.

When executing the .exe version:
F:\Tools\ExeScript\Test>test.exe ..\*.*
Unregistered demo version - for evaluation only. You must purchase the software to remove this message.
Press any key to continue.
[CmdCmdLine]=[cmd /c ""C:\Users\RMetzger\AppData\Local\Temp\test.bat" ..\*.*"]
[%0 %*]=["C:\Users\RMetzger\AppData\Local\Temp\test.bat" ..\*.*]



Volume in drive C is TI105847W0F
Volume Serial Number is D674-17CD

Directory of C:\Users\RMetzger\AppData\Local

05/12/2012 04:19 PM <DIR> .
05/12/2012 04:19 PM <DIR> ..
04/21/2012 07:56 AM <DIR> Adobe
04/24/2012 03:10 PM <DIR> AnVir
05/07/2012 04:10 PM <DIR> CrashDumps
04/27/2012 03:26 PM <DIR> ElevatedDiagnostics
04/21/2012 09:52 AM 88,288 GDIPFONTCACHEV1.DAT
04/28/2012 08:37 AM <DIR> Microsoft
04/20/2012 05:31 PM <DIR> Microsoft Games
04/20/2012 04:35 PM <DIR> Mozilla
05/12/2012 12:14 AM <DIR> QBFC
05/12/2012 06:17 PM <DIR> Temp
04/27/2012 04:32 PM <DIR> VirtualStore
1 File(s) 88,288 bytes
12 Dir(s) 245,165,117,440 bytes free
Press any key to continue . . .

%~x0=.bat not .exe
..\*.* =C:\Users\RMetzger\AppData\Local not F:\Tools
%~f0=C:\Users\RMetzger\AppData\Local\Temp\test.bat not test.exe
%~f1=C:\Users\RMetzger\AppData\Local\. not F:\Tools\ExeScript\.
Note the differences in the Dir command results.

Clearly, the .exe version makes the Current Directory the
one in which it was extracted and subsequently run.
Relative references refer to the extraction directory.
This is not the same as the batch file natively executes.

My code for utilities I am writing work fine as a pure batch
execution, but fail when running as a .exe when compiled by
ExeScript Editor.

I need to get the native batch versions of these variables
running under the compiled batch executable.

Any Suggestions?


Ron Metzger
Posts: 2
Joined: May 9, 2012, 6:07 pm

Re: Bug: Batch File Parameters/.exe vs. .bat

Postby Support » May 13, 2012, 2:19 am

Dear Ron,

just set Work Directory=Current directory in ExeScript options.
Posts: 326
Joined: June 20, 2004, 8:27 am

Re: Bug: Batch File Parameters/.exe vs. .bat

Postby metzgerron » May 13, 2012, 1:54 pm

[quote="Support"]Dear Ron,

just set Work Directory=Current directory in ExeScript options.[/quote]

Dear Support,

Unfortunately, that is not a solution. My example above was simply a demonstration of a problem using as few variables as possible.

My intended application does not allow writing to the 'current directory.' It is read/execute Only. Second, concurrency issues would arise.

Yes, I know that ExeScript is generating a 9-digit random named .bat file and executing it, but resource files are not random, nor would there use during execution if randomly named. Oh, but wait, I can't extract the resource files in a Read Only environment.

My point is that the command line parameters are different between raw execution and the actual .exe/.bat version; with whatever work directory I choose. There should not be interpretation differences of the command line parameters as it currently occurs.

Simply put: .exe = .bat or at least should. The command line parameters do not.

I could accept minor and subtle differences, but these are glaring and unfortunately extreme enough that I cannot write code that rectifies these differences.

As it stands, changing the drive:directory during execution changes the expected execution settings. All this happens invisibly and without any easy way to diagnose. Again, raw execution doesn't do this either. The drive:directory change is a fundamental change in the premise of how the files are executed. This is not minor or subtle.

As it turns out, I have had problems choosing the Windows Temp directory as well as execution from this directory is often blocked by many security products.

My most reliable solution has been to create a random digit directory under %APPDATA%. Typically, I use "%APPDATA%\ExeScript\8RandomDigits
which I clean up at the end of execution. Seems to be the most reliable. However, this leads to the problem when specifying relative references, because it now is referencing the newly created directory instead of the [b]current directory prior to execution[/b]. This differs even when running the raw execution shell vs .exe.

When using 'Windows temp' or a specified directory, changing the drive:directory to the work directory is a change in the operational expectations in programming.

Clearly this is an architectural issue.

FYI: even though my Hide Folder profile/control panel settings shows that I have BBCode On, it remains Off. Odd, but not a big deal.

How is the beta version of this program coming?


Ron Metzger
Posts: 2
Joined: May 9, 2012, 6:07 pm

Re: Bug: Batch File Parameters/.exe vs. .bat

Postby Support » May 14, 2012, 7:59 am

Possibly the following will be helpful:

The following runtime macros are available in ExeScript:

#ES.exe.path – Full path to the executable file.
#ES.exe.name – The name of the executable file.
#ES.exe.pathname – Full path to the compiled executable file, with its name.
#ES.script.path – Full path to your current script.
#ES.script.name – The name of your current script.
#ES.script.pathname – Full path to your current script file, with its name.
#ES.res.path – Full path to the resource extraction folder.
#es.include – Includes the code of an additional (external) script in the location where #es.include is specified in the main script.

Example of use:

#es.include "myscript.vbs"
Posts: 326
Joined: June 20, 2004, 8:27 am

Return to Bugs

Who is online

Users browsing this forum: No registered users and 1 guest