Post by Chris Iverson on Nov 16, 2018 17:25:02 GMT -5
This is an issue that was recognized by RickH over on the JB forums(in this topic, regarding JB2.
This happens in LB v4.5.1 as well, and it is a regression from LB4.04/JB1, as the issue doesn't happen there.
LB seems to look for whatever the final backslash is on the command line, and assume that everything before that slash is part of the default directory for the TKN, instead of other parameters.
Here's a basic sample program to demonstrate the issue.
Just enough to show what CommandLine$ got passed in, and stay on the screen until closed.
Create a full application out of this, runtime files and everything, and copy it to a folder. I used C:\temp\test.exe as the app name, with the program compiled to C:\temp\test.tkn, and all of the runtime engine files there.
Open a CMD window, and navigate to the folder. Let's try a few invocations.
Results in:
As expected.
Results in
Again, also as expected.
Results in
Note the blank starting line, but I think that's normal compared to previous versions.
Results in
So, again, as expected.
So, let's specify some paths on the command-line. Say we need filenames for some reason.
Result:
Uh, oh.
Next try, let's specify the TKN manually:
Result:
Now, following this example, make a new C:|temp2 folder, and copy the test.tkn from C:\temp to C:\temp2.
And let's try to run one of those examples again.
Result:
So, that one works, but only if we copy the TKN to a different folder entirely.
Let's try the second one again.
Result:
Still fails.
Let's try a different "resource" file path. Relative path, instead of full path.
Result: Error.
Let's try specifying the TKN file.
Result: Error.
Let's do the copy the TKN thing again.
Run first example.
Result:
Ok, so that works now. Let's try the second example.
Result: Error.
Still an error. Well, remember what I mentioned earlier about how it now assumes that everything before the last backslash is part of the path?
It doesn't think that C:\temp\ is the path. It thinks that "C:\temp\test.tkn sub\" is the path.
This can be proven. Let's create a folder in our temp directory named "test.tkn sub".
NOTE THE QUOTES AROUND THE FOLDER NAME. Those are necessary to prevent the commands from thinking that 'sub' is a different argument.
Now, rerun that last example.
Result:
As you can see, it finally worked, thus proving how backslashes are treated.
Now, Windows DOES actually provide a way to make separate arguments on a commandline explicit: You quote them. By quoting the TKN path, it should know to stop the path there.
We'll also use a different subfolder name, to be sure we're not using one previously prepped.
Result:
Wait, what?
Let's try adding a third parameter
Yup. By quoting the TKN path, the program launches, but then LB throws away the rest of the command-line.
This happens in LB v4.5.1 as well, and it is a regression from LB4.04/JB1, as the issue doesn't happen there.
LB seems to look for whatever the final backslash is on the command line, and assume that everything before that slash is part of the default directory for the TKN, instead of other parameters.
Here's a basic sample program to demonstrate the issue.
print CommandLine$
print "test."
input a
Just enough to show what CommandLine$ got passed in, and stay on the screen until closed.
Create a full application out of this, runtime files and everything, and copy it to a folder. I used C:\temp\test.exe as the app name, with the program compiled to C:\temp\test.tkn, and all of the runtime engine files there.
Open a CMD window, and navigate to the folder. Let's try a few invocations.
C:\temp>test.exe
Results in:
test.exe
test.
?
As expected.
C:\temp>test.exe blah
Results in
test.exe blah
test.
?
Again, also as expected.
C:\temp>test.exe C:\temp\test.tkn
Results in
test.
?
Note the blank starting line, but I think that's normal compared to previous versions.
C:\temp>test.exe C:\temp\test.tkn blah
Results in
test.exe C:\temp\test.tkn blah
test.
?
So, again, as expected.
So, let's specify some paths on the command-line. Say we need filenames for some reason.
C:\temp>test.exe C:\temp2\bar
Result:
---------------------------
Application load aborted
---------------------------
File not found: test.TKN
---------------------------
OK
---------------------------
Uh, oh.
Next try, let's specify the TKN manually:
C:\temp>test.exe C:\temp\test.tkn C:\temp2\bar
Result:
---------------------------
Application load aborted
---------------------------
File not found: test.TKN
---------------------------
OK
---------------------------
Now, following this example, make a new C:|temp2 folder, and copy the test.tkn from C:\temp to C:\temp2.
C:\temp>mkdir C:\temp2
C:\temp>copy C:\temp\test.tkn C:\temp2
And let's try to run one of those examples again.
test.exe C:\temp2\bar
Result:
test.exe C:\temp2\bar
test.
?
So, that one works, but only if we copy the TKN to a different folder entirely.
Let's try the second one again.
C:\temp>test.exe C:\temp\test.tkn C:\temp2\bar
Result:
---------------------------
Application load aborted
---------------------------
File not found: test.TKN
---------------------------
OK
---------------------------
Still fails.
Let's try a different "resource" file path. Relative path, instead of full path.
C:\temp>test.exe sub\bar
Result: Error.
Let's try specifying the TKN file.
C:\temp>test.exe C:\temp\test.tkn sub\bar
Result: Error.
Let's do the copy the TKN thing again.
C:\temp>mkdir sub
C:\temp>copy test.tkn sub
Run first example.
C:\temp>test.exe sub\bar
Result:
test.exe sub\bar
test.
?
Ok, so that works now. Let's try the second example.
C:\temp>test.exe C:\temp\test.tkn sub\bar
Result: Error.
Still an error. Well, remember what I mentioned earlier about how it now assumes that everything before the last backslash is part of the path?
It doesn't think that C:\temp\ is the path. It thinks that "C:\temp\test.tkn sub\" is the path.
This can be proven. Let's create a folder in our temp directory named "test.tkn sub".
C:\temp>mkdir "test.tkn sub"
C:\temp>copy test.tkn "test.tkn sub"
NOTE THE QUOTES AROUND THE FOLDER NAME. Those are necessary to prevent the commands from thinking that 'sub' is a different argument.
Now, rerun that last example.
C:\temp>test.exe C:\temp\test.tkn sub\bar
Result:
test.exe C:\temp\test.tkn sub\bar
test.
?
As you can see, it finally worked, thus proving how backslashes are treated.
Now, Windows DOES actually provide a way to make separate arguments on a commandline explicit: You quote them. By quoting the TKN path, it should know to stop the path there.
We'll also use a different subfolder name, to be sure we're not using one previously prepped.
C:\temp>test.exe "C:\temp\test.tkn" sub2\bar
Result:
test.
?
Wait, what?
Let's try adding a third parameter
C:\temp>test.exe "C:\temp\test.tkn" sub2\bar param
test.
?
Yup. By quoting the TKN path, the program launches, but then LB throws away the rest of the command-line.