Page 2 of 3 <123>
Topic Options
#155284 - 2006-01-14 02:53 PM Re: *not a bug*
Les Offline
KiX Master
*****

Registered: 2001-06-11
Posts: 12734
Loc: fortfrances.on.ca
Quote:

My only point is that it is unexpected behaviour...



Then what do you make of the weird behaviour when you are trying to pass an arguement that starts with a number? I had to prefix the var (used # in my case) and then strip it off after.
Code:
  If Left($Recipient,1) = "#"
$Recipient = Right($Recipient,Len($Recipient)-1)
endif

_________________________
Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.

Top
#155285 - 2006-01-14 05:03 PM a bug?
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22346
Loc: OK
oh...
was talking to a friend and decided to test once more and was able to produce a code that does not escape the characters:
Code:

#include "windows.h"
#include <iostream>
int main() {
printf("%s",GetCommandLine());
}



so, using ANSI argument parsing does introduce the problem.
or using the cout from std.

so, I'm starting to think this might be called a bug after all.


Edited by Jooel (2006-01-14 05:05 PM)
_________________________
!

download KiXnet

Top
#155286 - 2006-01-14 05:27 PM Re: a bug?
Shawn Administrator Offline
Administrator
*****

Registered: 1999-08-13
Posts: 8611
a bug where ?
Top
#155287 - 2006-01-14 05:57 PM Re: a bug?
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22346
Loc: OK
a bug in handling of the input argument.
_________________________
!

download KiXnet

Top
#155288 - 2006-01-14 06:16 PM Re: a bug?
Shawn Administrator Offline
Administrator
*****

Registered: 1999-08-13
Posts: 8611
in where ? Windows ?
Top
#155289 - 2006-01-14 10:25 PM Re: a bug?
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22346
Loc: OK
kixtart.
_________________________
!

download KiXnet

Top
#155290 - 2006-01-14 11:15 PM Re: a bug?
Shawn Administrator Offline
Administrator
*****

Registered: 1999-08-13
Posts: 8611
sorry you lost me. Did kix32 process the command-line any different than any other console app ?

-Shawn

Top
#155291 - 2006-01-15 12:02 AM Re: a bug?
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22346
Loc: OK
that does not matter.
and yes it did.
anyway, it don't matter.

kix32.exe is said to function in some manner and when that does not apply, it's a bug.
also, as wkix32.exe and my last code with printf() and GetCommandLine() show, the correct working is quite doable.
again, that does not matter.
even if it wasn't, it should be documented.
and as it is not, it qualifies as a bug.

imho.
_________________________
!

download KiXnet

Top
#155292 - 2006-01-17 05:39 PM Re: *not a bug*
Ruud van Velsen Moderator Offline
Developer
*****

Registered: 1999-05-06
Posts: 391
Loc: Amsterdam, The Netherlands
Wow, excellent test/debug work there.

The behaviour you have found is actually by design of the C/C++ commandline argument handler. Details on this (including examples) can be found in:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/htm/progs_12.asp

Hope this clarifies the issue.

Regards,

Ruud

Top
#155293 - 2006-01-18 10:03 AM Re: *not a bug*
Richard H. Administrator Offline
Administrator
*****

Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
So to clarify, is there no way you will be able to fix this because it is a feature of the startup code?

FYI I get the same problem compiling with a port of the GCC compiler, possibly it's using the same libraries for the start-up code.

Top
#155294 - 2006-01-18 10:52 AM Re: *not a bug*
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22346
Loc: OK
richie, there is a way.
using different input method removes the problem.
_________________________
!

download KiXnet

Top
#155295 - 2006-01-18 12:48 PM Re: *not a bug*
Ruud van Velsen Moderator Offline
Developer
*****

Registered: 1999-05-06
Posts: 391
Loc: Amsterdam, The Netherlands
If I were to implement a new macro called @COMMANDLINE, which would return the entire, un-processed, commandline would that help at all?

This request is on the todo-list anyway, so if this resolves this particular issue as well, I'll be glad to try and get this into 4.52.

Regards,

Ruud

Top
#155296 - 2006-01-18 01:00 PM Re: *not a bug*
Richard H. Administrator Offline
Administrator
*****

Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
If you can pull in the command line in an unmolested format, can you not then parse it in a more sensible way than the startup code?

I don't think it would help much to have to use two different methods to get command line variable assignments.

If creating a bespoke argument parser is going to cause a lot of work or delay I guess that in the short term we could probably create a "command line parser" UDF to do the job - at least we could be sure of the accuracy of the data.

Top
#155297 - 2006-01-18 01:09 PM Re: *not a bug*
Allen Administrator Online   shocked
KiX Supporter
*****

Registered: 2003-04-19
Posts: 4557
Loc: USA
If it's not a lot of trouble to add, I give a vote for the macro.
Top
#155298 - 2006-01-18 03:06 PM Re: *not a bug*
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22346
Loc: OK
just like richie said, it does not remove the problem.

after adding the macro, would it be possible to use extra arguments on commandline?
iirc, that was the reason for it. so one could extend the kix commandline have other parameter switches like all the exe's have...
oh, and ofcourse the path to kix.exe
_________________________
!

download KiXnet

Top
#155299 - 2006-01-18 08:46 PM Re: *not a bug*
iffy Offline
Starting to like KiXtart

Registered: 2005-05-29
Posts: 149
Loc: The Netherlands
Are there more known 'irregularities' than the one that started this topic?

If not, isn't 'correcting' just this one 'odd' behaviour relatively simple without introducing new stuff?

If there are more issues than the trailing escape character issue than I'd go for leaving the current commandline parsing as it is and introduce the new @commandline macro as suggested by Ruud.

PS.. just curious: is the problem in C/C++ in printf/cout or in argv?

Top
#155300 - 2006-01-18 10:31 PM Re: *not a bug*
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22346
Loc: OK
iffy, it seems to be a problem of cout as well as argv.
_________________________
!

download KiXnet

Top
#155301 - 2006-01-19 10:03 AM Re: *not a bug*
Richard H. Administrator Offline
Administrator
*****

Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
Quote:

Are there more known 'irregularities' than the one that started this topic?




Yup, check the link that Ruud provided to see what the problem is. Basically, before your program starts there is a bit of startup/setup code that is run. It does a number of things, one of which is to present argc / argv / envp as parameters for Main() (at least in the C world).

MS has changed command line handling a few times, and each time it has veered away from doing anything you would consider sensible. Obviously they think programmers appreciate being able to work in idiosyncratic and inconsistent environments.

I'd be interested if anyone can think of a good reason for this behaviour.

Quote:

If not, isn't 'correcting' just this one 'odd' behaviour relatively simple without introducing new stuff?




No, it's probably not that simple. As the startup code is executed before you get you hands on it in the program there is no way to affect it's action. Because you cannot see the original data you cannot determine if it's been screwed about.

The best you can do is to write your own command line parser and parse the original command line. It's not a particularly complicated bit of code to write, but it is new code which is not already in the KiXtart interpreter.

Quote:

If there are more issues than the trailing escape character issue than I'd go for leaving the current commandline parsing as it is and introduce the new @commandline macro as suggested by Ruud.




The @COMMANDLINE macro is going to be there anyway. The problem is that if you don't fix this anomoly in some way you are going to be in the position of having to say that sometimes assigning variable values on the command line will work in KiXtart and sometimes it won't, depending on the data. That's not a good place to be.

Quote:

PS.. just curious: is the problem in C/C++ in printf/cout or in argv?




This issue specifically is in the handling of the command line arguments. The handling of strings by library functions like printf() is standardised and is not an issue (unless they are badly broken ).

Top
#155302 - 2006-01-19 11:16 AM Re: *not a bug*
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22346
Loc: OK
again.
fixing this issue is rather simple.
instead of using the args parsed for you, parse them yourself from the raw commandline.

and richie, not sure I understand your flaming of MS here.
you just posted a while ago that same issue is there with gcc.
last time I checked, it's not MS compiler.
_________________________
!

download KiXnet

Top
#155303 - 2006-01-19 01:45 PM Re: *not a bug*
Richard H. Administrator Offline
Administrator
*****

Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
Quote:

again.
fixing this issue is rather simple.
instead of using the args parsed for you, parse them yourself from the raw commandline.




It is a work-around, but I don't think that it's a good long term solution to say 'using $var="VALUE" on the command line doesn't always work as you'd expect so you're better off parsing the line yourself'. Much better to fix '$var="VALUE"' so that it always works as expected.

Quote:

and richie, not sure I understand your flaming of MS here.



Hah! Having had to put up with doubling speech marks, using ^ as an escape and various other unspeakable and changing kludges over the years, it's no surprise that the goal-posts have been moved again. I appreciate that some of this nastiness is down to the command line interpreter.

Quote:

you just posted a while ago that same issue is there with gcc.
last time I checked, it's not MS compiler.



Correct. However it will of course use standard Windows code and libraries including start-up code, and that is where the problem lies.

Top
Page 2 of 3 <123>


Moderator:  ShaneEP, Arend_, Jochen, Radimus, Glenn Barnas, Allen, Ruud van Velsen, Mart 
Hop to:
Shout Box

Who's Online
0 registered and 581 anonymous users online.
Newest Members
Audio, Hoschi, Comet, rrosell, PatrickPinto
17880 Registered Users

Generated in 0.073 seconds in which 0.026 seconds were spent on a total of 12 queries. Zlib compression enabled.