Seriously, the things I do for you people.
With the Portable alpha, and feedback starting to roll in, the most obviously blocker for Perl on a Stick is that the batch files produced by pl2bat don't work when Perl isn't in PATH, which for the portable situation is a given.
The trouble with batch programming is that it's such a dead language at this point, it's hard to even find good information about it.
So in Portland, I undertook an expedition to the glorious fantabulous Powell's Books, in the hope that if anyone could find me something, they could.
Alas, the only remain batch file programming book in the United States was stuck in their warehouse in Chicago!
Fortunately, Powell's expert Michael Schwern came to my rescue and after some scrounging in the second hand books sections, emerged with just what I needed.
Aside from being extremely old, it also happens to be about the most embarrassing technical book I've ever owned. Pulling it out at the coffee shop in front of an assembled gaggle of Perl/OSCON geeks resulted in a loud chorus of laughter...
And so between this book, some built in Windows help information, and some online tutorials, I've managed to piece together a fix to pl2bat to make the batch script look for and use the perl executable in the same directory as the
The specific line is:
FOR %%i IN ( %0 ) DO %%~di%%~piperl -x -S %0 %*
In a way, I'm quite lucky that it turned out so easy, given how utterly dysfunctional Windows batch is as a "language". By comparison, shell script is elegant and well structured.
The key problem here is that batch doesn't have any string manipulation functions at all, nor does it have much of a file system interface either.
It does (sort of) support variables, which is the "%i" in the above. Except that it's only %i if you use a variable on the command line. Inside a batch script you have to use %%i instead. Don't ask me why, I've never seen any explanation. It just is.
The "perl -x -S" bit is straight forward by comparison...
%0 is the equivalent of $0, and %* is the equivalent of @ARGV.
The tricky bit here is that there's literally no way to turn a string like C:\strawberry\perl\bin\foo.bat into C:\strawberry\perl\bin\perl.exe, so you can call the correct Perl instance.
So instead, we need to badly abuse some evil functionality built into the FOR command/loop.
The FOR command has a bunch of wildly diverse, and utterly insane, ways of working.
But the interesting one is when you use it to iterate over files, like so:
FOR %%variable IN ( file1.txt file2.txt ) DO something
If, and ONLY if, FOR is used to iterate over a list of files, and it knows they are files, then some magic %%variable stuff comes into existance.
These looks like %%~(letter)variable, and let you access different bits or variations of the file name.
The two useful ones in this case is %%~dvariable, which gives us the drive letter for the file in the form "C:", and %%~pvariable which gives the path in the form "\strawberry\perl\bin\".
And thus, by doing a completely useless single value for loop FOR %%i IN ( %0 ) DO we can cause the magic variables we need to come into existance, from which we can just do a simple string concatination (which needs no syntax, because it's just implied) and add perl.exe to the end, which gets us all the way to something that is rediculous, but works.
Of course, this only works post-installation, and wouldn't be usable at all if you called it in the modules blib at build time...
Making THAT works gets even weirder, and will most likely require more thought.
But it does look like I'll have batch stuff working properly by the time YAPC::EU rolls around, making the YAPC::EU "Perl on a Perl on a Stick Stick" much more functional than the American version