This will allow to separate better the individual command to
be executed (CMD_COMMAND) from the chaining and I/O handling
of several commands (CMD_NODE).
This also renames CMD_LIST into CMD_COMMAND to fit in above
scheme.
Signed-off-by: Eric Pouech <epouech@codeweavers.com>
The || and && operators to chain commands rely on the LHS command
to be successful (or unsucessful) to decide upon launching the RHS
command.
Unfortunately, success/failure is not always when errorlevel is
0 (non zero).
Some exmaples:
- if a redirection fails (eg. appending to a non existing file),
the command (builtin/external) is always unsuccessful (and the
error level is untouched,
- external command (when redirection is ok) is succesful when
program exit code is zero,
- ditto for a call to a label inside the batch file, with
the 'exit /b' parameter,
- it's way more complicated for builtins. Eg 'type' is unsuccessful
on a non existing file, while 'dir' (on the same unexisting file)
succeeds.
So start adding some tests about success / failure of some commands.
Signed-off-by: Eric Pouech <epouech@codeweavers.com>
cmd shouldn't terminate itself when user hits ctrl-c.
cmd should terminate the currently running CUI child it
waits for upon ctrl-c.
Signed-off-by: Eric Pouech <epouech@codeweavers.com>
When the path contains a mountpoint on Unix or a junction point to
another drive on Windows, cmd.exe should show free space for the
path instead of the root of the drive.
'if exists' takes a parameter which can be directory, directory/,
directory/. directory\ or directory\. for example, and should equate
to true if the directory exists. The syntax directory\ is explicitly
rejected by FindFirstFile and hence was not working - look for this
specific case, and if found append a '.'.
Follow-up commit of bc9d68bcbe
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55130#add_comment
Previously if an empty string was encountered while parsing out PATH,
cmd.exe would ignore the rest of the PATH entirely.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55097
Signed-off-by: Liam Middlebrook <lmiddlebrook@nvidia.com>
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>
When processing a (..) multiline section, each line is processed and
if it starts with a '@' it is not echoed, but more importantly if is
'rem' then anything else on that line should be ignored. The reported
issue was that a pipe was being executed when it was hidden behind a
rem, which was trigged by the preceeding '@' character not being
skipped.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=45729
Signed-off-by: Jason Edmeades <us@edmeades.me.uk>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
With the 'for' loop /f syntax, if tokens are requested the the normal
syntax is something like tokens=1,2* but there is valid syntax like
1,2,* (which effectively means the same). Make this other syntax work.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=45722
Signed-off-by: Jason Edmeades <us@edmeades.me.uk>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Avoid whitespace affecting the parsing of a for loops items. The
leading and trailing quote or backtick needed removing, and it was
assumed that the trailing character would be that character, which was
wrong when there was whitespace unless the parameter is trimmed.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=45731
Signed-off-by: Jason Edmeades <us@edmeades.me.uk>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
