Looking at pp, it defaults to bundling core modules, plus some of it's own modules. Confirmed with: pp -e "print join qq(\n), @ARGV, '-'x20, map(qq|$_ => $INC{$_}|, sort keys %INC)" -o printargv.exe && printargv.exe * ... which shows a few dozen included modules.

My guess is that either one of the PAR pacakges (or less likely, one of the CORE packages) is automatically globbing for you. I don't see a way to do the opposite of --bundle, other than trying --exclude on each of the elements of %INC until it stops auto-globbing (though that might break things if the culprit is in one of the PAR::* modules). Alternately, maybe --par or --perlscript to package without the standalone binary, and see if running the .par alone does the same (sorry, not enough time for those experiments for now).

Thanks for the insight pryrt,

I must admit I never used -p nor -P options of pp but if I assume it correctly these version seems to works just as expected ie printing the lone star.

 pp --perlscript -e "print join qq(\n), @ARGV" -o printargv.exe

>perl printargv.exe *
*

# dunno if this is correct..
>par printargv.exe *
*
[download]

Sorry but I have no idea about how to deal with par files..

I really wonder what this imply. Anyway mine was more a curiosity than a problem so do not waste your time investigating if you have not. Thanks anyway.

L*

There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

Actually, MinGW, on Windows, does glob expansion, e.g.:

#include <stdio.h>
extern int _CRT_glob;
//_CRT_glob = 0;
int main( int argc, char **argv ) {
    int i;
    for ( i = 1; i < argc; i ++ )
        printf( "%s\n", argv[i] );
    return 0;
}
[download]

and then

>gcc x.c
>a.exe *.c
x.c
[download]

If comment is uncommented, the output becomes *.c. However, Perl has its reasons to prevent such globbing. The "other Win32 ports" being ActiveState, and PAR-packed executable, created with AS-Perl, won't expand globs.

What's odd, is that executable built with PAR::Packer should prevent globbing, too -- this seems to be the intention. But for some reason, it doesn't work. So, I'd say it's minor bug and/or inconsistency.

many thanks for the insight vr,

I was a bit lost in the first time because I do not know the deep details of what happens.. so I wondered why you mentioned the mingw part.

My strawberry use not mingw perl -V:make   make='gmake'; But if I understand your words correctly you mean that the PAR::Packer intention is to prevent the glob to be expanded as it does for mingw. So to be consistent it should prevent the expansion everytime.

If so and given my output above it must be a little inconsistency or minor bug..

Accordingly to the above I opened a github issue

L*

There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

My strawberry use not mingw perl -V:make make='gmake';

Not that it matters, since the bug report was the right thing to do... but are you sure your Strawberry Perl's compiler is not mingw? "gmake" vs the older "dmake" is not an indicator of whether it's mingw. All the evidence I can find (from Wikipedia to Strawberry's website, to the flags quoted in your -V information to my Strawberry-perl-gcc's -v) all agree that it's mingw.

Wikipedia's Strawberry Perl article says, "Strawberry Perl incorporates the MinGW development environment during installation."

From a more authoritative location, Strawberry's 5.26.0.1-64bit Release Notes, "new gcc-7.1 (we switched to seh exception handling) + mingw-w64-5.0.2 runtime"

Looking at extracts from the full -V you quoted, I see a couple mentions of mingw:

...
  ccflags =' -s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE -D__USE_MINGW_ANSI_
+STDIO -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT
+_SYS -DUSE_PERLIO -fwrapv -fno-strict-aliasing -mms-bitfields'
...
  libpth=D:\ulisseDUE\perl5.26.64bit\c\lib D:\ulisseDUE\perl5.26.64bit
+\c\x86_64-w64-mingw32\lib D:\ulisseDUE\perl5.26.64bit\c\lib\gcc\x86_6
+4-w64-mingw32\7.1.0
[download]

What do you get for where gcc and gcc -v. On my Strawberry 5.26.0_64_PDL, I get quite a few mentions of "mingw" as well:

C:>where gcc
C:\usr\local\apps\berrybrew\perls\5.26.0_64_PDL\c\bin\gcc.exe

C:>gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=C:/usr/local/apps/berrybrew/perls/5.26.0_64_PDL/c/
+bin/../libexec/gcc/x86_64-w64-mingw32/7.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-7.1.0/configure --host=x86_64-w64-mi
+ngw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix
+=/mingw64 --enable-shared --enable-static
 --disable-multilib --enable-languages=c,c++,fortran,lto --enable-libs
+tdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-libat
+omic --enable-lto --enable-graphite --ena
ble-checking=release --enable-fully-dynamic-string --enable-version-sp
+ecific-runtime-libs --enable-libstdcxx-filesystem-ts=yes --disable-li
+bstdcxx-pch --disable-libstdcxx-debug --d
isable-bootstrap --disable-rpath --disable-win32-registry --disable-nl
+s --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --wi
+th-arch=nocona --with-tune=core2 --with-l
ibiconv --with-system-zlib --with-gmp=/opt/build/prerequisites/x86_64-
+w64-mingw32-static --with-mpfr=/opt/build/prerequisites/x86_64-w64-mi
+ngw32-static --with-mpc=/opt/build/prereq
uisites/x86_64-w64-mingw32-static --with-isl=/opt/build/prerequisites/
+x86_64-w64-mingw32-static --with-pkgversion='x86_64-posix-seh, Built 
+by strawberryperl.com project' CFLAGS='-O
2 -pipe -fno-ident -I/opt/build/x86_64-710-posix-seh-rt_v502/mingw64/o
+pt/include -I/opt/build/prerequisites/x86_64-zlib-static/include -I/o
+pt/build/prerequisites/x86_64-w64-mingw32
-static/include' CXXFLAGS='-O2 -pipe -fno-ident -I/opt/build/x86_64-71
+0-posix-seh-rt_v502/mingw64/opt/include -I/opt/build/prerequisites/x8
+6_64-zlib-static/include -I/opt/build/pre
requisites/x86_64-w64-mingw32-static/include' CPPFLAGS=' -I/opt/build/
+x86_64-710-posix-seh-rt_v502/mingw64/opt/include -I/opt/build/prerequ
+isites/x86_64-zlib-static/include -I/opt/
build/prerequisites/x86_64-w64-mingw32-static/include' LDFLAGS='-pipe 
+-fno-ident -L/opt/build/x86_64-710-posix-seh-rt_v502/mingw64/opt/lib 
+-L/opt/build/prerequisites/x86_64-zlib-st
atic/lib -L/opt/build/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: posix
gcc version 7.1.0 (x86_64-posix-seh, Built by strawberryperl.com proje
+ct)
[download]

Hi, Discipulus, I meant that in these 3 cases:

perl -e "print join qq(\n), @ARGV" *
pp -e "print join qq(\n), @ARGV" -o printargv.pl -P && perl printargv.
+pl *
pp -e "print join qq(\n), @ARGV" -o printargv.par -p && par printargv.
+par *
[download]

the executable, being finally loaded and run, is one and the same perl.exe. Its main function is loaded/executed by wrapper/loader created by/in MinGW environment, being present at the time Strawberry Perl was built. The _CRT_glob appears to be responsible for glob expansion of arguments -- i.e. main gets not real argv, but expanded (or not) by wrapper. Just as in C example in my comment above.

Whereas, in

pp -e "print join qq(\n), @ARGV" -o printargv.exe && printargv.exe *
[download]

the loaded executable is fresh, just compiled printargv.exe, whose main is also loaded by wrapper/loader, and its compilation somehow missed the state of _CRT_glob flag.

As to Strawberry's idea of providing MinGW/gcc environment for CPAN distributions to install "same as in Linix/Unix", -- no other way for that to work but to have Perl compiled in the same MinGW/gcc environment, no?

Hi,

? What do you have for output from perl -V

update: thanks for perl -V, it was kind of a long shot, but I don't see any surprises in your %ENV , no mention of sitecustomize

Please ignore, did not fully read the question.

Alexander

EDIT: Ignore this. You don't want it to glob...