This isn't really a Perl problem! When you launch a script from the command line in *nix, the environmental variables have been set up via your login. When you launch a script from 'inetd' you must ensure that required environment is set up for the script to work.

This would be the same problem with any language (C, C++, etc.). What you could do to find the problem is in your test script open a file and dump your %ENV with a foreach loop. Move that file to a backup name and then call the script from 'inetd' and then compare the two files (can use 'diff' under *nix). It could be different users, protection problem, etc.

The Perl script lanuches and runs perfectly from inetd.
However, the PAR packager binary version doesn't run.
See below when I poked inetd, it launched the binary program (testportal).
The response suggests that I am not calling the program correctly.
Any ideas why would perl packer change the usage of my script and how come I can call it from the command line?
Is this something to do with pp not supporting daemon mode as advised by Old Gray Bear or something else?
Any more wisdom would be appreciated.

SOLUTION FOUND - When I added the -d option to my command line, the resultant binary may be launched by inetd.
Perldoc pp does not go into much detail on this option. But contrib/docs/where_is_it.txt gave me the clue to find the answer. Thanks Anonymous Monk.

POST-MORTEM -
I suspect that my problem was caused due to Perl being installed on the target machine. When I build with dependencies the binary does not launch correctly (perhaps due to a library ambiguity?). When I rebuild without dependencies, the library is loaded and my program runs.