Andrew, Thanks for sharing the results of your experiments with open(..., "p") and system().
Some of your comments, those which pertain more to UNIX semantics, are things which Shamim might comment more effectively on than I. On the Windows side of things, which is mostly where your discussion aims, I am responsible, either directly or via student efforts. On both sides, I am keen to improve what we've got. Our Windows popen() was some copylefted code cobbled from the internet. It seems to rely mainly on Win32 CreateProcess for its limits and semantics. If an executable is not found on the search path it seems to hope the command is a CMD.EXE internal command. Elsewhere we've sinced made a list of the internal commands, so this code need not be guessing like it is. Generally, to run an icode one might prefix it for this command with "iconx" as argv[0]. Running icode with .bat extension is sort of a legacy thing at this point, under NT-based Win32 the extension .cmd is more frequently used and might work for you. The .icx extension is not executable generally, and it would feel a bit hokey to rig it to work. Unicon output icode is generally appended to a copy of iconx or wiconx and given a .exe extension that ought to work fine from open(..."p"). Regarding system(), Visual C++'s system() was for console mode only, so we ended up writing our own, and this is a place where evil lurks, as there is the old (Icon) system() living in fsys.r but the Unicon system is living in fxposix.ri. We should merge those. Our command line argument processing lives in CmdParamToArgv() in rsys.r and while I don't see a lot of limits in there other than MaxPath, if your exceedingly long command line argument list is giving us trouble before we hand things off to WinExec or _spawnvp or one of the other system functions we are relying on, we may be able to fix it. If, however, you are giving command line arguments that the underlying Win32 won't handle, you pretty much have to accept that Windows is not UNIX after all, despite claims to the contrary. One more interesting point is that the code (and therefore your observed behavior) seems to vary some for these functions under nticonx.exe (pure NT Console), iconx.exe (NT Console with graphics) and wiconx.exe (Win32 app, faking a console if stdio to a terminal is indicated). So when you make bug reports, always tell us which iconx we are talking about, and if possible, tell us whether the behavior differs across iconx's. To sum up: a couple people have worked very hard to make open(..."p") and system() work to the extent that they do on Windows, and we want them to be better. We welcome help, both in the form of bug reports and example calls that don't behave as desired, and in the form of bug fixes and code improvements. Thanks for the quoting fix. Cheers, Clint On Tue, Jun 2, 2009 at 12:11 AM, Andrew Clarke <[email protected]> wrote: > Yet more on this, > > I've been experimenting with use of > > system(cmd[], infile, outfile, errfile [waitflag]) > > and although it is coping with a large effective command line (ie around > 500) it seems to be losing the last member of the cmd[] list when used in > list form. This is on Windows; I haven't yet tested on *nix. > > I've noticed a few other apparent problems with this call on Windows: > > * output of the called process doesn't appear to go into the outfile > parameter - something I created by calling the pipe() function. The output > just pumps to the console from the .icx when it starts running. > > * the executable (cmd[1]) is not searched for on the path. > > * I can't seem to get it to recognise .icx as a valid executable even after > registering .icx as an executable shell extension. > > * in list form, if the various args contain spaces or unpleasantly placed > quotes, the argv of the .icx is broken at those args. If at all possible > (ie if Windows is in any way capable) I would hope that it can behave > soberly and properly like exec() on *nix. > > * waitflag just waits for the process to initiate on windows. Using "nowait" > means it doesn't even wait for startup, so you get no clue from the error > return about successful or failed startup. Also I can't make sense of the > returned value; it's &null when "nowait" is used, or a mysterious number > like 1 when "nowait" is not used. > > Windows doesn't seem to have a decent fork/exec/wait model that matches > Unix, so I sympathise with the authors on this point. I don't know if it's > achievable, but I expect "nowait" even on windows should at least wait for > successful startup and report on that, and if the code asks for waiting, it > really should wait. > > I'm interested to know what could be done with the returned process id on > Unix. I can't see any sort of wait() function available in Unicon to use. > > > > ------------------------------------------------------------------------------ > OpenSolaris 2009.06 is a cutting edge operating system for enterprises > looking to deploy the next generation of Solaris that includes the latest > innovations from Sun and the OpenSource community. Download a copy and > enjoy capabilities such as Networking, Storage and Virtualization. > Go to: http://p.sf.net/sfu/opensolaris-get > _______________________________________________ > Unicon-group mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/unicon-group > ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ Unicon-group mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/unicon-group
