From: Andrew Kingston <andrew@peerless.co.uk>
Subject: Perl submit script issues
   Date: Fri, 15 Jul 2005 03:48:53 -0700

Hi

Cheers
Andrew

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.

--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Cel: (Tel# suppressed)
Fax: (Tel# suppressed)

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.

Cheers
Andrew

Andrew Kingston wrote:

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.

	Really?

	Sounds like it might be a 16 bit version of Cygwin, or a 16 bit
	version of perl.

	Perl's system() and DOS (cmd.exe) should be able to invoke 32 bit versions
	of Cygwin (such as mv, awk, etc) just fine..

	I think the problem is deeper; either a 16 bit version of Perl, DOS,
	or Cygwin is involved here..


--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Cel: (Tel# suppressed)
Fax: (Tel# suppressed)

Greg Ercolano wrote:

Andrew Kingston wrote:

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.

    Really?

    Sounds like it might be a 16 bit version of Cygwin, or a 16 bit
    version of perl.

Perl's system() and DOS (cmd.exe) should be able to invoke 32 bit versions

    of Cygwin (such as mv, awk, etc) just fine..

    I think the problem is deeper; either a 16 bit version of Perl, DOS,
    or Cygwin is involved here..

Cheers
Andrew

Andrew Kingston wrote:

I've just been doing a bit more digging & I think I've found what was causing the problem. In \cygwin\bin if you do an ls -l awk.exe, it gives you: lrwxrwxrwx 1 Adminst Users 19 Nov 1 2004 awk.exe -> gawk.exe.

	Huh, I didn't know cygwin somehow implemented symbolic links
	under Windows.

	Maybe underneath it's a 'junction'.. Windows terminology
	for a symlink, which Win32 does support, but junctions can
	only be pointed to files on the same disk currently, not to
	network drives :/

	More info about NTFS junctions here:
	http://support.microsoft.com/default.aspx?scid=kb;EN-US;q205524

If I run gawk.exe at a DOS prompt I don't get any errors, but run awk.exe, and I get the error I've been mentioning.

	Weird.
	It's as if the cygwin symbolic link is the cause.

I get the same error whenever I try to run one of the linked Cygwin apps at a DOS prompt - like gunzip.exe & zcat.exe.

	If you're curious, it might be interesting to make it a copy
	instead of a link, eg:

		cp gawk.exe /temp/awk.exe
		echo 4 | /temp/awk '{ printf("%04d\n"; }'

	..the implication being if that works, it's the symlink for sure.

	Might be a bug in the specific version of cygwin you're using.
	I tried cygwin once, and it was too weird for me. It has too
	many hoops it hops through with those weird pathnames it uses,
	and some of its shells are kinda buggy. So I left it alone,
	and decided to just do everything in perl, and just live with
	DOS as an interactive shell. DOS has been getting better;
	things like tab completion and better commands make it less
	annoying than it used to be.

So it looks like I could put the code back into my script if I needed to as long as I used gawk instead of awk.

	Yes -- I'd agree.

	It's good you got to the bottom of that; we can all know
	to watch for this.

	FWIW, within your perl script, you should be able to do
	all awk-like stuff within perl, eg. these being equivalent:

		echo 4 | awk '{ printf("%04d\n",$0); }'
		echo 4 | perl -ne '{ printf("%04d\n",$_); }'

	..or better yet, just use perl to do the work.
	I can't think of any situation where one would
	need a perl script to invoke awk externally.. it's
	usually always more efficient to code it all within perl.

	eg. I'd always prefer these perl commands:

		my $padframe = sprintf("%04d", $frame);

	..to these:

		my $padframe = `echo $frame | awk '{ printf("%04d\n",$0); }'`;
		chomp($padframe);


--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Cel: (Tel# suppressed)
Fax: (Tel# suppressed)

Greg Ercolano wrote:

Andrew Kingston wrote:

I've just been doing a bit more digging & I think I've found what was causing the problem. In \cygwin\bin if you do an ls -l awk.exe, it gives you: lrwxrwxrwx 1 Adminst Users 19 Nov 1 2004 awk.exe -> gawk.exe.

    Huh, I didn't know cygwin somehow implemented symbolic links
    under Windows.

    Maybe underneath it's a 'junction'.. Windows terminology
    for a symlink, which Win32 does support, but junctions can
    only be pointed to files on the same disk currently, not to
    network drives :/

    More info about NTFS junctions here:
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;q205524

If I run gawk.exe at a DOS prompt I don't get any errors, but run awk.exe, and I get the error I've been mentioning.

    Weird.
    It's as if the cygwin symbolic link is the cause.

I get the same error whenever I try to run one of the linked Cygwin apps at a DOS prompt - like gunzip.exe & zcat.exe.

    If you're curious, it might be interesting to make it a copy
    instead of a link, eg:

        cp gawk.exe /temp/awk.exe
        echo 4 | /temp/awk '{ printf("%04d\n"; }'

    ..the implication being if that works, it's the symlink for sure.

    Might be a bug in the specific version of cygwin you're using.
    I tried cygwin once, and it was too weird for me. It has too
    many hoops it hops through with those weird pathnames it uses,
    and some of its shells are kinda buggy. So I left it alone,
    and decided to just do everything in perl, and just live with
    DOS as an interactive shell. DOS has been getting better;
    things like tab completion and better commands make it less
    annoying than it used to be.

So it looks like I could put the code back into my script if I needed to as long as I used gawk instead of awk.

    Yes -- I'd agree.

    It's good you got to the bottom of that; we can all know
    to watch for this.

    FWIW, within your perl script, you should be able to do
    all awk-like stuff within perl, eg. these being equivalent:

        echo 4 | awk '{ printf("%04d\n",$0); }'
        echo 4 | perl -ne '{ printf("%04d\n",$_); }'

    ..or better yet, just use perl to do the work.
    I can't think of any situation where one would
    need a perl script to invoke awk externally.. it's
    usually always more efficient to code it all within perl.

    eg. I'd always prefer these perl commands:

        my $padframe = sprintf("%04d", $frame);

    ..to these:

        my $padframe = `echo $frame | awk '{ printf("%04d\n",$0); }'`;
        chomp($padframe);

Agreed - I'm also much more comfortable using perl, so if I needed to replace my colleagues code I'd do that... as long as I could work out what he was trying to do with awk :)

	I'm pretty good at awk -- if you post the code here,
	I can probably translate it for you. Hope it ain't too large..


--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Cel: (Tel# suppressed)
Fax: (Tel# suppressed)