Novitiatus has asked for the wisdom of the Perl Monks concerning the following question:

In part of an automated build system, a client is building a product that builds in the last release on a windows system. We have set up a new system for the next release.
Running under an MKS korn shell, and after the clients code is fetched a client's perl script runs to start compiles, (oversimplified).
Within the perl script a back ticked system call is made. The shell script being called doesn't have an extension. Within MKS you can set HASHBANG=1 so it will use the #! entry at the top. This is set in the environment.

It appears the perl script's back ticked system call is running cmd instead of the parent shell, mks's sh, or the environment isn't inherited, so the #! isn't recognized.

Is there a way to tell perl or does perl recognized the SHELL environment variable, (yes, it is defined), to know what shell will be used or is it more likely my environment isn't being passed to the system call?

This worked in the previous release and I can't figure out what is different between the two.

Humbly awaiting guidance or lashing,
Novitiatus
  • Comment on Is it my ENV within my system call or the shell itself?

Replies are listed 'Best First'.
Re: Is it my ENV within my system call or the shell itself?
by Aristotle (Chancellor) on Oct 02, 2003 at 20:12 UTC
    Just backtick something like perl -le'print for %ENV' and see what the %ENV looks like. I also seem to recall that Perl doesn't necessarily go through the shell anymore even for backticks - if that's the case, you'll need another way of invoking Perl on the file as Windows itself cannot be made to honour the shebang line. The easiest solution, it seems, would be to just qx/perl scriptname/.

    Makeshifts last the longest.

      ...Windows itself cannot be made to honour the shebang line.

      CMD doesn't honour the shebang line, but the MKS shell for Win32 does. The only problem was persuading perl to use the right shell. The PERL5SHELL envvar takes care of that nicely.


      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
      If I understand your problem, I can solve it! Of course, the same can be said for you.

        Not only CMD.EXE, but Windows as a whole. Launching executables using a system call is bound to the filename extension. Nevertheless, if Perl is indeed going through the shell in this case, then of course that offers a potential solution which did work in your case.

        Makeshifts last the longest.