From: Andrew Kingston <andrew@peerless.co.uk>
Subject: Re: Perl submit script issues
   Date: Tue, 19 Jul 2005 10:26:26 -0700
Msg# 992
View Complete Thread (8 articles) | All Threads
Last Next
Greg Ercolano wrote:
Andrew Kingston wrote:

sometimes I'll get an error - 16 bit MS-DOS Subsystem.


    Sounds like the "ComSpec" environment variable is somehow
    being changed from the CMD.EXE default to scuzzy old 16 bit COMMAND.COM
    (or similar 16 bit shell), which if changed by the script, will cause
    the script to then be unable to invoke any 32bit apps correctly
    (eg. using system(), backticks, open(), etc)

If I run other example scripts, or other ones I've customised I don't get any problems, so it must be something to do with this one script.


    Make sure it's not a user specific environment problem first;
    open a DOS window via "Start | Run | cmd.exe", and check
    the value of ComSpec:

C:\>set | findstr ComSpec
ComSpec=C:\WINNT\system32\cmd.exe
        ^^^^^^^^^^^^^^^^^^^^^^^^^
C:\>

    If that's set to something other than CMD.EXE, that's bad
    and needs to be fixed.

    If you find that setting to be correct, but invoking the script
    from this DOS shell still fails, eg:

C:\>perl //path/to/your/submit-script.pl

    ..then I'd say the script is probably somehow changing ComSpec
    (or #include'ing, require'ing or eval'ing a file that does this)
    then fails when the script tries to later invoke system(), open(),
    or `backticks`.

    If you're still having trouble, send me a copy of the script
    in private email, and I can possibly tell you what the cause is,
    if indeed it is a problem just with this script, and not the others.

    My guess is that some sequence of events in the script leads to
    that variable getting changed, causing errors when it tries to run
    other perl scripts.

I've trawled the internet, but can't find anything that helps.


    groups.google.com might be a better resource in this case
    for the NTVDM error, not sure.

I found what was causing the problem. There was a piece of code which a colleague had added (I thought it was from the original example script), which used unix commands (mv, awk, etc which were in the system path because cygwin is installed on all our windows machines). These were then executed using system() in the section around where the script creates defaults, or loads previous settings in to the gui - that's why it worked OK sometimes & not others. If you run the Cygwin awk from a DOS command prompt, you should see something akin to the error I was getting.

Cheers
Andrew

Last Next