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"
I think that is also wrong. The method I described handles virtually>>>implemented with lib$spawn?another is long command lines don't work. I suspect "system" is
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?
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 [EMAIL PROTECTED] Personal Opinion Only
