Is it better to use a "packaged" easily installable version of Perl such as Strawberry on a Windows OS or to compile a version or there is no practical difference, etc...?

I primarily ask for two reasons: stability and speed. An underlying assumption to both reasons is that compiling code will always be faster, because it will compile based on specific chipsets and its respective native math libraries.

1. Stability. My systems run both AMD CPUs and GPUs. I have wondered if instability in GAMES are sometimes caused by various issues of the binaries being compiled for Intel CPUs and NVidia GPUs. By extension, is there an inherent stability benefit of compiling Perl on a Windows system?

2. Speed. This likely has no real practical value unless one is running a "large" server on Windows; but, I wanted to ask anyway. So, by a similar analogy to GAMES stability, since there is a real benefit to GAMES which have been optimized for either AMD or Intel/NVidia and sometimes specifically a chipset, is there a speed benefit to compiling Perl on Windows?

thanks

# IMPORTANT MODULES FOR THIS CODE...
use CGI qw(-utf8); 
use File::Spec::Functions qw( catfile );

sub send_file {
    my ($cgi, $dir, $file) = @_;

    # $dir = '/var/www/download/';
    # $file = 'MyLaTeXDocument.pdf';

    my $path = catfile($dir, $file);
        
    open my $fh, '<:raw', $path or die "Cannot open '$path': $!\n";

    $cgi->charset(''); #REMOVES PRIOR UTF-8 SETTING, AS THIS IS BINARY
+ FILE
    print $cgi->header(
        -type => 'application/octet-stream',
        -attachment => $file,
    );

    binmode STDOUT, ':raw';
    print while <$fh>;    
    close $fh or die "Cannot close '$path': $!";

    return;
}
[download]

The browser console sees a string of characters returning in the response, but no download dialogue is opened.

Response headers

Connection
    Keep-Alive
Content-Disposition
    attachment; filename="MyLaTeXDocument.pdf"
Content-Type
    application/octet-stream
Date
    Fri, 22 Sep 2023 11:13:27 GMT
Keep-Alive
    timeout=5, max=100
Server
    Apache/2.4.52 (Ubuntu)
Transfer-Encoding
    chunked
[download]

Response Payload

JVBERi0xLjUKJeTw7fg... [truncated...too lazy to type more]
[download]

my $one_string = "hello world";
say length $one_string;    # 11
 
my @many_strings = ("abc", "cd", "e", "fg", "hi", "hello world");
say length @many_strings;  # 1
say scalar @many_strings;  # 6
[download]

I want to know what it would take for the next one:

say __?__ @many_strings;  # 21
[download]

<tag>many characters ends abruptly here in the middl</tag>
[download]

I save the line in a scalar array element, then print the entire array. The result has the begin and end tag, but the line in the middle is truncated. In the last fail, it truncated at 23,052 characters which didn't seem like a particularly significant number. In other cases the line greatly exceeds that length, without truncation.

Ideas of why this happens on some lines and not others, or better ways to save these long lines with are appreciated. Maybe more than one tag? I studied MAX XML tag-contents restrictions, as well as Perl scalar length limits, and I don't see any specific limits.

my @fonts = `/usr/bin/fc-list : family`;

My perl version is:

perl -v

This is perl 5, version 34, subversion 0 (v5.34.0) built for x86_64-li
+nux-gnu-thread-multi
(with 58 registered patches, see perl -V for more detail)
[download]

The error that appears in my logs is: "Insecure $ENV{PATH} while running with -T switch . . .," despite the fact that my shebang line has only #!/usr/bin/perl and, while narrowing the problem down, I have disabled all module uses except one: use CGI qw(-utf8);.

As is clear to be seen, there are no variables, nor any executable code, inside the backticks--so there should be no legitimate security issue worthy of shutting down the execution of the script. They invoke a standard command which is useful for displaying the fonts available and installed on the server. Should those fonts change, such as if more were to be installed, the next run of the script would automatically show this--which is what I want.

But even if I put ls inside those backticks, the whole script will fail, and I get "Internal Server Error" as the message in my browser.

Other options than using backticks seem cludgy at best, and problematic at worst. I could run a cronjob that writes the output of this command to a file, then the perl script reads from that file. To be up-to-date, this cronjob would have to run often, consuming server resources--not to mention the added unnecessary file to be stored in the system.

I could use a system call (assuming taint would allow this--I haven't tried it yet) that would do what the cronjob does, then, after opening and reading the file, I could unlink it. This requires multiple steps, much more code, involves file permissions which create potential failure points, and just seems quite rather unperlish.

I fell in love with perl years ago when it gave me the ability to do what I wanted in easy and intuitive ways. This taintedness is rubbing against the grain.

Why is taint even forced on the script without my having invoked it? In actual fact, I would like the script to run with taint, but I need to be able to run this command, too. Is this as impossible as wanting to have my cake and eat it too?

There's a fun little bug in the debugger, which you can see like this. Create a dumb little script. Anything will do.

#!/bin/perl
use strict;
use warnings;

print "we";
print "just";
print "need";
print "something";
print "to";
print "list";
[download]

Now let's start up the debugger.

perl -d zz.pl

Loading DB routines from perl5db.pl version 1.77
Editor support available.

Enter h or 'h h' for help, or 'man perldebug' for more help.

main::(zz.pl:5):    say "we";
  DB<1>
[download]

All as expected, but now:

  DB<1> l 1.2
1.2     use strict;
  DB<2> l
2.2     use warnings;
3.2     use feature 'say';
4.2     
5.2:    say "we";
6.2:    say "just";
7.2:    say "need";
8.2:    say "something";
9.2:    say "to";
[download]

That's kind of unexpected, but it gets better!

  DB<2> l 1.1.3.5
1.1.3.5     use strict;
  DB<3> l
2.1     use warnings;
3.1     use feature 'say';
4.1     
5.1:    say "we";
6.1:    say "just";
7.1:    say "need";
8.1:    say "something";
9.1:    say "to";
[download]

Why does this happen? well it goes back to commit a687059cbaf, which is the one that moves the debugger into lib in Perl 3. The pattern used to capture the line number specification is (\d\$\.)+, which matches all kinds of things, including floating-point numbers, IPv4 addresses, and other junk. The overall pattern used to parse the l command arguments changes over time, but that basic match to extract a "line number" never does.

You may be thinking, "yeah, okay, I see that, but why does the debugger show the floating-point line number?" The reason is that the line number spec is captured as a string. THe debugger stores the source code of the current file in an array whose name is not a valid Perl variable name, and uses the line number spec captured by the l command to index it.

When Perl indexes an array, the index value is converted to an integer if possible, because array indexes have to be integers. The line spec we have is captured and stored as a string, so when we try to index the source array with it, "1.22" becomes the integer 1, and we find line 1. The command uses the value of the index variable (remember, that's still a string!) to print the line number, and so we end up with a floating-point line number.

Now, when we run the bare l command, the string "1.22" is still in the list command's "last line listed" variable, and Perl simply takes that variable and adds 1 to its contents to look for the next line. Since the contents are a string that looks like a floating point number, Perl converts it to a float, adds 1.0 (so we don't downgrade it from a float), and assigns that back to the current line number,so we get lines 2.22, 3.22, and so on.

I've submitted a patch to fix this for 5.40, but it's pretty surprising that we've had this bug for 32 years!