Re: "system" long commands and stderr redirection.

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:

While I do not know what the Perl system function is doing, it would 
look to me that it is simply passing the command through as a DCL 
command, and as such is not attempting to interpret the redirection 
codes at all.

> 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.

I will have to confess that I know little of bash, m4, or perl.

However, it now appears that the redirection is being done by bash 
instead of md4 or dcl.

The system function appears to assume that the underlying operation 
system will understand the quoted command, and makes no attempt to 
process it.

The question is is if the command:

  m4 --help </dev/null 2>&1 | grep reload-state >/dev/null

will work under DCL.


The behavior seems to be explained in these comments in VMS.C.

 * Note on command arguments to perl 'exec' and 'system': When handled
 * in 'VMSish fashion' (i.e. not after a call to vfork) The args
 * are concatenated to form a DCL command string.  If the first arg
 * begins with '$' (i.e. the perl script had "\$ Type" or some such),
 * the command string is handed off to DCL directly.  Otherwise,
 * the first token of the command is taken as the filespec of an image
 * to run.  The filespec is expanded using a default type of '.EXE' and
 * the process defaults for device, directory, etc., and if found, the
   resultant
 * filespec is invoked using the DCL verb 'MCR', and passed the rest of
 * the command string as parameters.  This is perhaps a bit complicated,
 * but I hope it will form a happy medium between what VMS folks expect
 * from lib$spawn and what Unix folks expect from exec.

So it appears one way to implement what you may need is a modification 
for Perl for VMS to use the BASH shell instead of DCL, or to run the 
program with out a shell at all.

Maybe one of the Perl maintainers can figure out a patch.

Perl can detect if it is running under bash and should use it instead 
DCL by looking at the environment variable "SHELL" to see if perl is 
being run under "bash"

> > > > > 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.

The DCL line length has not been completely removed.  And i was in 
error.  The new line lengths are in 7.3-2.

A line can now be 4095 bytes in length.  Perl has an internal limit of 
(4*MAX_DCL_SYMBOL-4) for the line lengths and since MAX_DCL_SYMBOL is 
255, this limits it to 1016 characters.

With VMS 7.3-2 and later on Alpha/IA64 DCL symbols are limited to 8192 
bytes, and previously they are limited to 1024 bytes.

As I do not know the history of the perl limitations, I do not know what 
would have to be changed to have them take advantage of the new size.

-John
wb8tyw@xxxxxxx
Personal Opinion Only