LB Booster
Programming >> Liberty BASIC language >> CommandLine$ oddity http://lbb.conforums.com/index.cgi?board=lblang&action=display&num=1418143043 CommandLine$ oddity
Post by Richard Russell on Dec 9th, 2014, 3:37pm
I'm getting confusing results from LB 4.04 when using the CommandLine$ variable and I wonder if anybody can shed some light. Firstly I created the following program:
Code:
print CommandLine$
wait
I compiled this in LBB to the executable commandlinetest.exe and then tried running it using Start... Run... and from a command prompt:
From Start... Run... Open: commandlinetest red yellow blue opened a window containing red yellow blue
From a command prompt: >commandlinetest red yellow blue opened a window containing red yellow blue
I next created commandlinetest.tkn in LB 4.04 and copied run404.exe to commandlinetest.exe. Repeating the above tests:
From Start... Run... Open: commandlinetest red yellow blue opened a window containing red yellow blue
So far so ordinary, but:
From a command prompt: >commandlinetest red yellow blue opened a window containing commandlinetest red yellow blue
What? Surely using Start... Run... must give the same results as executing the program directly from a command prompt (I wouldn't know how to make them different if I wanted to) but it seems that with LB 4.04 they are different!
Am I going mad or is this a bug in LB? It would make it awkward to write a program which takes command-line parameters and may be run using both methods.
Richard.
Re: CommandLine$ oddity
Post by RobM on Dec 10th, 2014, 11:25pm
That is strange.
How does Windows send the command line to a program? (meaning how is it structured) Is it like a DLL call where the parameters are sometimes separated by a double chr$(0)?
Either way it would seem Windows is sending "commandlinetest" along with the regular command line variables.
Re: CommandLine$ oddity
Post by Richard Russell on Dec 11th, 2014, 4:23pm
How does Windows send the command line to a program?
It is passed as the third parameter of WinMain, the 'C' prototype of which is as follows:
Code:
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
PSTR szCmdLine, int iCmdShow)
szCmdLine is a NUL-terminated string containing the command line 'tail', i.e. any parameters, which is what LBB copies into CommandLine$.
It's also possible to retrieve the command line using the GetCommandLine API, which gives you the full command line (including the executable name at the beginning).
But, crucially, both methods give consistent results whether the program is run from a command prompt or from Start... Run... It's almost as though LB is using szCmdLine when executed from Start.. Run... and GetCommandLine when executed from a command prompt, but that makes no sense (and, anyway, how does it know?).
Richard. Re: CommandLine$ oddity
Post by RobM on Dec 11th, 2014, 6:21pm
So LB must be using GetCommandLine but that does really explain why there would be a difference.
Either way, this is probably something that is done behind the scenes in Smalltalk and Carl wouldn't be able to fix it.
Re: CommandLine$ oddity
Post by Richard Russell on Dec 11th, 2014, 9:36pm
Either way, this is probably something that is done behind the scenes in Smalltalk and Carl wouldn't be able to fix it.
I see there's currently a thread at the LB Community Forum which indicates that the problems with CommandLine$ go far deeper than I realised. Even when consistently run from a command prompt the contents of the variable depend on things like whether you enclose the program name in quotes or not!
If the issue is a fault in Smalltalk Carl should be able to workaround it by calling the GetCommandLine API himself (thereby bypassing Smalltalk's command line processing) and parsing it to return the wanted command 'tail' - which basically involves removing the initial (possibly quoted) path/filename of the executable.