> Very interesting. So gcc on VMS is under active development? Absolutely. My company is working on the IA64 VMS port of GNAT under contract to HP. GNAT as you may know, is the Gnu Ada compiler and Gnu C is required to build the backend. I don't really recommend Gnu C for serious development on VMS, since its not compatible with the standard DEC C header files. Only the ones needed for building GNAT and bootstrapping Gnu C have been ported.
> >The latter version uses Perl. So far I've run into two problems with the > >Perl "system" function. One is stderr can't be redirected properly, > > Define "properly". What do you want it to do and what does it do instead? For example this command: system "$m4 --help </dev/null 2>&1 | grep reload-state >/dev/null"; writes the "help" output to the screen, when it should be going to /dev/null. > > >another > >is long command lines don't work. I suspect "system" is implemented with > >lib$spawn? > > Yes, system is implemented via lib$spawn, so as far as I know, > there's no way around DCL command line limits. You can see the > implementation in the Perl_do_spawn() function in [.vms]vms.c in the > Perl sources. > > >I believe that a better solution would be for "system" to look at the > >program(s) being executed, and if they are CRTL based executables then > >vfork/exec should be used, otherwise falling back to lib$spawn. This is what > >my ports of bash and Gnu make do, and it works quite well. > > That's intriguing. I take it by a "CRTL based executable" you mean one > that calls DECC$CRTL_INIT? How do you determine that at run time? There are a couple of ways to check, by looking at the location of the executable (e.g. /gnu/bin) or by looking at some bits in the header. That's the easy part. > Also, you seem to be suggesting that vfork/exec do not use lib$spawn. > Any idea how they create a subprocess if they don't do that? Exec uses lib$spawn but CRTL also sets up some piping infrastructure. The basic idea is to do redirect stdin, stderr, stdout as needed to temporary files to read and write the command line as needed for communicating it to the next process in the pipeline. The temporary files can be created on a ramdisk to give reasonable performance. Unfortunately its not possible to uses pipes directly due to the semantics of vfork on VMS. It gets kind of messy but I can give you the code from bash that does it. > Patches are welcome, but an overhaul of system() does not sound > particularly easy, so I would like to understand a bit more about how > your approach works. Are the bash or make implementations you > mention above open source? I used to have an anonymous ftp site and some of my Gnu tools for VMS made their way eventually to DEC->Compaq->HP and I think now reside on sourceforge.net. They cleaned up and rewrote the VMS specific piping in bash, and ended up breaking some things. I've sent them a few bug reports but I don't know if they ever got fixed.
