ubi@sri-unix.UUCP (06/09/87)
In article <552@unc.cs.unc.edu> mcguffey@unc.UUCP (Michael McGuffey) writes: > >funny that they would claim in the VAX C ref manual that >they want to maintain compatibility with unix c but >have such a glaring bug. > Speaking of glaring, why did DEC decide not to implement system() under VMS??? It's bad enough that I can't exec anything except C programs. I hate having to work under VMS, but if I could say system("@foo bare"); , or system("show time"); , or even system("run $disk:[mydir]foo"); , I'd stop complaining for a few hours, anyway. Help, please. --Ron Ueberschaer SRI International Menlo Park, CA ...!{hplabs,rutgers}!sri-unix!ubi ubi@sri-unix.UUCP
Liebschutz@BIONET-20.ARPA.UUCP (06/09/87)
From the Vaxc version 2.3 release notes:
The following VAX C Run-Time Library functions are available with V4.6
of VMS. For more information on each of these functions, see the VAX
C Run-Time Library Reference Manual.
o The system function, which passes a command string to be
executed by the command processor.
Rob Liebschutz
LIEBSCHUTZ@BIONET-20.ARPA
-------campbell@maynard.UUCP (06/10/87)
You can use LIB$SPAWN. The calling sequence isn't *quite* as convenient,
but other than that it will do the job.
--
Larry Campbell The Boston Software Works, Inc.
Internet: campbell@maynard.BSW.COM 120 Fulton Street, Boston MA 02109
uucp: {husc6,mirror,think}!maynard!campbell +1 617 367 6846stevesu@copper.UUCP (06/10/87)
In article <3322@sri-unix.ARPA>, ubi@sri-unix.ARPA (Ron Ueberschaer) writes: > Speaking of glaring, why did DEC decide not to implement system() > under VMS??? It's bad enough that I can't exec anything except > C programs. I suspect they left it out because you probably don't want to use it. The only way to implement system() is with lib$spawn(), which is notoriously slow. Here's one I use, which I call "vmssystem" so that I have to think about it before using it. (A program containing "system" won't automatically link, without some attention.) Besides thinking about whether you can afford to spend several seconds in a lib$spawn, you may also need to change the string actually passed to system(), which is usually a Unix command of some sort. (For example, just because you had a working "system" wouldn't mean that you could port the tar utility, which contains this gem: sprintf(buf, "sort +0 -1 +1nr %s -o %s; \ awk '$1 != prev {print; prev=$1}' %s >%sX; mv %sX %s", tname, tname, tname, tname, tname, tname); system(buf); Steve Summit stevesu@copper.tek.com #define NULL 0 struct descriptor { short dsc_length; char dsc_type; char dsc_class; char *dsc_addr; }; vmssystem(command) char *command; { int r; long int status; struct descriptor vmscmd; vmscmd.dsc_addr = command; vmscmd.dsc_length = strlen(command); vmscmd.dsc_type = vmscmd.dsc_class = 0; r = lib$spawn(&vmscmd, /* command string */ (struct descriptor *)NULL, /* input file */ (struct descriptor *)NULL, /* output file */ (long int *)NULL, /* flags */ (struct descriptor *)NULL, /* process name */ (long int *)NULL, /* process id */ &status, /* completion status */ (unsigned char *)NULL, /* completion efn */ (int (*)())NULL, /* completion astadr */ 0, /* completion astarg */ (struct descriptor *)NULL, /* prompt */ (struct descriptor *)NULL); /* CLI */ if(!(r & 01)) return -1; return status; }
LEICHTER-JERRY@YALE.ARPA.UUCP (06/11/87)
...
Speaking of glaring [failures to emulate Unix], why did DEC decide not
to implement system() under VMS??? It's bad enough that I can't exec
anything except C programs. I hate having to work under VMS, but if I
could say
system("@foo bare"); ,
or
system("show time"); ,
or even
system("run $disk:[mydir]foo"); ,
...
The purpose of VAX C's emulation of the Unix library is primarily to allow
Unix code to be ported to VMS as easily as possible. Any Unix program that
uses system() is applying it to a shell command, which isn't likely to work
on VMS anyway.
Besides, it's pretty easy to implement system() on top of LIB$SPAWN; I've
included code below.
Given the history of the VAX C RTL, which has picked up more and more Unix
emulation functions as time has gone on, a version of system() could easily
show up at some point - i.e., this could be simply a matter of implementation
priorities. Should this happen, the enclosed code would become obsolete,
and you should get rid of it. (Note that the VAX C RTL ships with VMS these
days, so you have to watch the VMS release notes.) The code could be sped
up (considerably), and still do what you usually want it to do, by including
such flags as NOCLISYM and NOLOGNAM, thus eliminating the possibly long wait
while DCL copies over all your defined symbols and process logicals. The
current code, while slower, is more general, since it allows you to SPAWN
commands you've defined in DCL.
I'd stop complaining for a few hours, anyway.
Amazing. A Unix programmer who'll stop complaining about VMS, even if only
for a few hours. It's just because of that promise that I've enclosed this
code.... :-)
-- Jerry
---------------------------------Cut here-------------------------------------
/*-----------------SYSTEM emulation-------------------------------------
*
* Executes the VMS DCL command in string command_line.
* The command may ask the terminal for further input.
* After the VMS command exits, control is returned to the calling
* function.
*
* Example:
* system("show def");
*
* Beware: This call is painfully slow on a loaded system
*
* for VAX-VMS 4-Nov-85 J. Faricelli
* modified 2-Dec-85 J. Faricelli (allow command to ask for input)
*
*----------------------------------------------------------------------*/
#include stdio.h
int system(command_line)
char *command_line;
{
#include descrip /* VMS descriptors header file */
#include ssdef /* VMS system call header file */
static $DESCRIPTOR(spawn_line,"");
int lib$spawn();
int spawn_flags, spawn_rc, i;
unsigned int len;
char *string;
/* Create local storage for command line */
len = strlen(command_line);
string = (char *) malloc(len);
strncpy(string,command_line,len);
/* VMS doesn't grok a newline at the end of the string,
so don't send that to spawn (make it a blank). */
/* command_line[len-1] is end of string (remember, index is
0..len-1) */
if ( command_line[len-1] == '\n' ) {
string[len-1] = ' ';
}
/* Prepare descriptor for call to spawn */
spawn_line.dsc$w_length = len;
spawn_line.dsc$a_pointer = string;
spawn_flags = 0;
spawn_rc = lib$spawn(&spawn_line,&0,&0,&spawn_flags);
if( spawn_rc != SS$_NORMAL ) {
fprintf(stderr,"Internal error in VMS emulation of system() call\n\
Error during spawn of subprocess:\n\
VMS return code was: %d\n",spawn_rc);
free(string);
return(-1);
}
free(string);
return(0);
}
-------ed@qtc.UUCP (06/12/87)
Well I just rec'vd VAX C v2.3. The release notes mention'd that the compiler
is closer to home (sys v) BUT the libraries are not available until VMS 4.6
which is not yet shipping (of some kind of 'soft' hold).
Anyway the "system()" function is just one of the new functions.
Complaints:
1. WHY should layered products become dependant on the version
of VMS. BAD.
2. Release notes are part of the installation procedure and no
longer (for some time now) on hard copy. Hey DEC, how do
we know if this product should be installed or not. If
you are telling us that VMS 4.6 is required to make use
of VAX C 2.3, then I would not have installed this version
yet. Now your support group is saying that we should
actually wait for VMS to catch up. BAD.
3. It turns out that VMS HELP is not updated with the release
notes anyway, although SYS$HELP:VAXC023.RELEASE_NOTES
has the info.
4. The documentation is now two binders instead of one. You
give us one (the new style) binder and expect us to use
the older binder for the other. I don't mind, but the
older binder does not hold the "smaller" binder label.
This may seem petty and it really is but hey. We pay
up the nose for DEC products so why not perfection.
I do like DEC products but when I buy a compiler or any product, that is
what I want. Not parts and pieces.
+------------------------------------------------------------+
| Ed Lisle | ogcvax! |
| Quantitative Technology Corporation | verdix! qtc!ed |
| Beaverton, OR (503) 626-3081 | sequent! |
+------------------------------------------------------------+DHASKIN@CLARKU.BITNET.UUCP (06/16/87)
> Date: 12 Jun 87 17:08:22 GMT > From: Ed Lisle <VRDXHQ!VERDIX!QTC!ED@SEISMO.CSS.GOV> > Subject: Re: Why no system() under VAX C > > Well I just rec'vd VAX C v2.3. The release notes mention'd that the > compiler is closer to home (sys v) BUT the libraries are not available > until VMS 4.6 which is not yet shipping (of some kind of 'soft' hold). > > Anyway the "system()" function is just one of the new functions. > > Complaints: > > 1. WHY should layered products become dependant [sic] on the version of > VMS. BAD. Layered products have varying degrees of dependence on VMS itself and in general have to reflect changes to the operating system. I can understand why it may become necessary for them to have some dependence on VMS; the problem here seems to be that VMS 4.6 should have been released before C 2.3 and 4.6 has been held for some reason or another. DEC is out of sync. It would be interesting to know, though, why language-sepecific libraries are being tied to VMS... it may be that library maintenance and development is a responsibility of the VMS team rather than, say, the C team? Can anyone shed any light? > 2. Release notes are part of the installation procedure and no longer (for > some time now) on hard copy. Hey DEC, how do we know if this product > should be installed or not. If you are telling us that VMS 4.6 is required > to make use of VAX C 2.3, then I would not have installed this version yet. > Now your support group is saying that we should actually wait for VMS to > catch up. BAD. Most products now also support the OPTIONS N switch on VMSINSTAL, which will only fetch the release notes from the installation kit and make them available to you, without having to perform the installation. I personally prefer this method, as I used to keep misplacing the hardcopy release notes. Now I just OPTION N them onto disk and print a new copy when I lose the old one. If the product does not yet support OPTIONS N, one can also use OPTIONS G to pull the installation save sets onto disk and use BACKUP to pull the release notes manually from the save sets. % Denis W. Haskin Manager, Technical Services % % ----------------------------------------------------------------------- % % DHASKIN@CLARKU.BITNET Office of Information Systems (617)793-7193 % % Clark University 950 Main Street Worcester MA 01610 % % % % "Anyone who _moves_ before Most Holy comes back out will spend the rest % % of eternity sipping lava through an iron straw." - Cerebus %
carl@CITHEX.CALTECH.EDU.UUCP (06/18/87)
>> 1. WHY should layered products become dependant [sic] on the version of >> VMS. BAD. > Layered products have varying degrees of dependence on VMS itself and in > general have to reflect changes to the operating system. I can understand > why it may become necessary for them to have some dependence on VMS; the > problem here seems to be that VMS 4.6 should have been released before C > 2.3 and 4.6 has been held for some reason or another. DEC is out of sync. > It would be interesting to know, though, why language-sepecific libraries > are being tied to VMS... it may be that library maintenance and development > is a responsibility of the VMS team rather than, say, the C team? Can > anyone shed any light? The VAXCRTL no longer qualifies as simply a "language-specific library"; you get VAXCRTL whether or not you buy VAXC as a layered product: it is a part of vanilla VMS. As to why DEC can't just release the new VAXCRTL, independent of the new VMS release, there's always the possibility that it's got changes in it that reflect changes in VMS itself, and that it can't be reliably used under VMS 4.5: DEC does a pretty good job of keeping their software products upward compatible, but downward compatibility's another matter entirely. If the VAXCRTL references another shared image (which it certainly does), then you can't use the new C library until you have, say, the new RMS release, which depends on things like ACP's and XQP's, and so forth. All you'd get for your troubles would be an ident mismatch between libraries.
weaver@prls.UUCP (06/19/87)
With most of the VMS languages, the libraries are distributed with the operating system. This was not done with VMS C at first, probably because of the number of fixes required on a new product. The disadvantages I see in this is that if a change in a compiler requires a change in the libraries, then a release of the compiler may have to wait for a release of the operating system, and that now the programmer has to think more about the difference between the library calls and the compiler. It sounds like a bug was found too near the release date to hold up VMS. The advantage is that changes in the operating system which require changes in the libraries cause no problem with release dates. My feeling is that there is more dependancies between the libraries and the operating system than between the libraries and the compilers, so fewer problems come up doing things this way. Another reason for tying the libraries to the operating system is to allow more sharing of the code. The libraries for various languages can be combined into shared segments for efficiency, and more of the routines called from the library routines can be shared among the languages. If shared segments were distributed with the language updates, users who do not pay for the compilers but receive binaries (e.g. application programs from third parties) would have to get new shared segments every time they got a new binary created by a different version of the compiler. Also, the shared segments would have to be parted out by language, or there would be even more trouble synchronizing releases. -- Michael Gordon Weaver Usenet: ...pyramid!prls!weaver Signetics Microprocessor Division 811 East Arques Avenue Sunnyvale, California USA 94088-3409 Phone: (408) 991-3450
LEICHTER-JERRY@YALE.ARPA (06/19/87)
1. WHY should layered products become dependant on the version
of VMS. BAD.
Two reasons: (a) The layered product often depends on features new to some
particular version of VMS; (b) in the particular case of the VAX C OTS (and
other language OTS's), the OTS code ships with ALL VMS systems, so that you
can compile a C program and then run it on ANY VMS system, whether that system
has VAX C on it or not. (This has always been the case for VMS languages
other than C; but C Version 1 didn't ship its OTS with VMS. You then had
trouble - some technical, some licensing - moving compiled C code to systems
that didn't have the C compiler. Bad news.)
The alternative is to ship the OTS with BOTH the layered product AND VMS.
This leads to all sorts of unpleasantnesses, as it becomes much more difficult
to determine what works on what system, and what should be installed on what
system. For example, if the VAX C V2.3 kit containing the same OTS that
shipped with VMS V4.6 were installed on a V4.7 (or whatever) system, it would
replace a newer, presumably improved version of the OTS with an older one.
Despite the problems, this HAS been done on occasion, probably in cases where
new compiler features were so closely tied to new OTS features that it was
pointless to use the new compiler with the old OTS. That's not the case with
VAX C - the new compiler will work perfectly well with the old OTS, since they
are not really too closely coupled.
2. Release notes are part of the installation procedure and no
longer (for some time now) on hard copy. Hey DEC, how do
we know if this product should be installed or not. If
you are telling us that VMS 4.6 is required to make use
of VAX C 2.3, then I would not have installed this version
yet. Now your support group is saying that we should
actually wait for VMS to catch up. BAD.
When you try to install the product, you are asked whether you want to actully
install it, print the release notes, or both. Just ask for "release notes
only". (There may even be a VMSINSTAL option that does this - I don't remem-
ber.)
The advantage of having the release notes on the kit, instead of in printed
form, is that they can be more up to date - getting stuff printed has a long
lead time, but if you've changed ANYTHING on the kit, you have the opportunity
to change the release notes, too.
-- Jerry
-------