Calling GetConsoleCP() when ReadConsoleW() fails (potentially indicating
that cmd.exe's instance isn't attached to a console) makes no sense.
In details, since GetConsoleCP() returns 0 when not attached to a console
to indicate error, we're in fact using CP_ACP.
So fallback explicitely to OEM CP (which is the default for CUI programs).
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
GCC 12.2 rightfully complains about an out-of-founds array access.
This can possibly happen for unsupported variable names.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
This allows:
- to mimic native behavior when a stray '\0' is present in file
(in 'FOR /F' execution, it's interpreted as an EOF marker)
(prevents an infinite loop)
- supports (with /USEBACKQ) unicode output (if BOM is present)
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53386
There are cases where the read can fail (not attached to a console,
input stream mapped to /dev/null...)
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Changes CMD to set its errorlevel to 0 only when the value of an environment variable
is set in in non-interactive / batch mode, retains the previous value otherwise.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=47791
Signed-off-by: Florian Eder <others.meder@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Some buffers in WCMD_HandleTildeModifiers() are only of size MAX_PATH,
even though they handle strings that aren't necessarily
filenames. When changed to have size MAXSTRING, a stack overflow crash
with strings of size MAX_PATH stops happening.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=42731
Signed-off-by: Damjan Jovanovic <damjan.jov@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Previously, invoking 'call' with an empty string would leave errorlevel
unchanged. Reset errorlevel to 0 to match the behavior of
the Windows 'cmd.exe'.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=49982
Signed-off-by: Aaron Hill <aa1ronham@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Based on a patch by Francesco Noferi.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=48396
Signed-off-by: Myah Caron <qsniyg@protonmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
For example, the explicit path "C:\some;path" is currently treated as if
the PATH environment variable is "C:\some;path" which is obviously wrong,
and searches for the directories "C:\some" and "path".
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This fixes a hang in the WinTV 8.5 installer.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Neither WCMD_give_help(), nor WCMD_setshow_default() are ever called
with a NULL pointer (notice how WCMD_skip_leading_spaces() already
assumes its argument is not NULL and does not return NULL).
Signed-off-by: Francois Gouget <fgouget@free.fr>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Found while trying to look into bug 44236.
A batch script is executed containing a line like this:
if (%1)==(p) start /W " " "%SFDIR%WSFplot" wr2300.t35 3
This returns an error like this:
Syntax error
Can't recognize 'p' as an internal or external command, or batch script.
It looks like native does handle the brackets differently when contained
inside the condition part of the if command.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=44338
Signed-off-by: Bernhard Übelacker <bernhardu@mailbox.org>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>