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.
- Display the names of the files being TYPEd only if more than one file
has been specified on the command-line, or if a file specification
(with wildcards) is present (even just for one).
These names are displayed on STDERR while the files are TYPEd on
STDOUT, therefore allowing concatenating files by just redirecting
STDOUT to a destination, without corrupting it with the displayed file
names. Also, add a /N option to force not displaying these file names.
- When file specifications (with wildcards) are being processed, silently
ignore any directories matching them. If no corresponding files have
been found, display a file-not-found error.
- When explicitly directory names are specified, don't do any special
treatment; the CreateFile() call will fail and return the appropriate
error.
- Fix the returned errorlevel values.
See https://ss64.com/nt/type.html for more information.
Fixes some cmd_winetests.
- When reading from a file, retrieve its original size so that
we can stop reading it once we are beyond its original ending.
This allows avoiding an infinite read loop in case the output of
the file is redirected back to it.
Fixes CORE-17208
- Move the FileGetString() helper to the only file where it is
actually used.
- Restore any truncated space in the name prefix, before displaying
any error message.
- When trimming the name prefix from "special" characters (spaces, comma
and semicolon), so that e.g. "set ,; ,;FOO" displays all the variables
starting by "FOO", save also a pointer to the original name prefix, that
we will use for variables lookup as well.
This is done, because the SET command allows setting an environment variable
whose name actually contains these characters (e.g. "set ,; ,;FOO=42"),
however, by trimming the characters, doing "set ,; ,;FOO" would not allow
seeing such variables.
With the fix, it is now possible to show them.
That's an actual fact, done on original MS-DOS COMMAND.COM, FreeCOM,
Windows' CMD.EXE, etc., but is strangely undocumented on MSDN documentation.
See https://www.dostips.com/forum/viewtopic.php?t=4436
Fixes some cmd_winetests.
This functionality is: case insensitivity comparisons (/I);
CMDEXTVERSION and DEFINED unary operators; EQU, NEQ, LSS, LEQ, GTR, GEQ
generic string comparators.
- First, the option and the APIs called by it can work directly on
paths relative to the current directory. So there is no need to
call GetFullPathName(), with the risk of going over MAX_PATH if the
current path is quite long (or nested) but the RMDIR is called on a
(short-length) relative sub-directory.
- Append a path-separator (backslash), only if the specified directory
does not have one already, and, that it does not specify a current
directory via the "drive-root" method, e.g. "C:" without any trailing
backslash.
- In case there are errors during deletion of sub-directories or
sub-files, print the error but continue deleting the other sub-dirs
or files.
- Monitor the Ctrl-C breaker as well, and stop deleting if it has been
triggered.
- When removing file/directory read-only attribute, just remove this
attribute, but keep the other ones.
- When deleting the directory, first try to do it directly; if it fails
with access denied, check whether it was read-only, and if so, remove
this attribute and retry deletion, otherwise fails.
- When recursively deleting a drive root directory, ultimately resolve
the dir pattern and check whether it's indeed a drive root, e.g.
"C:\\", and if so, just return success. Indeed, calling
RemoveDirectory() on such drive roots will return ERROR_ACCESS_DENIED
otherwise, but we want to succeed even if, of course, we won't
actually "delete" the drive root.
Use kernel32!lstrcmp(i) instead of CRT!_tcs(i)cmp, so as to use the correct
current thread locale information when comparing user-specific strings.
As a result, the following comparison: 'b LSS B' will return TRUE,
instead of FALSE as it would be by using the CRT functions (and by
naively considering the lexicographical order in ANSI).
This behaviour has been introduced in Windows 2000 onwards.
For MKDIR, also properly support the case of ERROR_FILE_EXISTS and
ERROR_ALREADY_EXISTS last-errors by displaying the standard error
"A subdirectory or file XXX already exists.\n"
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.
We note two things, when CMD searches for the corresponding label in the
batch file:
- the first character of the line is always ignored, unless it's a colon;
- the escape caret ^ is supported and interpreted.
Fixes some cmd_winetests.
- The ':EOF' label feature is available only when extensions are enabled.
- Anything that follows the ':EOF' label, separated by at least one
whitespace character, is ignored, and the batch file terminates.
- 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.
- Use a common large string buffer for temporary command substitutions/expansions,
instead of having such a buffer in the local stack of the parsing and
echoing functions that may be called recursively. Since CMD executes
synchronously we know that this common buffer can only be used once at
a time.
- Also do a small code cleanup in ParseIf(), ParseFor() and ParseCommandPart().
Add a MSCMD_ECHO_COMMAND_COMPAT define to be able to switch back to our
older but less broken behaviour at compile-time.
- Append a trailing space to commands when those have a parameter,
as well as after a command-block closing parenthesis.
- Space around redirection strings need to be switched around.
- Use ConOutPuts() instead of ConOutPrintf() for displaying strings that
are not printf formatted.
- When echo-ing/unparsing FOR command, any possible FOR variables
present in the FOR parenthesized list (before the "do" part) should be
substituted as well.
* Update German translations
* Update translation again
* More translations
* Some fixes in the german translation
* Some more fixes
* Little translation tweak
* Updates to 2nd review
* Little update
* Add back keyboard accel for IDS_OPENFILELOCATION.
Co-authored-by: Hermès BÉLUSCA - MAÏTO <hermes.belusca-maito@reactos.org>
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
Particular DIR commands like: "DIR .", "DIR .." now work as expected,
and we also correctly fix the behavior for files without extension,
that r38746 (2b06cfc0) originally tried to fix but broke the previous
examples.
Therefore "DIR *." and "DIR noextfile." work too.
Pathological cases like "DIR \...", "DIR \...\.", "DIR ..\...\.." and
the like (and with more than 3 dots) now work as expected.
Adapted from PR #592 by Katayama Hirofumi MZ, but with extended bugfixing.
CORE-13961
- 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.
- Start to doxygenate the library, focusing in great details on the
functions of the "outstream" module.
- Add a K32LoadStringEx function that expands (K32)LoadString by
allowing a LanguageId parameter to be able to load strings from other
languages than the current one.
- Add "ConResMsg*" helper functions to be able to (format and) print
message strings with inserts that come *NOT* from a message table (as
usual) *BUT* from resource string tables.
Will be helpful for CORE-14265 in particular.
[CMD] Fix the call to ConMsgPrintfV().