From @nwc10

As you might be able to infer from the missing header, I couldn't get
perlbug to run properly on VMS, as I couldn't figure out the name of and
editor which would work.

system LIST on VMS appears to split on all spaces. Contrast​:

$ perl -w
system 'perl', '-le', 'print@​ARGV', 'a', 'b c'
__END__
abc
$ perl -w
system 'perl', '-le', 'print @​ARGV', 'a', 'b c'
__END__

$

This appears not to be documented as a limitation in pod/perlport.pod

Is it a bug which can be fixed, or does it need to be documented as a
portability limitation?

Nicholas Clark

Flags​:
  category=core
  severity=low

Site configuration information for perl 5.19.3​:

Configured by nclark at Mon Jul 29 13​:08​:35 UTC+5​:30 2013.

Summary of my perl5 (revision 5 version 19 subversion 3) configuration​:
 
  Platform​:
  osname=VMS, osvers=V8.4, archname=VMS_IA64
  uname='VMS ptac V8.4 HP rx2600 (1.30GHz/3.0MB)'
  config_args='-"des" -"Dusedevel"'
  hint=none, useposix=false, d_sigaction=define
  useithreads=undef, usemultiplicity=undef
  useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
  use64bitint=undef, use64bitall=undef, uselongdouble=undef
  usemymalloc=undef, bincompat5005=undef
  Compiler​:
  cc='CC/DECC', ccflags ='/Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj /NOANSI_ALIAS/float=ieee/ieee=denorm/NAMES=(SHORTENED)/Define=_USE_STD_STAT=1',
  optimize='/NoList',
  cppflags='undef'
  ccversion='70390019', gccversion='', gccosandvers='undef'
  intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
  ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
  alignbytes=8, prototype=define
  Linker and Libraries​:
  ld='Link/nodebug', ldflags ='/NoTrace/NoMap'
  libpth=/sys$share /sys$library
  libs=
  perllibs=
  libc=(DECCRTL), so=exe, useshrplib=true, libperl=undef
  gnulibc_version='undef'
  Dynamic Linking​:
  dlsrc=dl_vms.xs, dlext=exe, d_dlsymun=undef, ccdlflags=''
  cccdlflags='', lddlflags='/Share'

@​INC for perl 5.19.3​:
  /perl_root/lib/site_perl/VMS_IA64
  /perl_root/lib/site_perl
  /perl_root/lib/VMS_IA64/5_19_3
  /perl_root/lib
  .

Environment for perl 5.19.3​:
  HOME=PTAC$DKA0​:[NCLARK]
  LANG (unset)
  LANGUAGE (unset)
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)
  PATH=PTAC$DKA0​:[NCLARK.I.perl-7d9633e5aba8]
  PERLSHR=PERL_ROOT​:[000000]PERLSHR.EXE
  PERL_BADLANG (unset)
  PERL_DESTRUCT_LEVEL=2
  PERL_DL_NONLAZY=1
  PERL_ROOT=PTAC$DKA0​:[NCLARK.i.perl-7c406553eef4.]
  SHELL (unset)

From @craigberry

On Wed, Aug 7, 2013 at 12​:29 PM, Nicholas Clark
<perlbug-followup@​perl.org> wrote​:

# New Ticket Created by Nicholas Clark
# Please include the string​: [perl #119195]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=119195 >

As you might be able to infer from the missing header, I couldn't get
perlbug to run properly on VMS, as I couldn't figure out the name of and
editor which would work.

There is likely a vim on the system you're using but I don't know how
useable it is.

system LIST on VMS appears to split on all spaces. Contrast​:

$ perl -w
system 'perl', '-le', 'print@​ARGV', 'a', 'b c'
__END__
abc
$ perl -w
system 'perl', '-le', 'print @​ARGV', 'a', 'b c'
__END__

$

This appears not to be documented as a limitation in pod/perlport.pod

Is it a bug which can be fixed, or does it need to be documented as a
portability limitation?

system doesn't really do arguments -- we fake it by stringing them
together into a command. (I think Windows does the same thing.) That
means the two examples above are just doing​:

$ perl -le print@​ARGV a b c
abc
$ perl -le print @​ARGV a b c

$

In the second example, Perl has no way of knowing that '@​ARGV' is part
of the one-line Perl program rather than just another argument. The
only way I can think of to fix it would be to have system() quote the
arguments before inserting them into the command string. Something
like that appears to be going on in create_command_line in
win32/win32.c, so perhaps that could be imitated in setup_argstr in
vms/vms.c.

The RT System itself - Status changed from 'new' to 'open'

From @Leont

On Thu, Aug 8, 2013 at 10​:47 PM, Craig A. Berry <craig.a.berry@​gmail.com> wrote​:

The
only way I can think of to fix it would be to have system() quote the
arguments before inserting them into the command string. Something
like that appears to be going on in create_command_line in
win32/win32.c, so perhaps that could be imitated in setup_argstr in
vms/vms.c.

I've been told the windows quoting code is buggy, but I haven't been
able to convince any of the more knowledgable people to file a perlbug
report yet.

Leon

From @nwc10

On Wed, Aug 21, 2013 at 12​:53​:59PM +0200, Leon Timmermans wrote​:

On Thu, Aug 8, 2013 at 10​:47 PM, Craig A. Berry <craig.a.berry@​gmail.com> wrote​:

The
only way I can think of to fix it would be to have system() quote the
arguments before inserting them into the command string. Something
like that appears to be going on in create_command_line in
win32/win32.c, so perhaps that could be imitated in setup_argstr in
vms/vms.c.

I've been told the windows quoting code is buggy, but I haven't been
able to convince any of the more knowledgable people to file a perlbug
report yet.

Based on my memories of trying to fake up list-based @​ARGV on RISC OS, which
is also command-line based at the level that operating system spawns things

0) There is no perfect solution to serialising the argv passed to "exec"()
  in such a way that the same argv arrives in main()
1) If the command line quoting mechanism does not provide a way to escape
  certain characters (typically control characters) you're never going to be
  able to pass those
2) If the command line quoting mechanism is part of the runtime support, then
  you have "fun" if different runtimes have different ideas about how quoting
  should work, because in the general case for an unknown program you're about
  to spawn, you can't know which rules you're meant to be playing by, so you
  can only quote using the subset which works with everything.
  And different versions of the same runtime can fix bugs or otherwise
  "improve" things.
3) If the runtime is handling redirection, you have even more fun.

but given all of the above, I would have expected that list system and list
exec would be capable of adding sufficient quoting to get spaces escaped,
within strings that otherwise would not need escaping.

(but yes, changing things now might break more than it fixes)

Nicholas Clark