Path: utzoo!mnetor!uunet!nbires!maa
From: maa@nbires.nbi.com (Mark Armbrust)
Newsgroups: comp.sys.ibm.pc
Subject: Re: EXEC call (was: Re: shell script program for pc)
Message-ID: <1246@nbires.nbi.com>
Date: 7 Feb 88 17:01:54 GMT
References: <2638@cup.portal.com> <5706@eecae.UUCP> <19318@bu-cs.BU.EDU> <2890@cup.portal.com> <2026@bsu-cs.UUCP> <19737@bu-cs.BU.EDU>
Reply-To: maa@nbires.UUCP (Mark Armbrust)
Organization: NBI Inc, Boulder CO
Lines: 22

In article <19737@bu-cs.BU.EDU> madd@bu-it.bu.edu (Jim Frost) writes:
>If you parse the command line and build FCB's, then all the MS-DOS
>utilities will work. CHKDSK and FORMAT both use the FCB "drive" field
>to determine which drive to use, instead of going to the extra effort
>of parsing out the drive name from the command line.  Sort of a short
>cut.

Also note that unless you immediately follow the command with the switch
character (i.e. "COPY/B ...") there will be a space as the first character
in the unformatted arguments string.  When I was working on a make utility
the 'cl' (4.0) command was sometimes blowing up in strange ways and I
tracked it down to this missing space.  Incidently, the same arguments
passed from command.com as "CL/..." also blew up the compiler.  [Sorry I
can't remember a specific example, it was quite a while ago.]

Some tools ignore the character count byte and scan the argument string until
they find a 0x0D byte (return).  Command.com puts this byte after the argument
string and it IS NOT INCLUDED in the character count byte.

Hope this helps.

Mark