mkdir has a prototype of $;$:

perl -we "print prototype('CORE::mkdir')"
$;$
[download]

This means that the first variable in the call to it will be put into scalar context. Most likely, you have now a subdirectory named "2" in ~/LGRID_Machine/examples, because @a evaluated to the number of elements (2).

To solve your larger problem of calling arbitrary builtins with the appropriate parameters, I think you will have to explicitly pass the parameters:

mkdir $a[0], $a[1];
[download]

instead of

mkdir @a;
[download]

Creating the appropriate calls can maybe be done by inspecting prototype("CORE::$function"), but some functions (like print) don't even have a prototype because they are super special.

Many, many thanks Corion!

Casiano

Update:Ah bollocks, that's exactly what the OP wants to do, ignore me please.

To solve your larger problem of calling arbitrary builtins with the appropriate parameters, I think you will have to explicitly pass the parameters:

mkdir $a[0], $a[1];
[download]

That won't work, it'll just create the directory $a[0] with the permissions as per filemask $a[1] (at least that's what it does on my 5.8.8 on Linux, is this different on Windows?)

To the OP: mkdir expects a single directory name. If you want to create multiple directories just do so in a loop, e.g.

for my $d (@a) {
  mkdir $d or die "Couldn't create directory $d: $!";
}
[download]


All dogma is stupid.

... which basically is what casiano was trying to do:

@a = ('/tmp/DIRECT', 18)
[download]

I answered his question in context of CORE and CORE::GLOBAL operators (resp. Re^2: CORE and CORE::GLOBAL operators), and imagine the actual code is some generalized call routine to dispatch the call on a remote machine.

If you have a scenario where you have lots of these arrays floating around and you'd rather not go and change them all to use $array[0], $array[1], you could just put in your code a new function: sub mkdir {CORE::mkdir $_[0],$_[1]} which would then split it up for you.

I'm pretty sure I've read a few times how prototypes are evil, but I think this is even more evil than normal prototypes: with normal prototypes, I can fake my way around them with the & sigil. Not so with built-ins.

(...) No, that doesn't work, either. You have to do both: create the function, AND call it with &. Doesn't work:

$ perl -e '@x=qw(foo 18);sub mkdir{CORE::mkdir($_[0],$_[1])};mkdir(@x)
+';ls
2
[download]

$ perl -e '@x=qw(foo 18);sub mkdir{CORE::mkdir($_[0],$_[1])};&mkdir(@x
+)';ls
foo
[download]

$ perl -e '@x=qw(foo 18);&mkdir(@x)';ls
Undefined subroutine &main::mkdir called at -e line 1.
[download]