I recently tried to run a TOS application via shel_write(), using an extended to pass the command line parameters via ARGV. After some results it looks like there are at least 2 bugs in the current implementation.
What i did was
a) construct a new enviroment block including the ARGV command line parameters.
b) put a pointer to that block, and a pointer to the program name into a x_shell-structure
c) call shel_write(SHW_EXEC|SHD_ENVIRON, 0, 1, &x_shell, cmd) where cmd[0] contains 0x7f
What happened was, that tw-call tried to execute a program named "-p" (the first parameter that was intended to be passed to my program).
After some investigation, i think found out the reason for this. When running a TOS program, shel_write executes tw-call instead (or whatever happens to be in the environment variable TOSRUN), constructing a new command line to included the original program name. There are however a few things that look strange:
a) in function launch(), there is code like:
if (wiscr == 1 || p_tail[0] == 0x7f || (unsigned char)p_tail[0] == 0xff)
{
/* In this case the string CAN ONLY BE null terminated. */
longtail = strlen(p_tail + 1);
if (longtail > 124)
longtail = 124;
DIAG((D_shel, NULL, "ARGV! longtail = %ld", longtail));
}
Why is the commandline restricted to 124, when it was expclicity specified that ARGV method should be used? The variable longtail is not adjusted later, nor does the function try to get the actial parameters from the ARGV environment variable.
b) if the variable longtail is set, a new enviroment is created using make_argv(). However, make_argv() stashes the build environment block into C.env, while create_process() passes my Environment block to tw-call.
The outcome of this is that tw-call parses the original command line parameters, instead of the ones including its own path, ie. it only sees
"myprogram -p" instead of "tw-call myprogram -p".