----- Original Message ----- From: "Craig A. Berry" <[EMAIL PROTECTED]> To: "Douglas B Rupp" <[EMAIL PROTECTED]> Cc: "John E. Malmberg" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: 23 April 2004 22:11 Subject: Re: "system" long commands and stderr redirection.
> > At 11:18 AM -0700 4/23/04, Douglas B Rupp wrote: > > > > 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. > >> > >> That may need to be handled by GNV, or HP C RTL folks as the redirection > >> is being handled by m4, presumably a C program in GNV, not by the Perl > >> system function. > > > >I think that is wrong. The Perl system function should handle redirection > >that same on Unix as it does on VMS. I was able to work around the problem > >by rewriting the above as the following: > > > >system "bash -c \"$m4 --help </dev/null 2>&1 | grep reload-state > >>/dev/null\""; > > > >which demonstrates the problem doesn't need to be handled by m4. > > Perl's system function doesn't handle redirection on any platform; > that's normally something the command shell does (or doesn't do). > There are some programs on VMS that do their own redirection and Perl > is one of them, but that would only help with Douglas's problem in > the special case of Perl being the program run in the subprocess. m4 > could be made to do the same thing by commandeering its main() > function, but that's not a very good general solution. > > The Perl documentation on system() says that it runs execvp() unless > "shell metacharacters" are present, in which case it runs the shell > to execute the command. I would certainly expect redirection symbols > to be considered shell metacharacters, so a command that has > redirection is likely to be run through the shell on any platform. > The way I see the problem is that we are running the command under > the wrong shell (DCL instead of bash). One possibility here would be > to have Perl detect whether it is running under bash and if it is, > then prepend bash to the command for system(), exec(), and backtick > operations. I agree. There also may be plenty of existing VMS Perl scripts that rely on DCL being called. Rather than change how the perl core behaves, it would seem a better idea to provide a module: use vmsish::ShellSpawns; > Better yet, if there were some way to make bash a true-blue CLI from > a VMS standpoint, then lib$spawn would automatically use whatever CLI > is in use by the parent. That's out of my league and I have no idea > how possible or difficult that would be. This would be dependent on those guys at HP changing the behaviour of lib$spawn. Don't hold your breath ;). > The fact that we always use lib$spawn and never use execvp() like the > docs say we should do is a separate but related problem. Switching > to use execvp() when we can would not, as far as I can tell, help > with redirection. There is nothing in the CRTL docs about > redirection operators being supported as arguments to the exec() > family. There is an alternative to execvp and lib$spawn; this involves going to a lower level of call - to the underlying VMS system services. This also overcomes the line length problem. I would suggest parsing out the redirects inside perl, so we know where sys$input, sys$output and sys$error want to go, then passing these to XS. In the XS code, if any of these are pipes, call sys$crembx to set up mailboxen (the equivalent of pipes). Finally, call sys$creprc to create the VMS process. Sadly I don't have the time or the environment to develop this :(. Ivor.
