# End of script output before headers



## rtwingfield (Jun 2, 2016)

I can finally execute a "Hello world" Perl script from a command line (have encountered numerous problems with upgrade to perl5-5.24.0), but when called from a Firefox browser session, the following errors are reported:


```
[Thu Jun 02 04:47:00.927168 2016] [cgi:error] [pid 73280] [client 9.9.9.9:43404] AH01215: (2)No such file or directory: exec of '/www/vhosts/foobar.net/cgi-bin/perl/hello.pl' failed: /www/vhosts/foobar.net/cgi-bin/perl/hello.pl, referer: http://foobar.net/
[Thu Jun 02 04:47:00.942718 2016] [cgi:error] [pid 73280] [client 9.9.9.9:43404] End of script output before headers: hello.pl, referer: http://foobar.net/
```

This thread (10 months old and marked solved) described an obscure solution that doesn't work in my case:  https://forums.freebsd.org/threads/52478/#post-294495.  You can  google around and find other similar scenarios, one even suggesting a bug in the Apache2.4.+ system.  

I've had to reinstall the Apache2.4.20 instance (previous working version destroyed by Synth . . .?) and have changed nothing significant in the httpd.conf file.  Regardless, it was working before, but now fails.  

In the httpd.conf file, has something changed in the system that would be effected by the following directives?

```
LoadModule mpm_prefork_module libexec/apache24/mod_mpm_prefork.so

<IfModule mpm_prefork_module>
   LoadModule cgi_module libexec/apache24/mod_cgi.so
</IfModule>
```


----------



## SirDice (Jun 2, 2016)

Can you post your Perl script?


----------



## rtwingfield (Jun 2, 2016)

SirDice said:


> Can you post your Perl script?


Yeah, it's this complex piece:


```
#!/usr/bin/perl -wT

#use strict;
use warnings;
use CGI qw(:standard);
use CGI::Carp qw(fatalsToBrowser);

print header;

print start_html("Hello World");
print "<h1>Hello from Perl!</h1>\n";
print end_html;
```

Here's the result of a CL execution:

`# perl -wT hello.pl`

```
Content-Type: text/html; charset=ISO-8859-1

<!DOCTYPE html
  PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US">
<head>
<title>Hello World</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
</head>
<body>
<h1>Hello from Perl!</h1>

</body>
</html>
```




*** EDIT ***

. . .and just for fun, I've dumb'ed it down to this essential code:


```
#!/usr/bin/perl -wT
print "Hello from Perl!\n";
```

. . .same error problem.


*** EDIT ***

. . .and for even more fun   , I had sort of an epiphany . . .let's try to call something bogus that doesn't exist, e.g., bogus.pl and the error returned is 

```
[Thu Jun 02 17:11:45.174703 2016] [cgi:error] [pid 77155] [client 192.168.1.1:56440] AH02811: script not found or unable to stat: /www/vhosts/9.9.9.9.net/cgi-bin/perl/bogus.pl, referer: http://9.9.9.9.net/
```
 a different error message . . .so apparently, the Apache system is _finding_ the valid target . . .but refusing to render it.


----------



## SirDice (Jun 3, 2016)

rtwingfield said:


> . . .and just for fun, I've dumb'ed it down to this essential code:
> 
> ```
> #!/usr/bin/perl -wT
> ...


Yes, with this bit of code I actually expect the error as it's missing the Content-Type header. This shouldn't produce the error:

```
#!/usr/local/bin/perl
print "Content-Type: text/plain\n\n";
print "Hello World!";
```

Also make sure the script is marked as executable.


----------



## rtwingfield (Jun 3, 2016)

SirDice said:


> Yes, with this bit of code I actually expect the error as it's missing the Content-Type header. This shouldn't produce the error:
> 
> ```
> #!/usr/local/bin/perl
> ...


. . .exactly, it was an attempt to force some other error msg., but it didn't.

You know, the solution just *popped* out of your post like a _bolt out of the blue_!

```
#!/usr/local/bin/perl
```
   . . .there is no /usr/bin/perl.  All of my perl scripts are coded with 
	
	



```
#!/usr/bin/perl
```
  Most are over six years old.  (A period when I was actively writing a lot of Perl.)  As I've mentioned, I've encountered a lot of difficulty regarding the upgrade to /usr/ports/lang/perl5.24; regardless, here in Little Rock, AR USA at ~3:30 AM (10:30 AM Amsterdam), I read your post and boom!  . . .there it was.  How silly of me . . .just couldn't see the forest for the trees.

The scripts will execute from the CL,  `# perl hello.pl` but if invoked from a browser session, the code 
	
	



```
#!/usr/bin/perl
```
 isn't pointed to 
	
	



```
#!/usr/local/bin/perl
```
In fact, the script will execute from the CL without the #!_shebang_ code.

In defense of my oversight, the error messages are extremely ambiguous and subject to a lot of "dreaded" criticism out in _Google-world_.

```
AH01215: (2)No such file or directory: exec of '/www/vhosts/foobar.net/cgi-bin/perl/hello.pl' failed: /www/vhosts/foobar.net/cgi-bin/perl/hello.pl
End of script output before headers: hello.pl
```
The "_programmers_" that wrote this stuff know the _what-when-where-why_ of the problem.  Is it too much to ask that an extra error-message be coded into the system?  . . .a message that actually means something.  This is just too _Microsoft-esk_. 

But anyway, thanks for your attention to my problem.  It was a ricochet hit, but very helpful.


----------



## SirDice (Jun 3, 2016)

Aha! Yeah, that has bitten me more than once before too. The error message is indeed extremely confusing but it has to do with the way scripts are executed.


----------



## kpa (Jun 3, 2016)

You're reading too much into it, it's an older than sin feature of unix shell scripts that use the shebang technique and it vastly predates anything the Microsoft produced. Surprisingly it's entirely dependent on which shell you're using, some shells can work around the problem and report something more meaningful. This is with shells/zsh and a shell script that tries to use non-existent /bin/bash:


```
freebsd10 ~ % ./shebang.sh
zsh: ./shebang.sh: bad interpreter: /bin/bash: no such file or directory
freebsd10 ~ %
```

The default shell sh(1) on the other hand follows as closely as possible what the historical bourne shells did in the same situation.


----------



## wblock@ (Jun 3, 2016)

rtwingfield said:


> ```
> #!/usr/local/bin/perl
> ```


But don't use that either.  The recommended version is

```
#!/usr/bin/env perl
```


----------



## SirDice (Jun 3, 2016)

Sure, but in this case that's probably going to cause issues as the script is started as CGI from Apache. And as far as I know Apache's path doesn't include /usr/local/bin/. But maybe this has been rectified since I last used CGI scripts.


----------



## Murph (Jun 17, 2016)

SirDice said:


> Sure, but in this case that's probably going to cause issues as the script is started as CGI from Apache. And as far as I know Apache's path doesn't include /usr/local/bin/. But maybe this has been rectified since I last used CGI scripts.



If memory serves, it can actually be even more troublesome than simply missing from Apache's path.  E.g. if Apache was last started from the command line with something like `/usr/local/etc/rc.d/apache24 start`, it may well have /usr/local/bin in its path, allowing your scripts to work perfectly until the next time the system is rebooted.

You should be able to ensure that appropriate /usr/local stuff, and any other necessary environment is set for Apache by either editing /usr/local/sbin/envvars or adding a suitable script to /usr/local/etc/apache24/envvars.d.  The latter of those two should be the safer choice, as the former might get clobbered by a port/pkg update.

Personally, I recommend just using `#!/usr/local/bin/perl`, which also saves an exec(2) and a bunch of path enumeration.  Admittedly, that saving isn't a compelling argument when balanced against the cost of starting a new Perl instance, but it is still a saving.  The `env` trick is handy if you need a script to work across a broad range of systems without modification, but really doesn't add any value in the case of a CGI script which is only expected to execute on the local system.

Whatever solution is used, it needs to be verified after a full system reboot, due to the quirk of daemons inheriting interactive user environment when started from an interactive command line.


----------

