«

Has anyone encountered a problem with the Microsoft C 5.0 compiler always
returning a 0 from the system() call, no matter what the actual command
executed by system() returns?

Is there a fix for this or am i misunderstanding something fundamental
about
the way the system() call works in msc5.0? (Like the command.com always
returning the 0, which system(), in turn, returns to my program?)

I'm trying to determine whether or not the executed command succeeded or
not by
looking at the completion code from system, ala:

char buf[BUFSIZ];

sprintf(buf,"rnews < D_elricf.3aa");
if (!system(buf)) perror(buf);

and i'm having a hard time of it since system() always (seems) to return
0!

barry <> writes:
> Has anyone encountered a problem with the Microsoft C 5.0 compiler always
> returning a 0 from the system() call, no matter what the actual command
> executed by system() returns?
>
> Is there a fix for this or am i misunderstanding something fundamental
> about
> the way the system() call works in msc5.0? (Like the command.com always
> returning the 0, which system(), in turn, returns to my program?)
>
> I'm trying to determine whether or not the executed command succeeded or
> not by
> looking at the completion code from system, ala:
>
> char buf[BUFSIZ];
>
> sprintf(buf,"rnews < D_elricf.3aa");
> if (!system(buf)) perror(buf);
>
> and i'm having a hard time of it since system() always (seems) to return
> 0!

<joke>But 0! is 1.</joke>

How sure are you that "rnews < D_elricf.3aa" is returning a
non-zero status? It might just be a problem with rnews command.
If so, there's not much that system() can do about it.

All the standard says about this is:

If the argument is not a null pointer, and the system function
does return, it returns an implementation-defined value.

It may be reasonable to assume, on your particular implementation,
that the result returned by system() is related to the exit status
of the invoked program. But you should check your implementation's
documentation. The input redirection might have some effect on the
handling of the exit status; for example, I can imagine that you
might be getting the status of the command processor that invoked
the command "rnews < D_elricf.3aa" rather than the status of the
"rnews" command.

If there is a problem with your implementation's system()
function, you'll need to ask about it in a forum that deals with
your implementation, perhaps comp.os.ms-windows.programmer.win32
or one of the microsoft.* groups.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

In article <hu37hs$c41$>, barry <> wrote:
>Has anyone encountered a problem with the Microsoft C 5.0 compiler always
>returning a 0 from the system() call, no matter what the actual command
>executed by system() returns?
>
>Is there a fix for this or am i misunderstanding something fundamental
>about the way the system() call works in msc5.0? (Like the command.com
>always returning the 0, which system(), in turn, returns to my
>program?)

Kiki has already given you the "CLC standard" answer, which is, of
course, a) entirely correct in all its particulars and b) entirely
useless.

Now, onto a (hopefully) useful answer. As far as I know, this has never
worked correctly (for suitable assumptions about what "correct" means)
under DOS/Windows. I.e., the returned value returned by
COMMAND.COM/CMD.EXE/whateverElseFromMS tells you only that COMMAND.COM
itself succeeded (which is true 99.999999% of the time). This behavior
is unlikely to ever change in the Windows product line.

In Unix, it does work correctly - that is, sh "passes down" the value
returned by the command:

$ sh -c 'ls ksdfjh';echo $?
ls: ksdfjh: No such file or directory
1
$

P.S. Once, a long, long time ago, I wrote a DOS device driver to
address this problem. It was a little "hinky", but it did work. Was
rather cool, in its own little way.

P.P.S. The FGA for this sort of problem is to somehow hack the command
line that you run so that it indicates the status in some "out of band"
way, such as:

system("yourcommand & if errorlevel 1 echo Failed > atmpfile");

Note that in Unix, you could do: echo $? > atmpfile, but the seemingly
equivalent DOS syntax (%errorlevel%) just doesn't quite do it...

HTH

--
Just for a change of pace, this sig is *not* an obscure reference to
comp.lang.c...

Kenny McCormack writes:
> In article <hu37hs$c41$>, barry <>
> wrote:
>>Has anyone encountered a problem with the Microsoft C 5.0 compiler
>>always returning a 0 from the system() call, no matter what the actual
>>command executed by system() returns?
>>
>>Is there a fix for this or am i misunderstanding something fundamental
>>about the way the system() call works in msc5.0? (Like the command.com
>>always returning the 0, which system(), in turn, returns to my program?)
>
> Kiki has already given you the "CLC standard" answer, which is, of
> course, a) entirely correct in all its particulars and b) entirely
> useless.
>
> Now, onto a (hopefully) useful answer. As far as I know, this has never
> worked correctly (for suitable assumptions about what "correct" means)
> under DOS/Windows. I.e., the returned value returned by
> COMMAND.COM/CMD.EXE/whateverElseFromMS tells you only that COMMAND.COM
> itself succeeded (which is true 99.999999% of the time). This behavior
> is unlikely to ever change in the Windows product line.
>
> In Unix, it does work correctly - that is, sh "passes down" the value
> returned by the command:
>
> $ sh -c 'ls ksdfjh';echo $?
> ls: ksdfjh: No such file or directory 1
> $
>
> P.S. Once, a long, long time ago, I wrote a DOS device driver to
> address this problem. It was a little "hinky", but it did work. Was
> rather cool, in its own little way.
>
> P.P.S. The FGA for this sort of problem is to somehow hack the command
> line that you run so that it indicates the status in some "out of band"
> way, such as:
>
> system("yourcommand & if errorlevel 1 echo Failed > atmpfile");
>
> Note that in Unix, you could do: echo $? > atmpfile, but the seemingly
> equivalent DOS syntax (%errorlevel%) just doesn't quite do it...
>
> HTH

No waranties expressed or implied, use at own risk, etc.

I've been using these patches for years with no problems. Source (sort
of)
is included for those worried about virus problems.

(This is from a make package some friends and I wrote a while ago--ignore
any
references to make that didn't get edited out.)

-------------------------------------------------
COMMAND.COM patch to return ERRORLEVEL from child
_________________________________________________

There is a feature (bug) in COMMAND.COM that causes MAKE not to be able to
detect when commands that involve redirection fail. This is because MAKE
executes these commands using a sub-shell and the sub-shell does not
return
the exit code of the command it executed.

What follow are patches for COMMAND.COM version 2.11 (MS only) and
versions
3.20 and 3.30 (MS and IBM versions).

__________________________________________________ ____________________________

Patch to return ERRORLEVEL as exit code when COMMAND.COM terminates.
Note that in 3.20 and 3.30, ERRORLEVEL is already returned correctly when
a
sub-shell is terminated with the EXIT command. This patch does not cause
built-in commands (DEL, etc.) to return failure exit codes.

This patch is valid for MSDOS version 2.11. THIS IS NOT VALID FOR PCDOS!

0220: B8 00 4C CD 21 MS-DOS 2.11
0AC0: 00 00 00 00 00 00 00 00 COMMAND.COM
19C0: 06 8E 06 BA 2C 26 A1 35 08 26 A3 16 00 07
19D0: 8E 06 BC 2C B4 49 CD 21 B8 00 4C CD 21

0220: E9 9D 08 90 90 2.11 Patch
0AC0: B4 4C 2E A0 75 08 CD 21
19C0: 8E 06 BA 2C 06 B8 C8 0A 50 26 A1 35 08 26
19D0: A3 16 00 8E 06 BC 2C B4 49 CD 21 CB 90
__________________________________________________ _______

This patch is valid for MSDOS and PCDOS version 3.20.

0210: A1 9C 0A 2E A3 16 00 A1 9E 0A 2E A3 0A 00 A1 A0 3.20
COMMAND.COM
0220: 0A 2E A3 0C 00 B8 00 4C

0210: 0E 07 FC BE 9C 0A AD 26 A3 16 00 BF 0A 00 A5 A5 3.20 Patch
0220: A0 FA 0A B4 4C 90 90 90
__________________________________________________ _______

This patch is valid for MSDOS and PCDOS version 3.30.

023A: A1 8C 0B 2E A3 16 3.30
COMMAND.COM
0240: 00 A1 8E 0B 2E A3 0A 00 A1 90 0B 2E A3 0C 00 B8
0250: 00 4C

023A: 0E 07 FC BE 8C 0B 3.30 Patch
0240: AD 26 A3 16 00 BF 0A 00 A5 A5 B4 4C A0 EA 0B 90
0250: 90 90
__________________________________________________ ____________________________

MS-DOS 2.11 COMMAND.COM

0228 B8004C MOV AX,4C00 ; "/C" termination
022B CD21 INT 21

19C2 06 PUSH ES ; "EXIT" command processor
19C3 8E06BA2C MOV ES,[2CBA] ; in transient section
19C7 26A13508 MOV AX,ES:[0835]
19CB 26A31600 MOV ES:[0016],AX
19CF 07 POP ES
19D0 8E06BC2C MOV ES,[2CBC]
19D4 B449 MOV AH,49
19D6 CD21 INT 21
19D8 B8004C MOV AX,4C00
19DB CD21 INT 21
____________________________________________

MS-DOS 2.11 Patch

0228 E99D08 JMP 0AC8 ; "/C" termination -- jump to
022B 90 NOP ; exit patch
022C 90 NOP

0AC8 B44C MOV AH,4C ; terminate process with exit
0ACA 2EA07508 MOV AL,CS:[0875] ; code set to ERRORLEVEL
0ACE CD21 INT 21

19C2 8E06BA2C MOV ES,[2CBA] ; "EXIT" command in overlay
19C6 06 PUSH ES
19C7 B8C80A MOV AX,0AC8 ; put address of exit patch in
19CA 50 PUSH AX ; root on stack
19CB 26A13508 MOV AX,ES:[0835]
19CF 26A31600 MOV ES:[0016],AX
19D3 8E06BC2C MOV ES,[2CBC]
19D7 B449 MOV AH,49
19D9 CD21 INT 21
19DB CB RETF ; jump to exit patch
19DC 90 NOP
__________________________________________________ ____________________________

0210 A19C0A MOV AX,[0A9C] ; MSDOS COMMAND.COM
3.20
0213 2EA31600 MOV CS:[0016],AX
0217 A19E0A MOV AX,[0A9E] ; "/C" termination
021A 2EA30A00 MOV CS:[000A],AX
021E A1A00A MOV AX,[0AA0]
0221 2EA30C00 MOV CS:[000C],AX
0225 B8004C MOV AX,4C00
0228 CD21 INT 21

2728 B44C MOV AH,4C ; "EXIT" command termination
272A 26A0FA0A MOV AL,ES:[0AFA]
272E CD21 INT 21
____________________________________________

0210 0E PUSH CS ; 3.20 Patch
0211 07 POP ES
0212 FC CLD
0213 BE9C0A MOV SI,0A9C
0216 AD LODSW
0217 26A31600 MOV ES:[0016],AX
021B BF0A00 MOV DI,000A
021E A5 MOVSW
021F A5 MOVSW
0220 A0FA0A MOV AL,[0AFA]
0223 B44C MOV AH,4C
0225 90 NOP
0226 90 NOP
0227 90 NOP
0228 CD21 INT 21
__________________________________________________ ____________________________

023A A18C0B MOV AX,[0B8C] ; MS-DOS COMMAND.COM
3.30
023D 2EA31600 MOV CS:[0016],AX
0241 A18E0B MOV AX,[0B8E] ; "/C" termination
0244 2EA30A00 MOV CS:[000A],AX
0248 A1900B MOV AX,[0B90]
024B 2EA30C00 MOV CS:[000C],AX
024F B8004C MOV AX,4C00
0252 CD21 INT 21

2CE8 B44C MOV AH,4C ; "EXIT" command termination
2CEA 26A0EA0B MOV AL,ES:[0BEA]
2CEE CD21 INT 21
__________________________________________

023A 0E PUSH CS ; 3.30 Patch
023B 07 POP ES
023C FC CLD
023D BE8C0B MOV SI,0B8C
0240 AD LODSW
0241 26A31600 MOV ES:[0016],AX
0245 BF0A00 MOV DI,000A
0248 A5 MOVSW
0249 A5 MOVSW
024A B44C MOV AH,4C
024C A0EA0B MOV AL,[0BEA]
024F 90 NOP
0250 90 NOP
0251 90 NOP
0252 CD21 INT 21

------------------------------------------

barry <> wrote:

> Has anyone encountered a problem with the Microsoft C 5.0 compiler always
> returning a 0 from the system() call, no matter what the actual command
> executed by system() returns?

I don't know if this is still true, but at least in the MS-DOS days it
was not system() which had the problem, but the command shell.
Command.com always returned 0 to _its_ calling process, no matter what a
called program returned to command.com. Thus, regardless of the
implementation, system() never got anything but 0 to return to you in
the first place. The compiler writer would have had to implement a
completely new command shell to load and run programs, which was a bit
too hairy for most to bother with.

Richard

On Jun 1, 11:04*am, barry <nos...@nospam.com> wrote:
> Has anyone encountered a problem with the Microsoft C 5.0 compiler always
> returning a 0 from the system() call, no matter what the actual command
> executed by system() returns?
>
> Is there a fix for this or am i misunderstanding something fundamental
> about
> the way the system() call works in msc5.0? *(Like the command.com always
> returning the 0, which system(), in turn, returns to my program?)
>
> I'm trying to determine whether or not the executed command succeeded or
> not by
> looking at the completion code from system, ala:
>
> * * * * char buf[BUFSIZ];
>
> * * * * sprintf(buf,"rnews < D_elricf.3aa");
> * * * * if (!system(buf)) perror(buf);
>
> and i'm having a hard time of it since system() always (seems) to return
> 0!

I ran into this once and frankly can't remember how I fixed it. I do
remember it was ugly. I believe I ended up calling exeve() directly.
Of course you'll have to implement the file redirection yourself if
you do this. But I ran across this recently:
https://briandamaged.org/blog/?p=179
It might offer a solution in the form of a 2-line script that runs a
command and then causes the shell to exit with the current errorlevel
as its return value.

Good luck.

hi can anyone explain how to apply this patch thanks

sandeep wrote:
Kenny McCormack writes:
>> In article <hu37hs$c41$>, barry <>
>> wrote:
>>>Has anyone encountered a problem with the Microsoft C 5.0 compiler
>>>always returning a 0 from the system() call, no matter what the actual
>>>command executed by system() returns?
>>>
>>>Is there a fix for this or am i misunderstanding something fundamental
>>>about the way the system() call works in msc5.0? (Like the command.com
>>>always returning the 0, which system(), in turn, returns to my
>>>program?)
>>
>> Kiki has already given you the "CLC standard" answer, which is, of
>> course, a) entirely correct in all its particulars and b) entirely
>> useless.
>>
>> Now, onto a (hopefully) useful answer. As far as I know, this has
>> never worked correctly (for suitable assumptions about what "correct"
>> means) under DOS/Windows. I.e., the returned value returned by
>> COMMAND.COM/CMD.EXE/whateverElseFromMS tells you only that COMMAND.COM
>> itself succeeded (which is true 99.999999% of the time). This behavior
>> is unlikely to ever change in the Windows product line.
>>
>> In Unix, it does work correctly - that is, sh "passes down" the value
>> returned by the command:
>>
>> $ sh -c 'ls ksdfjh';echo $?
>> ls: ksdfjh: No such file or directory 1
>> $
>>
>> P.S. Once, a long, long time ago, I wrote a DOS device driver to
>> address this problem. It was a little "hinky", but it did work. Was
>> rather cool, in its own little way.
>>
>> P.P.S. The FGA for this sort of problem is to somehow hack the command
>> line that you run so that it indicates the status in some "out of band"
>> way, such as:
>>
>> system("yourcommand & if errorlevel 1 echo Failed > atmpfile");
>>
>> Note that in Unix, you could do: echo $? > atmpfile, but the seemingly
>> equivalent DOS syntax (%errorlevel%) just doesn't quite do it...
>>
>> HTH

No waranties expressed or implied, use at own risk, etc.

I've been using these patches for years with no problems. Source (sort
of)
is included for those worried about virus problems.

(This is from a make package some friends and I wrote a while
ago--ignore any
references to make that didn't get edited out.)

-------------------------------------------------
COMMAND.COM patch to return ERRORLEVEL from child
_________________________________________________

There is a feature (bug) in COMMAND.COM that causes MAKE not to be able
to detect when commands that involve redirection fail. This is because
MAKE executes these commands using a sub-shell and the sub-shell does
not return
the exit code of the command it executed.

What follow are patches for COMMAND.COM version 2.11 (MS only) and
versions
3.20 and 3.30 (MS and IBM versions).


__________________________________________________ ____________________________

Patch to return ERRORLEVEL as exit code when COMMAND.COM terminates.
Note that in 3.20 and 3.30, ERRORLEVEL is already returned correctly
when a
sub-shell is terminated with the EXIT command. This patch does not
cause built-in commands (DEL, etc.) to return failure exit codes.

This patch is valid for MSDOS version 2.11. THIS IS NOT VALID FOR
PCDOS!

0220: B8 00 4C CD 21 MS-DOS 2.11
0AC0: 00 00 00 00 00 00 00 00 COMMAND.COM
19C0: 06 8E 06 BA 2C 26 A1 35 08 26 A3 16 00 07 19D0: 8E 06
BC 2C B4 49 CD 21 B8 00 4C CD 21

0220: E9 9D 08 90 90 2.11 Patch
0AC0: B4 4C 2E A0 75 08 CD 21 19C0:
8E 06 BA 2C 06 B8 C8 0A 50 26 A1 35 08 26 19D0: A3 16 00 8E 06 BC
2C B4 49 CD 21 CB 90
__________________________________________________ _______

This patch is valid for MSDOS and PCDOS version 3.20.

0210: A1 9C 0A 2E A3 16 00 A1 9E 0A 2E A3 0A 00 A1 A0 3.20
COMMAND.COM
0220: 0A 2E A3 0C 00 B8 00 4C

0210: 0E 07 FC BE 9C 0A AD 26 A3 16 00 BF 0A 00 A5 A5 3.20 Patch
0220: A0 FA 0A B4 4C 90 90 90
__________________________________________________ _______

This patch is valid for MSDOS and PCDOS version 3.30.

023A: A1 8C 0B 2E A3 16 3.30
COMMAND.COM
0240: 00 A1 8E 0B 2E A3 0A 00 A1 90 0B 2E A3 0C 00 B8 0250: 00 4C

023A: 0E 07 FC BE 8C 0B 3.30 Patch
0240: AD 26 A3 16 00 BF 0A 00 A5 A5 B4 4C A0 EA 0B 90 0250: 90 90

__________________________________________________ ____________________________

MS-DOS 2.11 COMMAND.COM

0228 B8004C MOV AX,4C00 ; "/C" termination 022B CD21
INT 21

19C2 06 PUSH ES ; "EXIT" command processor
19C3 8E06BA2C MOV ES,[2CBA] ; in transient section 19C7
26A13508 MOV AX,ES:[0835] 19CB 26A31600 MOV
ES:[0016],AX 19CF 07 POP ES
19D0 8E06BC2C MOV ES,[2CBC] 19D4 B449 MOV AH,49
19D6 CD21 INT 21
19D8 B8004C MOV AX,4C00
19DB CD21 INT 21
____________________________________________

MS-DOS 2.11 Patch

0228 E99D08 JMP 0AC8 ; "/C" termination -- jump
to 022B 90 NOP ; exit patch 022C 90
NOP

0AC8 B44C MOV AH,4C ; terminate process with
exit 0ACA 2EA07508 MOV AL,CS:[0875] ; code set to
ERRORLEVEL 0ACE CD21 INT 21

19C2 8E06BA2C MOV ES,[2CBA] ; "EXIT" command in overlay
19C6 06 PUSH ES
19C7 B8C80A MOV AX,0AC8 ; put address of exit patch
in 19CA 50 PUSH AX ; root on stack 19CB
26A13508 MOV AX,ES:[0835] 19CF 26A31600 MOV
ES:[0016],AX 19D3 8E06BC2C MOV ES,[2CBC] 19D7 B449
MOV AH,49
19D9 CD21 INT 21
19DB CB RETF ; jump to exit patch 19DC 90
NOP

__________________________________________________ ____________________________

0210 A19C0A MOV AX,[0A9C] ; MSDOS COMMAND.COM
3.20
0213 2EA31600 MOV CS:[0016],AX 0217 A19E0A MOV
AX,[0A9E] ; "/C" termination 021A 2EA30A00 MOV
CS:[000A],AX 021E A1A00A MOV AX,[0AA0] 0221 2EA30C00
MOV CS:[000C],AX 0225 B8004C MOV AX,4C00
0228 CD21 INT 21

2728 B44C MOV AH,4C ; "EXIT" command termination
272A 26A0FA0A MOV AL,ES:[0AFA] 272E CD21 INT 21
____________________________________________

0210 0E PUSH CS ; 3.20 Patch 0211 07
POP ES
0212 FC CLD
0213 BE9C0A MOV SI,0A9C
0216 AD LODSW
0217 26A31600 MOV ES:[0016],AX 021B BF0A00 MOV
DI,000A
021E A5 MOVSW
021F A5 MOVSW
0220 A0FA0A MOV AL,[0AFA] 0223 B44C MOV AH,4C
0225 90 NOP
0226 90 NOP
0227 90 NOP
0228 CD21 INT 21

__________________________________________________ ____________________________

023A A18C0B MOV AX,[0B8C] ; MS-DOS COMMAND.COM
3.30
023D 2EA31600 MOV CS:[0016],AX 0241 A18E0B MOV
AX,[0B8E] ; "/C" termination 0244 2EA30A00 MOV
CS:[000A],AX 0248 A1900B MOV AX,[0B90] 024B 2EA30C00
MOV CS:[000C],AX 024F B8004C MOV AX,4C00
0252 CD21 INT 21

2CE8 B44C MOV AH,4C ; "EXIT" command termination
2CEA 26A0EA0B MOV AL,ES:[0BEA] 2CEE CD21 INT 21
__________________________________________

023A 0E PUSH CS ; 3.30 Patch 023B 07
POP ES
023C FC CLD
023D BE8C0B MOV SI,0B8C
0240 AD LODSW
0241 26A31600 MOV ES:[0016],AX 0245 BF0A00 MOV
DI,000A
0248 A5 MOVSW
0249 A5 MOVSW
024A B44C MOV AH,4C
024C A0EA0B MOV AL,[0BEA] 024F 90 NOP
0250 90 NOP
0251 90 NOP
0252 CD21 INT 21

------------------------------------------