application command line while debugging not parsed correctly

Started by Gravity, May 05, 2012, 09:13:36 PM

Previous topic - Next topic

Gravity

When running an application with the following command line argument, through the debugger,

$SYS/broker/bytes/received

the "$S" (i.e the first two chars) is stripped off.

When running the application from the command line it works fine.

This is with

Version 7.00.3 RC 2 Win64

Gravity

Actually,

I just found that if one uses

$$SYS it works.

czerny

I had posted my problems with commandline in ver 6.5 in
http://forum.pellesc.de/index.php?topic=4038.msg14788#msg14788.
Yours seem to be a parsing problem too. $x looks like a commandline prompt code, where $$ is a $ sign himself, $T the time, $D the date and so on.

czerny

CommonTater

@Graity ...  I think we need a little more information...

It would be helpful if you would post
1) *Exactly* what is being typed at the command line (program name, quotes, etc...)
2) The project command line settings for your debug run... (a screen cap should do)

Then...
Does it work from the command line?
What does this represent... a file?


TimoVJL

This code shows problem with Command line arguments:
$SYS/broker/bytes/received
#include <stdio.h>

int main(int argc, char **argv)
{
for (int i=0; i<argc;i++)
printf("%u: %s\n", i, argv[i]);
return 0;
}
0: C:\CODE\PellesC\Forum\cmdlineparams.exe
1: YS/broker/bytes/received
Press any key to continue...
May the source be with you

Pelle

The command line passes through the project macro expander, where common macros are like $(NAME) - but can also be as simple as $N (a single letter, like in POMAKE). In this case $S is taken as a reference to macro S, which doesn't exist (probably) and is replaced with an empty value. $$ can be used for a literal $.

Not a bug, but the documentation could probably be better...
/Pelle

czerny

This explains not the misbehaviour I observed. Should I post my command line problem here as a separate bug?

AlexN

Quote from: czerny on May 15, 2012, 07:30:36 PM
This explains not the misbehaviour I observed. Should I post my command line problem here as a separate bug?
I think to handle two or more (even similar) problems in one task, has best conditions that some aspects are overlooked.
So I prefer for me to put every problem in an own task and so you can easily track whether a problem is solved or not.
best regards
Alex ;)