sommar@enea.se (Erland Sommarskog) (04/30/91)
Also sprach Ralph Reid III (rreid@ecst.csuchico.edu): >I have played around with command line parameters in Ada a little, >and there does not seem to be a standard technique for reading them. >Several pieces of source code seem to be floating around, and two >examples came with the Meridian Adavantage compiler I have. Perhaps >a standard should be considered for Ada9x? Undoubtedly it would be pleasant if all Ada compilers on Unix were interchangeable on argv/argc, but that something like a POSIX binding not Ada 9X. Since you retrieve the arguments differently in different OSs, reading the command line is something which by definition is not portable(*) so it can't be in the language. Remember that the command-line interface itself is OS dependent. (*) Yes, I know that argc/argv is commonly available with C implementations. But if you're going to get the command-line interface right in, say, VMS, you better use the CLI$ routines. -- Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se Le fils du maire est en Normandie avec beaucoup de medecins.
rharwood@east.pima.edu (04/30/91)
In article <3275@enea.se>, sommar@enea.se (Erland Sommarskog) writes: > Undoubtedly it would be pleasant if all Ada compilers on > Unix were interchangeable on argv/argc, but that something > like a POSIX binding not Ada 9X. > > Since you retrieve the arguments differently in different OSs, > reading the command line is something which by definition is > not portable(*) so it can't be in the language. Remember that > the command-line interface itself is OS dependent. > > (*) Yes, I know that argc/argv is commonly available with C > implementations. But if you're going to get the command-line > interface right in, say, VMS, you better use the CLI$ routines. Erland, I agree 100%. Here's perhaps some more "justification". Perhaps the "correct" way for portability would be to write a package for EACH PROGRAM (or system) that has functions which return the possible values of switches and other command line "entries", like the following parameters for a PC-based file DUMP routine I recently wrote: type bases is (hex, ascii, octal); function address_format return bases; function file_to_dump return string; Then your "main" routine calls these functions, no matter what the external environment is. NOW comes the "non-portable" interface, where the actual BODIES of those functions above must call the OS-specific routines to determine the command line arguments. It would conceptually be possible to write two external interface routines: (1) one which works under the "unit test" mode and runs on the "host" system such as the VAX or PC-compatible (2) another which runs only on the target hardware, perhaps an embedded 80186 or 1750A machine. Ada is NOT the first language where information hiding has advantages... We must THINK in terms of portability and encapsulation during DESIGN. At CODE time is too late! <"plop-plop"... stepping of off soap box> Ray ----- Ray Harwood |Data Basix |Associate Faculty, Voice: (602)721-1988 |PO Box 18324 | Pima Community College FAX: (602)721-7240 |Tucson, AZ 85731 |Instructor in Ada and Pascal CompuServe: 76645,1370|AppleLink: DATA.BASIX|Internet: rharwood@east.pima.edu
sag@iplmail.orl.mmc.com (Steve Gabrilowitz) (04/30/91)
In article <3275@enea.se>, sommar@enea.se (Erland Sommarskog) writes: |> |> Since you retrieve the arguments differently in different OSs, |> reading the command line is something which by definition is |> not portable(*) so it can't be in the language. Remember that |> the command-line interface itself is OS dependent. |> |> (*) Yes, I know that argc/argv is commonly available with C |> implementations. But if you're going to get the command-line |> interface right in, say, VMS, you better use the CLI$ routines. Not exactly true. The argc/argv will work fine under VMS without using the CLI$ routines if the program is invoked via a symbol: $ TESTP :== $SYS$USER:[STEVE]TESTP.EXE $ TESTP 1 2 3 Your statement is correct only if the program is installed as a command using a .CLD file and $ SET COMMAND and all that junk. No matter, if Ada had some construct defined as a part of the language which would retrieve the commmand line parameters nothing would prevent the compiler writers from implementing whatever it was on VMS by internally calling the appropriate CLI$ functions - and isn't that part of what Ada is all about, providing a programming environment which is uniform and consistent over different platforms? The only problem I see with putting access to the command line into the Ada language is how it would be handled on embedded real time systems where the OS doesn't provide any mechanism for getting at the command line - indeed, there isn't even a command line to get at ;-) Perhaps this could best be handled by providing a recommended "standard" for getting the command line in Chapter 13? -- Steve Gabrilowitz Martin Marietta, Orlando Fl. sag@iplmail.orl.mmc.com Fidonet 1:363/1701
sampson@cod.NOSC.MIL (Charles H. Sampson) (05/02/91)
In article <1991Apr30.135735.1211@iplmail.orl.mmc.com> sag@iplmail.orl.mmc.com (Steve Gabrilowitz) writes: > ... if Ada had some construct defined as a part of the language >which would retrieve the commmand line parameters nothing would prevent >the compiler writers from implementing whatever it was on VMS by internally >calling the appropriate CLI$ functions - and isn't that part of what Ada >is all about, providing a programming environment which is uniform and >consistent over different platforms? > >The only problem I see with putting access to the command line into the >Ada language is how it would be handled on embedded real time systems where >the OS doesn't provide any mechanism for getting at the command line - >indeed, there isn't even a command line to get at ;-) > >Perhaps this could best be handled by providing a recommended "standard" >for getting the command line in Chapter 13? This issue was discussed a few months ago and I'll repeat the same point I tried to make then. Suppose there were a standard Ada technique for accessing command line parameters. What would it gain you? You could get at the parameters, but they would be different on different operating systems, so the code to process those parameters would not be transportable. In saying this I assume that you want the parameters in the VMS version of your program to be VMS-like, and in the UNIX version to be UNIX-like. If this assumption is wrong we can argue about it, but the issue is then user interface, not Ada. I've now directed the implementation of several small multi-platform programs written in Ada and the approach that I've used is one suggested by another responder: The information obtained from the command line parameters is abstracted in a package specification; that package's body is rewritten for each environment. One of these programs was ported to an environment that does not have command line parameters and the package body in this case implemented a set of hierarchical menus to obtain the required information. Charlie
joeo@masscomp.westford.ccur.com (Joe Orost) (05/02/91)
In article <3034@cod.NOSC.MIL> sampson@cod.NOSC.MIL (Charles H. Sampson) writes: > Suppose there were a standard Ada technique >for accessing command line parameters. What would it gain you? You >could get at the parameters, but they would be different on different >operating systems, so the code to process those parameters would not be >transportable. > > In saying this I assume that you want the parameters in the VMS >version of your program to be VMS-like, and in the UNIX version to be >UNIX-like. If this assumption is wrong we can argue about it, but the >issue is then user interface, not Ada. The C language forces the UNIX style of command arguments onto different systems, and in doing so, has achieved a certain level of portability. Why can't the Ada language do the same thing (or even follow C's lead and also specify the UNIX conventions)? [In fact, POSIX/Ada provides this.] Aren't all future operating systems UNIX based, anyway :-) ? regards, joe -- Full-Name: Joseph M. Orost Email: joeo@tinton.ccur.com Phone: (908) 758-7284 Fax: (908) 758-7113 US Mail: MS 322; Concurrent Computer Corporation; 106 Apple St Tinton Falls, NJ 07724
sommar@enea.se (Erland Sommarskog) (05/07/91)
Also sprach Steve Gabrilowitz (sag@iplmail.orl.mmc.com): )I said: )|) (*) Yes, I know that argc/argv is commonly available with C )|) implementations. But if you're going to get the command-line )|) interface right in, say, VMS, you better use the CLI$ routines. ) )Not exactly true. The argc/argv will work fine under VMS without using the )CLI$ routines if the program is invoked via a symbol: ) )$ TESTP :== $SYS$USER:[STEVE]TESTP.EXE )$ TESTP 1 2 3 And then Joe Orost (joeo@masscomp.westford.ccur.com) raised his voice: )The C language forces the UNIX style of command arguments onto different )systems, and in doing so, has achieved a certain level of portability. ) )Why can't the Ada language do the same thing (or even follow C's lead )and also specify the UNIX conventions)? [In fact, POSIX/Ada provides this.] This isn't really an Ada issue, so be careful when/if you followup. As a person living with Unix as a your every-day world, would you fancy a facility with options like /[NO]QUALIFIER=KEYWORD? Give me an VMS utility where I'm supposed to give qualifiers as -d2, and if looks could kill you would be a dead man. Portability is a virtue but user-friendliness and conformance to the environment conformance are higher virtues. That's why you should not use argv/argc on VMS (unless you really want do CDU parsing on your own), but use the CLI$ routines instead. -- Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se WORLD CHAMPIONS IN ICE HOCKEY 1991 - S W E D E N!