Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!unmvax!nmt.edu!jrwsnsr
From: jrwsnsr@nmt.edu (Jonathan R. Watts)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Long command lines
Message-ID: <1990Sep27.044522.8475@nmt.edu>
Date: 27 Sep 90 04:45:22 GMT
References: <7658@hydra.Helsinki.FI>
Organization: New Mexico Institute of Mining and Technology
Lines: 28

From article <7658@hydra.Helsinki.FI>, by kankkune@cs.Helsinki.FI (Risto Kankkunen):
> I think most of the programs are written in high level languages, like
> C and Pascal. In these languages you don't access the command line
> directly. Instead, the startup code parses it and separates to
> parameters. You access these via the argv array in C and ParamStr in
> TP.
> 
> So, every program written in high level language parses the command
> lines, and makes lots of unnecessary assumptions, before the program
> gets them. If the command line is passed in parameters, it is the shell,
> and ultimately the user that makes the assumptions and decisions.

I use Turbo Pascal 5.5, and while it does have ParamStr to return your
command line arguments, I decided to write my own command-line parser
instead.  This way, I can parse the command-line in whatever fashion I
like.  For example, at the moment, my parser will check if 4DOS is the
parent shell, and if so, it will use the environment variable CMDLINE
instead of the passed command-line; the great thing about this is that
it is completely transparent...if the program wasn't loaded by 4DOS, it
just ignores the environment, even if a CMDLINE variable is present.
It works great!  I've picked up some good ideas to add to my parser from
this thread, too, such as the @<filename> expansion.  (BTW, if anyone wants
a copy of my parser, feel free to mail me; it's implemented as a TP 5.5
unit.)
 
  - Jonathan Watts
 
jrwsnsr@jupiter.nmt.edu (Internet address)