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. 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. 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. > > > >>>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. >> >> The line limits are increased in 8.2, do you have access to the >> pre-release code before the field test? > >I think that is also wrong. The method I described handles virtually >unlimited command line lengths. Unless the DCL command line length liimit >has been completely removed (which I find very unlikely but maybe worth >asking about), it won't be enough for other than trivial scripts. POSIX specifies a 2K limit for the shell command buffer, though I believe many unices support more or even have no concrete limit. I have no idea what bash on VMS supports. The cases you are talking about that can be done with the exec() family probably can bypass that limit, but strictly speaking they aren't really commands; they are images invoked with C-style argv arrays passed to them. Distinguishing between when you can use exec() and when not strikes me as a bit tricky; it's hard to parse a shell command (or determine whether it even is a shell command) without using the command shell to do it. This is all highly interesting but not easy to act on quickly. I will try to have a look at how bash in GNV handles redirection and how other platforms use execvp() for Perl's system(). -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
