Do not use custom alloc/free functions by default.
Do not free resources at process exit.
- You're doing it brick by brick while the OS & CRT do that with a bulldozer better than you do.
All these modifications have been verified with Windows' CMD, either
by using written cmd_rostests and the existing cmd_winetests, or
manually by enabling the flags cmd!fDumpTokens and cmd!fDumpParse
(available in the public symbols) and analyzing how the tokens are
being parsed, as well as the generated command tree.
See also the following links for more details (but remember that these
observations have to be double-checked in Windows' CMD!):
* Parser rules: https://stackoverflow.com/a/4095133/13530036
* Discussion: https://www.dostips.com/forum/viewtopic.php?f=3&t=8355
* Numbers parsing: https://www.dostips.com/forum/viewtopic.php?t=3758
* Label names vs. GOTO and CALL: https://www.dostips.com/forum/viewtopic.php?f=3&t=3803
and: https://www.dostips.com/forum/viewtopic.php?f=3&t=3803&p=55405#p55405
- Fix REM command parsing. A C_COMMAND-like structure should still
be built, so that it can show up during batch command echo. However
some specific handling needs to be done, so use instead a new C_REM
command type.
Escape carets are parsed differently than usual: they are explicitly
kept in the command line and don't participate in line continuations.
Also, the Windows' CMD behaviour is to discards everything before the
last line continuation.
- Prefix operator '@' (the "silent" operator) is parsed as a separate
command. Thus, the command @@foo@bar is parsed as: '@', '@', 'foo@bar'.
- Improve the checks for numbered redirection.
For this purpose, we check whether this is a number, that is in first
position in the current parsing buffer or is preceded by a whitespace-
like separator, including standard command operators (excepting '@' !)
and double-quotes.
- Empty command blocks, i.e. "( )", standing by themselves, or present
in IF or FOR commands, are considered invalid. (The closing parenthesis
is considered "unexpected".)
- Ignore single closing parenthesis when being outside of command blocks,
thus interpreting it as a command, and ignore explicitly everything
following on the same line, including line continuations.
This very specific situation can happen e.g. while running in batch mode,
when jumping to a label present inside a command block.
See the code for a thorough explanation.
- Detect whether a parenthesized block is not terminated at the end
of a command stream (getting a NUL character instead of a newline),
and if so, bail out early instead of entering into an infinite loop.
- Perform a similar check for the parenthesized list in FOR commands.
- Initialize the static 'InsideBlock' value to a known value.
- The '&' operator (multi-commmand) is allowed to have an empty RHS.
When such situation occurs, turn the CurrentTokenType to TOK_END
so as to avoid a parse error later on.
- The main body of a IF statement, or its 'else' clause, as well as
the main body of a FOR statement, must not be empty, otherwise this
is considered a syntax error. If so, call ParseError() that sets
the 'bParseError' flag, and forcing all batch execution to stop.
CORE-13682
- Split SubstituteVars() into its main loop and a helper SubstituteVar()
that just substitutes only one variable.
- Use this new helper as the basis of the proper implementation of the
delayed expansion of variables.
- Fix a bug introduced in commit 495c82cc, when GetBatchVar() fails.
CORE-11857 CORE-13736
It will be followed with a separate fix for the FOR-loop code.
Fixes some cmd_winetests.
A NULL pointer can be returned for a valid existing batch/FOR variable,
in which case the enhanced-variable getter should return an empty string.
This situation can happen e.g. when forcing a FOR-loop to tokenize a
text line with not enough tokens in it.
They are currently specified for documentation purposes (i.e. what
Windows 8+ CMD.EXE can report) but not used yet, since ReactOS does not
support them.
This functionality is: case insensitivity comparisons (/I);
CMDEXTVERSION and DEFINED unary operators; EQU, NEQ, LSS, LEQ, GTR, GEQ
generic string comparators.
CORE-10495 CORE-13672
- Fix how the ERRORLEVEL and the last returned exit code are set by
EXIT and CALL commands, when batch contexts terminate, and when CMD
runs in single-command mode (with /C).
Addendum to commit 26ff2c8e, and reverts commit 7bd33ac4.
See also commit 8cf11060 (r40474).
More information can be found at:
https://ss64.com/nt/exit.htmlhttps://stackoverflow.com/a/34987886/13530036https://stackoverflow.com/a/34937706/13530036
- Move the actual execution of the CMD command-line (in /C or /K
single-command mode) from Initialize() to _tmain(), to put it on par
with the ProcessInput() interactive mode.
- Make ProcessInput() also return the last command's exit code.
- To this purpose use the ParseErrorEx() that correctly sets the
bParseError flag, and return the partially-parsed command so that
it gets echoed as well for diagnostics purposes (Windows-compatible).
- Any other parameters specified after (or before) the '/?' switch for
the FOR and IF commands, are considered fatal syntax errors as well,
thus we employ the ParseErrorEx() as well.
CORE-13713 CORE-13736
- In case execution of all batch contexts is stopped (by selecting "All"
at the Ctrl-C/Ctrl-Break prompt), notify as well the CheckCtrlBreak()
signal handler once there are no more batch contexts (this in effect
resets the internal 'bLeaveAll' static flag in CheckCtrlBreak).
This is an adaptation of the fix present in FreeCOM 1.5, first
described in https://gcfl.net/FreeDOS/command.com/bugs074g.html .
- Introduce a ParseErrorEx() helper that sets the 'bParseError' flag and
displays a customized syntax-error message, only for the first syntax
error encountered. Implement ParseError() around the *Ex function.
- In batch mode, echo the original pre-parsed batch file line if a parse
error has been encountered.
- When running a compound command - including IF, FOR, command blocks -,
and that control flow is modified by any CALL/GOTO/EXIT command,
detect this while running the compound command so as to stop it and go
back to the main batch execution loop, that will then set up the actual
new command to run.
- In GOTO, do not process any more parts of a compound command only when
we have found a valid label.
pushd command of cmd.exe didn't treat the quoted parameter correctly.
- Call StripQuotes in SetRootPath function.
- Fix typo of FEATURE_DIRECTORY_STACK.
This PR will enable "Command Prompt" here. CORE-12150
- Introduce two small helpers to change and restore the console title.
- Console title can change even when internal commands are executed.
- Note that when commands are run from within batch files, title is unchanged.
- When "cmd.exe /c command" is run, the console title is unchanged; however
when "cmd.exe /k command" is run, the console title changes.
This allows to break commands such as:
C:\ReactOS\system32> for %f in (*.*) do dir
as one would expect: stop the currently running 'dir' and the 'for'.
"bCtrlBreak" doesn't need to be volatile too.
Using CTRL-C to cancel command line input would leave the prompt in
a state where the next command would be ignored. For example:
dir<CTRL-C>
dir
would cause cmd.exe to ignore the second dir command.
CORE-11677
The standard Win32 Console Control Handler will give CTRL-C events to
processes spawned from cmd.exe. If cmd.exe calls GenerateConsolCtrlEvent()
then the child process will receive two CTRL-C events.
CORE-13974
This should fix situations where (for example):
command_1 | command_2 && echo Succeeded
should *NOT* run "echo Succeeded" if any of the command_1 or command_2 has
failed.
This also makes the ExecutePipeline() function on par with the other
"ExecuteXXX()" helpers.
Problem diagnosed by Doug Lyons; patch inspired by contributor 'cagey45'.
