Current process in NOS??

[milton@ecn.purdue.edu (Milton D Miller)]

First, my disclaimer: I don't have a PC to check anything I'm about
to say here out.  I don't have the compiler, either.  From these
two statements, you can probably guess I haven't done any NOS hacking
myself.  But that doesn't mean I haven't spent time looking, tracing,
and analyzing NOS and its inner workings.  (For me, first priority
has to be get my license!)

>Can anyone fill me in on how to determine when the code in "cmdparse.c"
>is running in the "console command state"?  What I need to do, is add a
>conditional that is only true when the command has come from the "net>"
>prompt.

Should not an authenticated sysop be able to do the same things?

>         My first attempt was to do a check using:
>     if (Current == Command)
>but that doesn't seem to do it.  This ends up being true, even when the
>command is coming thru cmdparse from the MBOX.

This is because Current and Command are *sessions*, not processes.
The console has several sessions, each of which has its own screen,
etc.  (This is why commands that start their own sessions do not
work well from the mailbox ... the session code gets in the way).
The current process is in Curproc, but that alone won't tell you
what you want to know.  You want to know where cmdparse is being
called from, but instead you are looking at what the console is
doing.

>For those that are curious, I was trying to patch in the mods made by
>the JA folks for running netnews, and this modification enables NOS to
>spawn an unknown command to MS-Dos for execution (so you can run the
>news processing software periodically).  Addition of the "timer" command
>and "commandfile" command went smoothly, and the "extsearch" works, but
>I'm getting "trash" commands coming from the MBOX, that are being tossed
>to MS-Dos for execution.

This is because the mailbox code calls cmdparse just like the command
intrepreter.  Yes, amazeingly, NOS does reuse some code! :-)  Ok, there
are subtile differences but the call from the mailbox code is essentially
indistinguishable from a call from the net prompt.  cmdparse has a job
to do and it does it fairly well: it takes a table of command
descriptions (including minimum number of arguments, stack size if a
process is to be spawned, help text for insufficent command argument
and procedure to call), and a line of text.  It breaks the line into
tokens (argc/argv style), matches the command from the table (in a
consistant way), and executes the procedure in the table.  It doesn't
know, nor should it care, where it was called from.

>                          I've found that if someone connects to the
>MBOX (via AX.25), and they haven't successfully received the MBOX prompt
>yet, they can start sending command text that passes right thru the
>MBOX cmdparse and out to Dos.  Kind of scary if someone knows about this
>"hole".  They can delete all your files!  So I'd really like to fix
>this one.  Any suggestions would be appreciated.

After looking at the code, I believe your diagnosis is incorrect.
Instead, what I think is happening is the commands are being parsed,
but you have changed the action on 'no command in the table matching'
from 'return an error message' to 'give dos a chance to understand
this'.  These commands can be entered at anypoint that calls cmdparse
(including the mailbox prompt).

May I suggest an alternate approach: require the commands be prefixed
with a nos command, for example, '!' or 'shell' (which are already
in NOS, at least in 901130), or, if you need something extra, 'exec'
(although exec in unix means something different)?  This approach
has been used several places, eg ex (the base of vi, from which
I am typing this), Mail, ~! commands, to name a few.
Instead of  typing 'newschk, the user would type '!newschk'.

This also avoids the problem of the ever increasing set of nos
commands from hideing all the dos commands.

>                                                  Here's a segment of what
>I've done to the code so far:
>
>   ...

I would suggest restoring cmdparse and instead use the prefix command
method instead.

milton