Mail Archives: djgpp/1997/11/09/06:19:09
On Fri, 7 Nov 1997, Shawn Hargreaves wrote:
> This would probably fix your nesting problem, but in general the djgpp
> system() function has problems running commands that use this method.
> When some random (non-unix script) file is invoked with this sort of
> 4DOS association, libc gets as far as the script_exec() routine in
> dosexec.c, decides that it isn't a valid script, and calls go32_exec()
> instead, which bypasses the command interpreter. Is there any reason why
> this is required (does it ever reach this shell script test when trying
> to run a native djgpp binary?)
DJGPP is trying hard to avoid calling the non-Unix shells, because
they aren't smart enough. (Yes, I know 4DOS is smarter, but see
below.) That is why it only calls the shell for commands which aren't
found neither in the current directory nor along the PATH.
When a command *is* found along the PATH, and it has one of the known
extensions (.bat, .btm, .sh, and some others), the appropriate
``interpeter'' program is invoked immediately. Otherwise, it is
checked to see whether it is a DJGPP executable. If so, it is invoked
by the native DJGPP method which enables long command lines. If not,
it is tested to be a Unix-style shell script which begins with a
"#!foo" where `foo' is a pathname of the program that should be
invoked to run this script. (`foo' does NOT need to be an exact
pathname, see the libc docs for `system'.) If the "#!" signature is
not found, it is assumed to be a .COM-style program and invoked
directly via the DOS Exec function.
Anything else is not supported by the current versions of dosexec and
system.
That is why (1) .bat files work and (2) DJGPP executables are
recognized and handled *before* the test for a possible shell script.
If you need to force `system' to call the shell right away, there's a
flag in `__system_flags' global variable that lets you do that (type
"info libc alpha system" and read there). I don't recommend that,
because an application will need to know what shell is used, so that
if it's COMMAND.COM it is NOT called.
> or could that call be replaced with
> __dosexec_command_exec(), which would make 4DOS associations work
> correctly?
That is done already, but only for extensions such as .bat and .btm
which are *known* to require the shell. There is no way to extend the
known extensions at run time, currently.
Another way is to call 4DOS explicitly, like this:
system ("4dos.com /c foo");
> Another possibility would be to test for an environment variable of the
> form .EXT, for any unknown file extensions, and invoke the command
> interpreter if that is found.
Bad idea, IMHO. Somebody might have these .EXT variables defined, but
could invoke COMMAND.COM on top of 4DOS, for some reason.
FYI, I didn't put support for 4DOS-specififc features into `system'
and dosexec because (1) I despise 4DOS from the first day I saw it
(don't ask) and (2) I don't know enough about it to implement that
support. Volunteers are welcome.
- Raw text -