- Fail if no parameter is provided.
- The "CALL :label args..." syntax is available only when command extensions
are enabled. Fail if this syntax is used outside of a batch context.
- Reparse the CALL command parameter with the command parser, in order
to accurately parse and interpret it as a possible command (including
escape carets, etc...) and not duplicate the logic.
** CURRENT Windows' CMD-compatibility LIMITATION ** (may be lifted in
a "ROS-specific" running mode of CMD): only allow standard commands to
be specified as parameter of the CALL command.
This reparsing behaviour can be observed in Windows' CMD, by dumping
the interpreted commands after enabling the cmd!fDumpParse flag from
a debugger (using public symbols).
- When reparsing, we should tell the parser to NOT ignore lines that
start with a colon, because in this situation these are to be
considered as valid "commands" (for parsing "CALL :label").
* For Windows' CMD-compatibility, the remaining escape carets need to
be doubled again so that, after the new parser step, they are escaped
back to their original form. But then we also need to do it the "buggy"
way à la Windows, where carets in quotes are doubled either! However
when being re-parsed, since they are in quotes they remain doubled!!
(see "Phase 6" in https://stackoverflow.com/a/4095133/13530036 ).
* A MSCMD_CALL_QUIRKS define allows to disable this buggy behaviour,
and instead tell the parser to not not interpret the escape carets.
- When initializing a new batch context when the "CALL :label" syntax is
used, ensure that we reuse the same batch file position pointer as its
parent, so as to have correct call label ordering behaviour.
That is,
:label
ECHO hi
CALL :label
:label
ECHO bye
should display:
hi
bye
bye
i.e., the CALL calls the second label instead of the first one (and
thus entering into an infinite loop).
Finally, the "CALL :label" syntax strips the first ':' away, so, as a
side-effect, the command "CALL :EOF" fails (otherwise it would perform
a "GOTO :EOF" and succeeds), while "CALL ::EOF" succeeds.
Fixes some cmd_winetests.
ReactOS command line interpreter CMD
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The ReactOS command line interpreter CMD is derived from FreeCOM, the
FreeDOS command line interpreter.
We are shooting mainly to be just like 2000/XP cmd.exe. They are very close and only a small number(none that i can recall off the top of my head, so maybe 0) differences have been found between those two. It has been reported that ROS cmd.exe does not work on nt4 because of a missing api. I'm hoping to fix this at some point.
Compiling
~~~~~~~~~
ROS cmd used to depend on __REACTOS__ to provide two different ways to build cmd. There is still code left in it for this but... The __REACTOS__ = 0 has not been develped, maintained. And therefore it does not even compile anymore. __REACTOS__ = 1 works fine on both windows(nt). and someday i plan to remove all the __REACTOS__ = 0.
Using rbuild you can compile cmd separately by "make cmd_install". Also you can compile cmd using MSVC 6 and soon 7/8 hopefully.
Current Features
~~~~~~~~~~~~~~~~
- environment handling with prompt and path support.
- directory utilities.
- command-line history with doskey-like features.
- batch file processing.
- input/output redirection and piping.
- alias support.
- filename completion (use TAB), both Bash and Windows-CMD style.
Credits
~~~~~~~
FreeDOS developers:
normat@rpi.edu (Tim Norman)
mrains@apanix.apana.org.au (Matt Rains)
ejeffrey@iastate.edu (Evan Jeffrey)
Steffen.Kaiser@Informatik.TU-Chemnitz.DE (Steffen Kaiser)
Svante Frey (sfrey@kuai.se)
Oliver Mueller (ogmueller@t-online.de)
Aaron Kaufman (morgan@remarque.berkeley.edu)
Marc Desrochers (bitzero@hotmail.com)
Rob Lake (rlake@cs.mun.ca)
John P. Price <linux-guru@gcfl.net>
Hans B Pufal <hansp@digiweb.com>
ReactOS developers:
Eric Kohl
Emanuele Aliberti <ea@iol.it>
Paolo Pantaleo <paolopan@freemail.it>
Brandon Turner <turnerb7@msu.edu>
Bugs
~~~~
There are still many bugs ;)
Please report bugs to ReactOS team <ros-dev@reactos.org> or to JIRA at www.reactos.org