TProcess

Archives Forums/MacOS X Discussion/TProcess

MacSven(Posted 2012) [#1]
TProcess makes me freaky under MacOS X

if i use the TProcess with this it should not work:

temp_proc:tproc = CreateProc("./avrdude -q -patmega1284p -cusbasp -Uflash:w:"+chr$(34)+"/Volumes/MacOS X/Applications/BlitzMax/SourceFiles/CocoaExt/LunaAVR Test/Examples/BitAccess.hex"+chr$(34)+":a",1)

This is the error:

avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x1e9705
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file ""/Volumes/MacOS"
avrdude: error opening "/Volumes/MacOS: No such file or directory
avrdude: input file "/Volumes/MacOS auto detected as invalid format
avrdude: can't open input file "/Volumes/MacOS: No such file or directory
avrdude: write to file '"/Volumes/MacOS' failed

It is a problem with spaces in the filename. If i use the same command in the Terminal.app it works fine:

localhost:LunaAVR Test Sven$ avrdude -q -patmega1284p -cusbasp -Uflash:w:"/Volumes/MacOS X/Applications/BlitzMax/SourceFiles/CocoaExt/LunaAVR Test/Examples/BitAccess.hex":a

avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x1e9705
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "/Volumes/MacOS X/Applications/BlitzMax/SourceFiles/CocoaExt/LunaAVR Test/Examples/BitAccess.hex"
avrdude: input file /Volumes/MacOS X/Applications/BlitzMax/SourceFiles/CocoaExt/LunaAVR Test/Examples/BitAccess.hex auto detected as Intel Hex
avrdude: writing flash (2624 bytes):
avrdude: 2624 bytes of flash written
avrdude: verifying flash memory against /Volumes/MacOS X/Applications/BlitzMax/SourceFiles/CocoaExt/LunaAVR Test/Examples/BitAccess.hex:
avrdude: load data flash data from input file /Volumes/MacOS X/Applications/BlitzMax/SourceFiles/CocoaExt/LunaAVR Test/Examples/BitAccess.hex:
avrdude: input file /Volumes/MacOS X/Applications/BlitzMax/SourceFiles/CocoaExt/LunaAVR Test/Examples/BitAccess.hex auto detected as Intel Hex
avrdude: input file /Volumes/MacOS X/Applications/BlitzMax/SourceFiles/CocoaExt/LunaAVR Test/Examples/BitAccess.hex contains 2624 bytes
avrdude: reading on-chip flash data:
avrdude: verifying ...
avrdude: 2624 bytes of flash verified

Are the TProcess and the Terminal Command different!


skidracer(Posted 2012) [#2]
Yes, CreateProcess will have problems with quotes used inside arguments. You will need to modify the makeargv code in freeprocess.c to get the above to work.


MacSven(Posted 2012) [#3]
Ok,

But how, my c-programing is not so good as i realy want!


Yasha(Posted 2012) [#4]
I've made no attempt at all to test this (written on a Windows box, ha!), but here's my off-the-top-of-my-head suggested change:

freeprocess.c


Changes are really just to makeargv, but it needs an extra #include so I pasted the whole thing.

In theory it should allow backslash escaped spaces and quotes, doublequoted and singlequoted substrings in arguments, and strip out the quotes before passing on the arg vector as expected by a command line. Makes no attempt to actually do backslash substitution though.

As warned above, I have not even tested to see if this so much as compiles correctly. Use at own risk.

Last edited 2012


MacSven(Posted 2012) [#5]
Hi Yasha,

Replaces the code and try to build, i get this error:

/Applications/BlitzMax/mod/pub.mod/freeprocess.mod/freeprocess.c:84: error: 'for' loop initial declaration used outside C99 mode

The GCC Compiler does not supported the C99 mode. Any other idea?


MacSven(Posted 2012) [#6]
Problem Solved:
Use this in you code it works fine on macos x
	argv=/*(char**)*/malloc( (n+1)/* *sizeof(char*)*/ );
	int a;
	for (a = 0; a < n; a ++) {
		argv[a] = temp_argv[a];
	}
	argv[n] = NULL;




Thanx you saved my life!


Yasha(Posted 2012) [#7]
Ha, I was just pasting that change into the above codebox at the same time you were finding it.

It's odd, that code uses three or four much more interesting C99 features and it chooses to complain about that? For instance, technically I think your solution is actually a C99 feature as well (ANSI C required all variables to be defined at the top of the function!).

(In general, you can tell GCC to shut up with --std=c99 or even --std=c11, but in this case you'd need to modify the BlitzMax build process to make that change.)

Last edited 2012