#155299 - 2006-01-18 08:46 PM
Re: *not a bug*
|
iffy
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
|
|
|
|
#155301 - 2006-01-19 10:03 AM
Re: *not a bug*
|
Richard H.
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
|
|
|
|
#155303 - 2006-01-19 01:45 PM
Re: *not a bug*
|
Richard H.
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
|
|
|
|
Moderator: ShaneEP, Arend_, Jochen, Radimus, Glenn Barnas, Allen, Ruud van Velsen, Mart
|
0 registered
and 581 anonymous users online.
|
|
|