On Tue, 02 Jun 2009 18:13, Clinton Jeffery wrote:
> Andrew,
>
> Thanks for sharing the results of your experiments with open(..., "p")
> and system().
>
I'd feel selfish not sharing the pleasure around ;-/
> 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.
>
I've tried a few combos -
thing.bat
thing.icx (assuming registration might work)
iconx thing.icx
I also had to prefix them with their location; I'm not 100% clear what's
going on since CMD should have at least found the .bat and icx via the
PATH, so I would need more investigation in that
> The .icx extension is not executable generally, and it would feel
> a bit hokey to rig it to work.
>
Yes, making .icx special in the Icon code might be convenient, but what
about .pl, .py, .rb, .js, ..........
However, Windows "shellexec" has the capability of registering commands to
execute various extensions, and I'm hoping Unicon can interact with that. I
know that from a command line, you can
echo %PATHEXT%
and see something like
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.ctl;.py;.pyw;.PSC1;.pl;.plw;.icx
Which is the actual output on my Windows box.
I know that CMD uses PATHEXT as the list of extensions to look for on the
search of PATH, and when it finds one, it looks up the extension in the
registry bucket; presumably the list that you can get to when you use
Windows Explorer and pick from the topmenu Tools/Folder Options[File Types]
I don't know if %PATHEXT% is generally available, although I would guess
it's in a known place of the registry, but I think I've seen a system call
that combines the path search with attention to the registered pathext.
Exact details I'm fuzzy about.
One thing I'll be trying today is to see if there's any Windows system call
gurus lurking somewhere in our talent pool. If I can get some definitive
answers I'll pass them back, or even fiddle some code.
> 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").
>
Interesting - I wasn't aware of that, then again I'm such an old Icon head I
still haven't explored all the new corners of Unicon.
> Regarding system(), [SNIP] lives in CmdParamToArgv() in rsys.r
>
cool hints for where to look are valuable
> 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.
>
I was reading about the system calls for this several months ago to try to
understand what's going on in other pieces of software, and I came to the
conclusion that even at the deepest levels of Windows process invocation,
there's a model of building a buffer containing a complete command line and
then the spawner will rip it apart again. Even the system calls that claim
to act like exec* still have rules which expose the lie. Therefore any code
calling it needs to pay careful attention to embedded spaces and use of
double quotes and escapes of double quotes.
> 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).
>
This is why I should explore more and RTFM - I'm aware of the existence of
wiconx (but have no need for graphics in my *Icon code) but I didn't know
the special status of nticonx which is certainly worth giving a try.
> 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.
>
Will do. I've used iconx exclusively to this point.
> 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.
>
and thanks Arizona and Texas for the language which has brought me job
security and a lot of fun! I'll re-enter the world of Windows system calls
and see what I can come up with, but in practical terms I need to get this
thing working in a timely manner so I guess I'm going to have to use
temporary files and other unpleasantness. I don't suppose there's an
undocumented tempfile creator function, one that will automatically clean
up when it's closed even on Windows?
------------------------------------------------------------------------------
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
Unicon-group@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unicon-group
