Fair point WRT @INC. I still wonder about Config, though.

The portable version of Strawberry Perl is not installed per se. It just lives in a folder and can be moved around without needing any additional steps to tell Perl where it has been moved to. There are some runtime effects on Config based on the location of the binary, and those are what I cannot locate the source of. Whether those have any bearing on @INC is another question, of course.

Edit: I think this is answered by haj in 11136120, and is the Portable module.

I still wonder about Config, though.

It's quite easy to change %Config values - and the same method works on all systems.
Just create a file named (say) New_Config.pm:

package New_Config;
use Config;

my $new = tied %Config;

$new->{make} = 'dmake';
$new->{byteorder} = '43215678';
# Specify as many as you like
1;
[download]

Then you'll see:

C:\>perl -V:byteorder
byteorder='12345678';

C:\>perl -MNew_Config -V:byteorder
byteorder='43215678';

C:\>perl -V:make
make='gmake';

C:\>perl -MNew_Config -V:make
make='dmake';
[download]

The first I became aware of this was with Mattia Barbon's EU::FakeConfig.
This was very useful as it allowed the use of gcc toolchains to build and install XS modules on perl's built using an MSVC toolchain. (This was back in the day when ActiveState were providing perl's built using MSVC-6.0.)

I haven't checked to see whether this technique is utilised by Strawberry Perl in achieving its relocatability.
IIRC, on Windows some Config keys can be altered by editing Config.pm and Config_heavy.pl - but there are also keys that, to my knowledge, can only be changed via this "tied hash" approach.

Cheers,
Rob

It's quite easy to change %Config values - and the same method works on all systems. Just create a file named (say) New_Config.pm:

You should be aware that changing paths in Config.pm has no effect on @INC. The point of the hack in ExtUtils::FakeConfig is to fool other programs about how this Perl has been built. Other programs use Config and act accordingly. For Perl itself it is just a report written at build time, the Perl executable does not read it (unless you start with perl -d as the debugger does use it).

However, Linux (amazingly) apparently does not provide such a convenience. 

It's not that amazing: in Linux the dir(s) containing the executable(s) is common to all installed programs: /bin, /sbin, /usr/bin, /usr/local/bin. It is not the case that each program has its own private bin/, lib/ (include/, etc/) and keep adding private bin/ dirs to the PATH, which (the PATH) being such a primitive structure it is "difficult" to add a path somewhere in the middle, say, in order to precede some similarly-named program, e.g. another Perl. With a common bin/ dir (Linux), programs have to either overwrite existing one or be renamed. Deriving the INC by and relative to the location of the executable can not work in Linux (5' EDIT: see Re^5: Devel::NYTProf: "undefined symbol: PL_stack_sp" error for how paths are hardcoded within libraries). Or any other sane OS which likes to put its soldiers to a communal camp, provided they all keep clean socks. In this way, a single bin/ file-permissions and other security policy will be saner to maintain. Additionally, there are (usually) no private program installations (re: "Do you wish to install this program for all users or just for you?") except in a groups-based way (e.g. admin, staff, etc.). Again, easier to maintain security policy. The results are obvious from a glance at the battlefield: virtually each and every windows box is pawned (including that windows XP of UK's 3bn nuclear air-carrier, see also here, for the other side of the story).

bw, bliako