TProcess
Archives Forums/MacOS X Discussion/TProcess
| ||
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! |
| ||
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. |
| ||
Ok, But how, my c-programing is not so good as i realy want! |
| ||
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 |
| ||
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? |
| ||
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! |
| ||
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 |