From: Luke Cole <luke@(email surpressed).au>
Subject: Rush + Autodesk Cleaner?
   Date: Thu, 29 Mar 2007 01:55:37 -0400

Hi,

Thanks,

---
Luke Cole
Research & Development

FUEL International
65 King St., Newtown, Sydney NSW, Australia 2042

	I advise taking rush out of the equation, and invoke your perl script
	directly from DOS, so that the system() command invokes the bat script,
	and check for exit code behavior that way.

	Can you show us the scripts you currently have?


Luke Cole wrote:

My initial attempt involved a rush render script in perl that would call Cleaner in command line mode via the perl system() call. This would result in Cleaner launching and displaying an error dialog complaining about invalid syntax, even though the exact same command typed into the console (rather than invoking it programmatically from perl using system()) executes successfully

	What's the command being run?

	Possibly it's just a matter of using the correct quoting
	of the command being passed to system().

As a second attempt, I created a small DOS batch file containing the Cleaner command and invoked this from my rush render script, hence shielding perl from the evil windows command switches (which only appear inside the batch file). Calling the batch file from the perl script worked better - the job is queued up and renders on our Cleaner machine successfully, the output from Cleaner is captured in the rush logs, unfortunately however the batch file never seems to return once the Cleaner render has finished, and so the rush job runs forever.

I tried putting in an exit statement in my batch file after the call to cleaner to ensure that the correct return code is being generated, however it seems that this line never gets called when I execute the bat file from within my perl render script - when I run the batch file directly in the console instead, everything behaves as expected.

	What happens if you run the perl script from the command line?
	Maybe it's not rush, but perl's system()?

I presume that this issue is due to the way the Win32 console behaves when invoked programmatically - I was wondering if there is some special trick that I need to get batch files working correctly with rush?

	Batch scripts should probably be run with:

		cmd /c \\path\to\foo.bat arg1 arg2

	In perl, you have to be sure to escape the backslashes correctly,
	so that the perl interpreter doesn't interpret the slashes as
	escape sequences (like \n, \e, etc)

	Show us what you have, and what command you're trying to run.
	(I myself am not familiar with the cleaner program)



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

Hi Greg,

[posted to rush.general]

	I advise taking rush out of the equation, and invoke your perl script

directly from DOS, so that the system() command invokes the bat script,

	and check for exit code behavior that way.

	Can you show us the scripts you currently have?

Here is the batch file (cleaner.bat):

EXIT /B 0

And the perl script that I have been using for experimentation purposes:

#!/usr/bin/perl -w
#
use strict;
use Sys::Hostname;
use File::Path;
use File::Copy;
use File::Basename;
#
# Globals
#
#$G::tmpdir = "/var/tmp/";
$G::homedir = $ENV{HOME};
$G::dotrushdir = "$G::homedir/.rush";

#
# Main Render
#
sub MainRender {

}

#
# Main Submit
#
sub MainSubmit {
    my $tmp = $G::dotrushdir . "/submit.$$";

    unless (open (SUBMIT, ">$tmp" ) )
        { print "open(>$tmp): $!\n", exit(1); }
    print SUBMIT << "EOF";
title           CleanerTest
ram             2048
frames          1
logdir          //starfish.fuel/indian/TVC_Tools/CleanerToolkit/logs

autodump        off
cpus            sparky=1\@99
EOF

#waitfor         -i %s
#waitforstate    done

    unless (close(SUBMIT) )
        { print "close($tmp): $1\n"; exit(1); }

    # Submit the job, parse out jobid
    my $out = `rush -submit spitfire < $tmp`; unlink ( $tmp );

    if ( $out =~ /RUSH_JOBID=(\S+)/ ) { $ENV{RUSH_JOBID} = $1; }
    else { print STDERR "$out\nSubmit failed.\n"; exit(1); }

    print "$ENV{RUSH_JOBID}\n";

    exit(0);
}


#
# MAIN FUNCTION
#
sub main {
    if (defined $ARGV[0] && $ARGV[0] eq "-render" ) {
        MainRender();
    } else {
        MainSubmit();
    }
}
main;

Luke Cole wrote:

My initial attempt involved a rush render script in perl that would call Cleaner in command line mode via the perl system() call. This would result in Cleaner launching and displaying an error dialog complaining about invalid syntax, even though the exact same command typed into the console (rather than invoking it programmatically from perl using system()) executes successfully

	What's the command being run?

The exact command being run looks something like this:

	Possibly it's just a matter of using the correct quoting
	of the command being passed to system().

As a second attempt, I created a small DOS batch file containing the Cleaner command and invoked this from my rush render script, hence shielding perl from the evil windows command switches (which only appear inside the batch file). Calling the batch file from the perl script worked better - the job is queued up and renders on our Cleaner machine successfully, the output from Cleaner is captured in the rush logs, unfortunately however the batch file never seems to return once the Cleaner render has finished, and so the rush job runs forever.

I tried putting in an exit statement in my batch file after the call to cleaner to ensure that the correct return code is being generated, however it seems that this line never gets called when I execute the bat file from within my perl render script - when I run the batch file directly in the console instead, everything behaves as expected.

	What happens if you run the perl script from the command line?
	Maybe it's not rush, but perl's system()?

I:\TVC_Tools\CleanerToolkit\bin>perl rush_cleaner_script.pl -render

--- Progress: 0% completed. ---
--- Progress: 0% completed. ---
--- Progress: 0% completed. ---
--- Progress: 0% completed. ---
--- Progress: 2% completed. ---
--- Progress: 3% completed. ---
--- Progress: 5% completed. ---
--- Progress: 6% completed. ---
--- Progress: 8% completed. ---
--- Progress: 9% completed. ---
--- Progress: 11% completed. ---
--- Progress: 13% completed. ---
--- Progress: 14% completed. ---
--- Progress: 16% completed. ---
--- Progress: 17% completed. ---
--- Progress: 19% completed. ---
--- Progress: 20% completed. ---
--- Progress: 22% completed. ---
--- Progress: 23% completed. ---
--- Progress: 25% completed. ---
--- Progress: 27% completed. ---
--- Progress: 28% completed. ---
--- Progress: 30% completed. ---
--- Progress: 31% completed. ---
--- Progress: 33% completed. ---
--- Progress: 35% completed. ---
--- Progress: 36% completed. ---
--- Progress: 37% completed. ---
--- Progress: 38% completed. ---
--- Progress: 40% completed. ---
--- Progress: 41% completed. ---
--- Progress: 43% completed. ---
--- Progress: 44% completed. ---
--- Progress: 46% completed. ---
--- Progress: 48% completed. ---
--- Progress: 49% completed. ---
--- Progress: 51% completed. ---
--- Progress: 52% completed. ---
--- Progress: 54% completed. ---
--- Progress: 55% completed. ---
--- Progress: 57% completed. ---
--- Progress: 58% completed. ---
--- Progress: 60% completed. ---
--- Progress: 61% completed. ---
--- Progress: 63% completed. ---
--- Progress: 64% completed. ---
--- Progress: 66% completed. ---
--- Progress: 68% completed. ---
--- Progress: 69% completed. ---
--- Progress: 71% completed. ---
--- Progress: 72% completed. ---
--- Progress: 74% completed. ---
--- Progress: 76% completed. ---
--- Progress: 77% completed. ---
--- Progress: 79% completed. ---
--- Progress: 80% completed. ---
--- Progress: 82% completed. ---
--- Progress: 83% completed. ---
--- Progress: 84% completed. ---
--- Progress: 86% completed. ---
--- Progress: 87% completed. ---
--- Progress: 89% completed. ---
--- Progress: 91% completed. ---
--- Progress: 93% completed. ---
--- Progress: 95% completed. ---
--- Progress: 96% completed. ---
--- Progress: 98% completed. ---
--- Processing Time: 00:01:17. ---
--- Task Processing Time: 00:01:08. ---
--- Progress: 99% completed. ---

I:\TVC_Tools\CleanerToolkit\bin>EXIT /B 0

I:\TVC_Tools\CleanerToolkit\bin>

For example, if I change the batch file to look like this:

echo -- FINISHED
EXIT /B 0

And submit it to rush, I end up with a log file that looks like so:

--------------- Rush 102.42 --------------
--      Host: sparky
--       Pid: 2428
--     Title: CleanerTest
--     Jobid: spitfire.946
--     Frame: 0001
--     Tries: 0
--     Owner: lrcole (1031/1031)
-- RunningAs: netrender
--  Priority: 99
--      Nice: 10
--    Tmpdir: C:/TEMP/.RUSH_TMP.331
--   LogFile: //starfish.fuel/indian/TVC_Tools/CleanerToolkit/logs/0001

--   Started: Fri Mar 30 11:43:55 2007
------------------------------------------

--- Progress: 0% completed. ---
--- Progress: 0% completed. ---
--- Progress: 0% completed. ---
--- Progress: 0% completed. ---
--- Progress: 1% completed. ---
--- Progress: 2% completed. ---
--- Progress: 4% completed. ---
--- Progress: 4% completed. ---
--- Progress: 5% completed. ---
--- Progress: 7% completed. ---
--- Progress: 8% completed. ---
--- Progress: 9% completed. ---
--- Progress: 11% completed. ---
--- Progress: 12% completed. ---
--- Progress: 13% completed. ---
--- Progress: 14% completed. ---
--- Progress: 15% completed. ---
--- Progress: 16% completed. ---
--- Progress: 17% completed. ---
--- Progress: 19% completed. ---
--- Progress: 20% completed. ---
--- Progress: 21% completed. ---
--- Progress: 22% completed. ---
--- Progress: 24% completed. ---
--- Progress: 25% completed. ---
--- Progress: 26% completed. ---
--- Progress: 27% completed. ---
--- Progress: 28% completed. ---
--- Progress: 29% completed. ---
--- Progress: 30% completed. ---
--- Progress: 31% completed. ---
--- Progress: 33% completed. ---
--- Progress: 34% completed. ---
--- Progress: 35% completed. ---
--- Progress: 36% completed. ---
--- Progress: 38% completed. ---
--- Progress: 39% completed. ---
--- Progress: 40% completed. ---
--- Progress: 41% completed. ---
--- Progress: 42% completed. ---
--- Progress: 44% completed. ---
--- Progress: 45% completed. ---
--- Progress: 46% completed. ---
--- Progress: 47% completed. ---
--- Progress: 48% completed. ---
--- Progress: 49% completed. ---
--- Progress: 51% completed. ---
--- Progress: 52% completed. ---
--- Progress: 53% completed. ---
--- Progress: 54% completed. ---
--- Progress: 55% completed. ---
--- Progress: 57% completed. ---
--- Progress: 58% completed. ---
--- Progress: 59% completed. ---
--- Progress: 60% completed. ---
--- Progress: 61% completed. ---
--- Progress: 62% completed. ---
--- Progress: 63% completed. ---
--- Progress: 64% completed. ---
--- Progress: 65% completed. ---
--- Progress: 66% completed. ---
--- Progress: 68% completed. ---
--- Progress: 69% completed. ---
--- Progress: 70% completed. ---
--- Progress: 71% completed. ---
--- Progress: 73% completed. ---
--- Progress: 74% completed. ---
--- Progress: 75% completed. ---
--- Progress: 76% completed. ---
--- Progress: 78% completed. ---
--- Progress: 79% completed. ---
--- Progress: 80% completed. ---
--- Progress: 81% completed. ---
--- Progress: 82% completed. ---
--- Progress: 84% completed. ---
--- Progress: 85% completed. ---
--- Progress: 86% completed. ---
--- Progress: 87% completed. ---
--- Progress: 89% completed. ---
--- Progress: 90% completed. ---
--- Progress: 92% completed. ---
--- Progress: 93% completed. ---
--- Progress: 95% completed. ---
--- Progress: 96% completed. ---
--- Progress: 98% completed. ---
--- Processing Time: 00:01:36. ---
--- Task Processing Time: 00:01:27. ---
--- Progress: 99% completed. ---

The echo command I added to the batch is never called.

I presume that this issue is due to the way the Win32 console behaves when invoked programmatically - I was wondering if there is some special trick that I need to get batch files working correctly with rush?

	Batch scripts should probably be run with:

		cmd /c \\path\to\foo.bat arg1 arg2

	In perl, you have to be sure to escape the backslashes correctly,
	so that the perl interpreter doesn't interpret the slashes as
	escape sequences (like \n, \e, etc)

	Show us what you have, and what command you're trying to run.
	(I myself am not familiar with the cleaner program)

---
Luke Cole
Research & Development

FUEL International
65 King St., Newtown, Sydney NSW, Australia 2042

	First, what happens if you avoid the cleaner.bat approach completely,
	and just try this:

sub MainRender()
{
    my $err = system('"C:\Program Files\Autodesk\Cleaner XL 1.5\Cleaner XL" '.
                     '/I I:\TVC_Tools\CleanerToolkit\profiles\input\DV_PAL_4x3.ip '.
                     '/O I:\TVC_Tools\CleanerToolkit\profiles\output\3GP_PAL_4x3.opt '.
                     '/D I:\TVC_Tools\CleanerToolkit\renders '.
                     '/sources I:\TVC_Tools\CleanerToolkit\test_data\test.mov');
    if ( $err ) { print "--- FAILED\n"; exit(1); }
    print "--- OK\n";
    exit(0);
}

	..being sure that system line is all on one line.
	(My apologies for any typos, as I didn't test it, but I think I specified
	that correctly)

	If that doesn't fly, read on..

Luke Cole wrote:

Here is the batch file (cleaner.bat):

CMD /C ""C:\Program Files\Autodesk\Cleaner XL 1.5\Cleaner XL" /I %1 /O %2 /D %3 /sources %4"
EXIT /B 0

	One quick suggestion about the cleaner.bat file: make it a one line program that reads:

"C:\Program Files\Autodesk\Cleaner XL 1.5\Cleaner XL" /I %1 /O %2 /D %3 /sources %4

	The batch script should return the exit code of the 'cleaner xl' program
	without an 'exit' command present.

	BTW, what I meant about add the 'cmd /c' was when you called
	the cleaner.bat from within the system() command, eg:

sub MainRender {
    system('cmd /c I:\TVC_Tools\CleanerToolkit\bin\cleaner.bat ..');

	Anyway, try those tweaks, and when I get back tonight, I'll try
	some tests if you don't have any luck.

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

Hi Greg,

[posted to rush.general]

	First, what happens if you avoid the cleaner.bat approach completely,
	and just try this:

sub MainRender()
{

my $err = system('"C:\Program Files\Autodesk\Cleaner XL 1.5 \Cleaner XL" '. '/I I:\TVC_Tools\CleanerToolkit\profiles\input \DV_PAL_4x3.ip '. '/O I:\TVC_Tools\CleanerToolkit\profiles\output \3GP_PAL_4x3.opt '.

                     '/D I:\TVC_Tools\CleanerToolkit\renders '.

'/sources I:\TVC_Tools\CleanerToolkit\test_data \test.mov');

    if ( $err ) { print "--- FAILED\n"; exit(1); }
    print "--- OK\n";
    exit(0);
}

	..being sure that system line is all on one line.

(My apologies for any typos, as I didn't test it, but I think I specified

	that correctly)

	If that doesn't fly, read on..

Thanks,

---
Luke Cole
Research & Development

FUEL International
65 King St., Newtown, Sydney NSW, Australia 2042

Luke Cole wrote:

OK, I've updated my code as you suggested, and it seems to submit OK now, so when I tried it out originally, there must have been something wrong with my escaping in the system() call.

	Good..

I still encounter the issue where the rush job runs forever however, even though the cleaner render is finished according to the output in the log file - I just checked the windows task manager on the machine and have noticed that "Cleaner XL.com" is still running, so this would explain why the rush job is still going. I'm not sure why Cleaner is not exiting when it is launched from the rush perl script - when I run the command ("C:\Program Files\ etc) directly in the win32 console, it exits after the render is done.

	OK, now that we're sure cleaner is the one that's hanging,
	I have a suggestion. It's going to sound silly, but change
	all your I: specifications to a UNC equivalent if possible.

	Assuming the I: drive is a network drive and has a UNC equivalent
	(and is not a SAN or local drive), be careful with the double
	slashes of the UNC; you'll need to use \\\\ to get a double slash,
	but just use singles for the single slashes, eg:

    my $err = system('"C:\Program Files\Autodesk\Cleaner XL 1.5\Cleaner XL" '.
                     '/I \\\\someserver\somevol\TVC_Tools\CleanerToolkit\profiles\input\DV_PAL_4x3.ip '.
                     '/O \\\\someserver\somevol\TVC_Tools\CleanerToolkit\profiles\output\3GP_PAL_4x3.opt '.
                     '/D \\\\someserver\somevol\TVC_Tools\CleanerToolkit\renders '.
                     '/sources \\\\someserver\somevol\TVC_Tools\CleanerToolkit\test_data\test.mov');

	I know it looks weird, but the reasoning is that '\\' *even*
	inside single quotes is still a special case. So you only
	double up on the escaping for the first slashes, not the rest.

Something I noticed when I run the Cleaner command in the windows console - it launches the Cleaner GUI and then closes it all down again when it exits after the render, however this does not happen when I submit through rush, so I am guessing that this output is redirected somehow.

	Yes; windows services are assigned a 'virtual desktop'
	where stuff like that gets redirected as you say.
	They really need to get rid of all GUI stuff though
	for their command line app -- that can cause lots of
	trouble.

Additionally, one other thing that I have noticed is that if I now try to run the modified perl script directly in the windows console (as opposed to submitting it via rush), I now receive the Cleaner error dialog that I referred to before. This does not seem to occur however when I launch the job from rush, so I guess it isn't really a problem. Weird.

	If you'd like to try to replicate outside of rush, and
	assuming the above UNC technique either doesn't help
	or is not relevant, try this:

		1) Enable the Windows telnet service on this machine. See:
		   WINXP TELNET: http://www.seriss.com/rush-current/misc/windows-telnet.html#WinXP
		   WIN2K TELNET: http://www.seriss.com/rush-current/misc/windows-telnet.html#Win2K
		   WIN2K3 TELNET: http://www.seriss.com/rush-current/misc/windows-telnet.html#Win2K3

		2) Telnet into the machine, and run your command.

	Does it hang? If so, you have a way to replicate the problem
	for Autodesk.

	And while you're at it, definitely report two bugs to Autodesk:

	    a) Having spaces in executable names is just really bad practice.

	    b) Using front slashes for option flags is also REALLY BAD.
               Besides making porting impossible, it disables the use
               of front slash UNC pathnames, which IS supported by Windows.

	Regarding (b), just because Microsoft made that mistake in 1985
	with DOS (which we now have to live with) doesn't mean Autodesk
	should follow their lead in 2007 to make life doubly miserable
	for command line scripting. GRR!

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

Hi Greg,

	OK, now that we're sure cleaner is the one that's hanging,
	I have a suggestion. It's going to sound silly, but change
	all your I: specifications to a UNC equivalent if possible.

	Assuming the I: drive is a network drive and has a UNC equivalent
	(and is not a SAN or local drive), be careful with the double
	slashes of the UNC; you'll need to use \\\\ to get a double slash,
	but just use singles for the single slashes, eg:

my $err = system('"C:\Program Files\Autodesk\Cleaner XL 1.5 \Cleaner XL" '. '/I \\\\someserver\somevol\TVC_Tools \CleanerToolkit\profiles\input\DV_PAL_4x3.ip '. '/O \\\\someserver\somevol\TVC_Tools \CleanerToolkit\profiles\output\3GP_PAL_4x3.opt '. '/D \\\\someserver\somevol\TVC_Tools \CleanerToolkit\renders '. '/sources \\\\someserver\somevol\TVC_Tools \CleanerToolkit\test_data\test.mov');

	I know it looks weird, but the reasoning is that '\\' *even*
	inside single quotes is still a special case. So you only
	double up on the escaping for the first slashes, not the rest.

	If you'd like to try to replicate outside of rush, and
	assuming the above UNC technique either doesn't help
	or is not relevant, try this:

		1) Enable the Windows telnet service on this machine. See:

WINXP TELNET: http://www.seriss.com/rush-current/misc/windows- telnet.html#WinXP WIN2K TELNET: http://www.seriss.com/rush-current/misc/windows- telnet.html#Win2K WIN2K3 TELNET: http://www.seriss.com/rush-current/misc/windows- telnet.html#Win2K3

		2) Telnet into the machine, and run your command.

	Does it hang? If so, you have a way to replicate the problem
	for Autodesk.

	And while you're at it, definitely report two bugs to Autodesk:

	    a) Having spaces in executable names is just really bad practice.

	    b) Using front slashes for option flags is also REALLY BAD.
               Besides making porting impossible, it disables the use

of front slash UNC pathnames, which IS supported by Windows.

	Regarding (b), just because Microsoft made that mistake in 1985
	with DOS (which we now have to live with) doesn't mean Autodesk
	should follow their lead in 2007 to make life doubly miserable
	for command line scripting. GRR!

L8r,

---
Luke Cole
Research & Development

FUEL International
65 King St., Newtown, Sydney NSW, Australia 2042

Luke,

-Phil


On Mar 30, 2007, at 1:10 AM, Luke Cole wrote:

[posted to rush.general]

Hi Greg,

	OK, now that we're sure cleaner is the one that's hanging,
	I have a suggestion. It's going to sound silly, but change
	all your I: specifications to a UNC equivalent if possible.

	Assuming the I: drive is a network drive and has a UNC equivalent
	(and is not a SAN or local drive), be careful with the double
	slashes of the UNC; you'll need to use \\\\ to get a double slash,
	but just use singles for the single slashes, eg:

my $err = system('"C:\Program Files\Autodesk\Cleaner XL 1.5 \Cleaner XL" '. '/I \\\\someserver\somevol\TVC_Tools \CleanerToolkit\profiles\input\DV_PAL_4x3.ip '. '/O \\\\someserver\somevol\TVC_Tools \CleanerToolkit\profiles\output\3GP_PAL_4x3.opt '. '/D \\\\someserver\somevol\TVC_Tools \CleanerToolkit\renders '. '/sources \\\\someserver\somevol\TVC_Tools \CleanerToolkit\test_data\test.mov');

	I know it looks weird, but the reasoning is that '\\' *even*
	inside single quotes is still a special case. So you only
	double up on the escaping for the first slashes, not the rest.

OK, I updated the paths to their UNC equivalents as you recommended, however the Cleaner program is still not returning after the render finishes.

	If you'd like to try to replicate outside of rush, and
	assuming the above UNC technique either doesn't help
	or is not relevant, try this:

		1) Enable the Windows telnet service on this machine. See:

WINXP TELNET: http://www.seriss.com/rush-current/misc/windows- telnet.html#WinXP WIN2K TELNET: http://www.seriss.com/rush-current/misc/windows- telnet.html#Win2K WIN2K3 TELNET: http://www.seriss.com/rush-current/misc/ windows-telnet.html#Win2K3

		2) Telnet into the machine, and run your command.

	Does it hang? If so, you have a way to replicate the problem
	for Autodesk.

I tested this out as well, and was indeed able to replicate the problem - when I launch the command I receive the following message:

ERR: An unexpected error occurred. See details below, specifically noting the Inner Exception.

That's all I get, the telnet session hangs then and I can't do anything else.

	And while you're at it, definitely report two bugs to Autodesk:

a) Having spaces in executable names is just really bad practice.

	    b) Using front slashes for option flags is also REALLY BAD.
               Besides making porting impossible, it disables the use

of front slash UNC pathnames, which IS supported by Windows.

	Regarding (b), just because Microsoft made that mistake in 1985
	with DOS (which we now have to live with) doesn't mean Autodesk
	should follow their lead in 2007 to make life doubly miserable
	for command line scripting. GRR!

So, looks like I have some bugs to submit to Autodesk now - it is disappointing that their command line interface is so poorly designed. Thanks very much for helping me out with this!

L8r,

---
Luke Cole
Research & Development

FUEL International
65 King St., Newtown, Sydney NSW, Australia 2042

Hi Phil,

Sure, I'll let you know if I am able to sort something out.

L8r,

Luke

On 30/03/2007, at 6:15 PM, Phil Pham wrote:

[posted to rush.general]

Luke,

Let me know if you ever get this working. I wouldn't mind being able to launch cleaner from a command line after a render as well.

-Phil


On Mar 30, 2007, at 1:10 AM, Luke Cole wrote:

[posted to rush.general]

Hi Greg,

	OK, now that we're sure cleaner is the one that's hanging,
	I have a suggestion. It's going to sound silly, but change
	all your I: specifications to a UNC equivalent if possible.

	Assuming the I: drive is a network drive and has a UNC equivalent
	(and is not a SAN or local drive), be careful with the double
	slashes of the UNC; you'll need to use \\\\ to get a double slash,
	but just use singles for the single slashes, eg:

my $err = system('"C:\Program Files\Autodesk\Cleaner XL 1.5 \Cleaner XL" '. '/I \\\\someserver\somevol\TVC_Tools \CleanerToolkit\profiles\input\DV_PAL_4x3.ip '. '/O \\\\someserver\somevol\TVC_Tools \CleanerToolkit\profiles\output\3GP_PAL_4x3.opt '. '/D \\\\someserver\somevol\TVC_Tools \CleanerToolkit\renders '. '/sources \\\\someserver\somevol\TVC_Tools \CleanerToolkit\test_data\test.mov');

	I know it looks weird, but the reasoning is that '\\' *even*
	inside single quotes is still a special case. So you only
	double up on the escaping for the first slashes, not the rest.

OK, I updated the paths to their UNC equivalents as you recommended, however the Cleaner program is still not returning after the render finishes.

	If you'd like to try to replicate outside of rush, and
	assuming the above UNC technique either doesn't help
	or is not relevant, try this:

		1) Enable the Windows telnet service on this machine. See:

WINXP TELNET: http://www.seriss.com/rush-current/misc/ windows-telnet.html#WinXP WIN2K TELNET: http://www.seriss.com/rush-current/misc/ windows-telnet.html#Win2K WIN2K3 TELNET: http://www.seriss.com/rush-current/misc/ windows-telnet.html#Win2K3

		2) Telnet into the machine, and run your command.

	Does it hang? If so, you have a way to replicate the problem
	for Autodesk.

I tested this out as well, and was indeed able to replicate the problem - when I launch the command I receive the following message:

ERR: An unexpected error occurred. See details below, specifically noting the Inner Exception.

That's all I get, the telnet session hangs then and I can't do anything else.

	And while you're at it, definitely report two bugs to Autodesk:

a) Having spaces in executable names is just really bad practice.

	    b) Using front slashes for option flags is also REALLY BAD.

Besides making porting impossible, it disables the use of front slash UNC pathnames, which IS supported by Windows.

	Regarding (b), just because Microsoft made that mistake in 1985
	with DOS (which we now have to live with) doesn't mean Autodesk
	should follow their lead in 2007 to make life doubly miserable
	for command line scripting. GRR!

So, looks like I have some bugs to submit to Autodesk now - it is disappointing that their command line interface is so poorly designed. Thanks very much for helping me out with this!

L8r,

---
Luke Cole
Research & Development

FUEL International
65 King St., Newtown, Sydney NSW, Australia 2042

---
Luke Cole
Research & Development

FUEL International
65 King St., Newtown, Sydney NSW, Australia 2042

Saker Klippsten wrote:
> I to would like to get cleaner working :)

	I think it's hit a wall with the 'run as a service' thing,
	where he replicated the hang from a DOS command line using
	telnet, and is going to report it as a bug to Autodesk.

	You can *probably* get past this hanging problem by, instead
	of running rushd as a service on the windows machines,
	running it from a DOS prompt (so that the renders have access to the desktop).

	That's sucky though to do for an entire farm, because logging
	out will kill rushd when configured this way, and it would mean
	you'd have to leave all the nodes logged in with rushd running
	in a DOS window, which is silly, and is an UGLY workaround.

	But if you do it only on one dedicated box, maybe it's worth it
	to specially configure rush on that one box to run from DOS.
	There's a description of how to configure Rushd to run from DOS
	instead of as a service here:
	http://www.seriss.com/rush-current/issues-afterfx-7.0/index.html#DualProc

	The real problem here is the Cleaner command line tool is actually
	trying to use the desktop, which is bad for any kind of command line
	based tool intended for distributed rendering. The vendor, Autodesk,
	needs to fix that. (And the spaces in the Cleaner's executable name,
	and the frontslash argument stuff would be secondary, but also important..)

Luke Cole wrote:

"C:\Program Files\Autodesk\Cleaner XL 1.5\Cleaner XL"

	BTW, I can't help but ask..

	Is it the case this cleaner program actually has spaces not only
	in the path, but the tool's own executable actually has *spaces*
	in it too? (*sigh*)

	And of course the use of front slashes for options is really bad.
	Good luck porting that interface to unix is all I can say.


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

Hi Greg,

[posted to rush.general]

Luke Cole wrote:

"C:\Program Files\Autodesk\Cleaner XL 1.5\Cleaner XL"

	BTW, I can't help but ask..

	Is it the case this cleaner program actually has spaces not only
	in the path, but the tool's own executable actually has *spaces*
	in it too? (*sigh*)

Yeah, it actually does.   :(

	And of course the use of front slashes for options is really bad.
	Good luck porting that interface to unix is all I can say.

---
Luke Cole
Research & Development

FUEL International
65 King St., Newtown, Sydney NSW, Australia 2042