Menu
▾
▴
#64 Error when invoking 'blat' with legal path
I encountered the error pasted below when running 'blat' with a legal, if unusual, command line.
"C:\Program Files\NoInstallReqd\Blat"\blat.exe
Blat v3.2.17 (build : Aug 10 2016 22:32:21)
32-bit Windows, Full, Unicode
unknown error code 2 when trying to open \blat.exe
I verified that there were no non-printing characters concealed in the command line.
This was the 32-bit version and happens in both XP SP3 and Win7 SP1
At first, I was going to write that I could not see this issue when running the 64-bit version on my Windows 7 Ultimate SP1. I even tried the 32-bit version, and the Win98 32-bit version. Each of these worked as intended, but I did eventually reproduce the same message.
I recompiled the program to turn on some debugging, to have the program print to my screen what it received from the command line parser. Here are my results, and comments will follow:
C:\Users\Chip>"C:\Program Files\NoInstallReqd\Blat"\blat.exe
Blat saw the following command line options:
C:\Program Files\NoInstallReqd\Blat
0043 003A 005C 0050 0072 006F 0067 0072 0061 006D 0020 0046 0069 006C 0065 0073 005C 004E 006F 0049 006E 0073 0074 0061 006C 006C 0052 0065 0071 0064 005C 0042 006C 0061 0074 0000
\blat.exe
005C 0062 006C 0061 0074 002E 0065 0078 0065 0000
Blat v3.2.17 (build : Mar 18 2017 10:13:04)
32-bit Windows, Full, Unicode
unknown error code 2 when trying to open \blat.exe
C:\Users\Chip>"C:\Program Files\NoInstallReqd\Blat\blat.exe"
Blat saw the following command line options:
C:\Program Files\NoInstallReqd\Blat\blat.exe
0043 003A 005C 0050 0072 006F 0067 0072 0061 006D 0020 0046 0069 006C 0065 0073 005C 004E 006F 0049 006E 0073 0074 0061 006C 006C 0052 0065 0071 0064 005C 0042 006C 0061 0074 005C 0062 006C 0061 0074 002E 0065 0078 0065 0000
Blat v3.2.17 (build : Mar 18 2017 10:13:04)
32-bit Windows, Full, Unicode
Windows console utility to send mail via SMTP or post to usenet via NNTP
by P.Mendes,M.Neal,G.Vollant,T.Charron,T.Musson,H.Pesonen,A.Donchey,C.Hyde
http://www.blat.net
syntax:
Blat <filename> -to <recipient> [optional switches (see below)]</recipient></filename>
Blat -SaveSettings -f <sender email="" addy=""> -server <server addr="">
[-port <port>]</port> [-try <try>]</try> [-profile <profile>]</profile>
[-u <login id="">]</login> [-pw <password>]</password>
or
Blat -install <server addr=""> <sender's addr=""> [<try>[<port>[<profile>]]]</profile></port></try> [-q]</sender's></server></server></sender>
Blat -profile [-delete | "<default>"]</default> [profile1] [profileN] [-q]
Blat -h
C:\Users\Chip>
In the first instance, I used your exact command line with the embedded quotation mark before the backslash. The second instance moved the quotation mark to the end, following the .exe. As you can see there are two different results. Now for the explanation.
Blat is written in C++ programming language, which has its own command line parser as part of the executable preamble. This parsing of the command line occurs before the first line of Blat.cpp is given control, because a requirement by C standards is that C program entry points must be given a count of the command line arguments, what those individual arguments are, and a list of environment variables and values. What you have stumbled upon is a bug in Microsoft's Visual Studio 2010 32-bit library routines that parse the command line argument in the preamble. Apparently, the library routines stop parsing the program's path at the second quotation mark, before picking up at the following backslash to present \blat.exe as the "first" argument to be given into the C code. What I need to do is check newer versions of Visual Studio for this same bug. If Microsoft still has this problem with the latest version, I will need to develop a work-around.
In the meantime, my suggestion is to ensure the quotation mark is always after the blat.exe name.
I will keep you posted on my progress with newer Visual Studio investigation.
Chip
The problem identified with Visual Studio 2010 continues to exist with Visual Studio 2017, and seems to be a problem with 32-bit compiled code, not with 64-bit compiled code.
When I built Blat with Open Watcom compiler, I see slightly different behavior with argument passing into Blat's main() function.
I used this command line for debug purposes:
"C:\Program Files\NoInstallReqd\Blat"\blat.exe
Blat 32-bit built with Open Watcom 1.9 gave this debug output --
Blat saw the following command line options:
argv[ 0] = C:\Program Files\NoInstallReqd\Blat\blat.exe
0043 003A 005C 0050 0072 006F 0067 0072 0061 006D 0020 0046 0069 006C 0065 0073
005C 004E 006F 0049 006E 0073 0074 0061 006C 006C 0052 0065 0071 0064 005C 0042
006C 0061 0074 005C 0062 006C 0061 0074 002E 0065 0078 0065 0000
argv[ 1] = \blat.exe
005C 0062 006C 0061 0074 002E 0065 0078 0065 0000
Blat 32-bit built with Microsoft Visual Studio 2010 gave this debug output --
Blat saw the following command line options:
argv[ 0] = C:\Program Files\NoInstallReqd\Blat\
0043 003A 005C 0050 0072 006F 0067 0072 0061 006D 0020 0046 0069 006C 0065 0073
005C 004E 006F 0049 006E 0073 0074 0061 006C 006C 0052 0065 0071 0064 005C 0042
006C 0061 0074 005C 0000
argv[ 1] = blat.exe
0062 006C 0061 0074 002E 0065 0078 0065 0000
Blat 32-bit built with Microsoft Visual Studio 2017 gave the same output as when it was built with VS 2010.
If you notice, Open Watcom parsed the first parameter different than Microsoft's Visual Studio by including the program name. I have not yet tried building Blat with GNU GCC.
Although I can develop a workaround for Visual Studio, I cannot get one for Open Watcom. At least with Open Watcom, I can fix that compiler's library routines since the source is freely available.
For now, I think we are stuck with this behavior. The best solution is to always ensure the closing quotation mark is after the program's name.
Chip
Thanks for the update. Compiler bugs are always a bitch.
I've re-written the portion of my script that was causing the problem. I do most of my scripting using bash under Cygwin so slapping double-quotes around all strings is second nature. In this case, I was modifying an old .BAT file to make it more general and the d-quotes weren't really needed.
I've added a comment to the script to remind me not to do this again when using 'blat'.
Thanks for maintaining this great tool. I use it primarily for mailing small automated backup files to an archiving account.
After some thought today regarding Open Watcom behavior versus Microsoft Visual Studio, I have what might be a solution. I have reservations about it because of the possibility that I might nuke the second argument by mistake. Here are the outputs from my small changes:
The first run is for 32-bit Blat without Unicode, specifically for Windows 98 and Millenium Edition. This was compiled with Microsoft Visual Studio.
The second run is for 32-bit Blat with Unicode for Windows 2000 and newer. This was compiled with Microsoft Visual Studio.
The third run is for 64-bit Blat with Unicode. This was compiled with Microsoft Visual Studio 2017.
The last run is 32-bit Blat with Unicode, compiled with Open Watcom version 1.9.
For purposes of showing the above results, I added "-showcommandlinearguments" to force Blat to display the command line arguments it was given before anything else is done in the program. This option is not otherwise supported by the program, which stops the program from doing anything useful or harmful.
In each of the first three runs, where Blat was compiled with Visual Studio, my edit merges the first two arguments into the first one, then removes the second argument from the list for "future" processing.
In the last run, where Blat was compiled with Open Watcom, my edit removes the second argument when it determined it was the same as the end of the first argument, then the edit removes that second argument from the list for "future" processing.
As mentioned, I am leary about releasing this change. I will post this to the Yahoo! Groups for further discussion. If the concensus is to incorporate the change, then I will release version 3.2.18. Otherwise, I will disable the changes and wait on releasing a version 3.2.18 when some other issue arises.
Chip