Permissions required to execute a Command Line Tool (CLT)?

...the process returns with error code "1" ...and no other info

Make sure that you check not only command STDOUT but STDERR as well. I doubt that command just dies ungracefully

That command *should* not have any restrictions. Have you dumped out the exact command you are trying to a file ?

This should generate some XML, are you trying to redirect that to a file ? are the permissions set appropriately for the path ?

And don't dis CLTs. GUIs are for people with weak minds.

Yeah, I'm redirecting both STDOUT and STDERR to the same log, and all I get is the following.

Note that to make sure it's not the code but rather something environmental, I recently add a cygwin "ps.exe" command just before I run the iwgetwfobj command. The ps.exe command comes back just fine whereas the iwgetwfobj does not.


2008-01-04 11:08:18,177 DEBUG .2008-01-04 11:08:18,177 DEBUG 
DotCom.Web.WorkflowUtil.Iwov.WorkflowCommandLineDriver [(null)] - 
The testoutput of running C:\cygwin\bin\ps.exe is '
      PID    PPID    PGID     WINPID  TTY  UID    STIME COMMAND
     6180       1    6180       6180  con 1038 11:08:18 /usr/bin/ps
'
2008-01-04 11:08:18,177 DEBUG 
DotCom.Web.WorkflowUtil.Iwov.CommandLineUtils [(null)] - 
Executing command: 'C:\Interwoven\TeamSite\bin\iwgetwfobj.exe 123'
2008-01-04 11:08:18,583 DEBUG 
DotCom.Web.WorkflowUtil.Iwov.CommandLineUtils [(null)] - 
I read this from our process: 
                                         ***<<-- expecting XML HERE
2008-01-04 11:08:18,583 DEBUG DotCom.Web.WorkflowUtil.Iwov.CommandLineUtils [(null)] - 
The process exit code is: '1'

I'm not trying to redirect the XML to a file; just trying to suck it in directly off of STDOUT.

are the permissions set appropriately for the path ?

Not sure what you mean by that; both the iwgetwfobj.exe and ps.exe are set to "Full Control" by "Everyone", so that shouldn't be the issue, right?

You are getting the debug information properly, so ignore the path question.

2 things to try, do any ts commands work ? something easy like iwversion ?

Also run a DOS command (maybe dir iwhome\bin) and dump that to the file

Yeah, I'm redirecting both STDOUT and STDERR to the same log

How exactly do you redirect to the same File? Note that something like "command >my.log 2>my.log" will fail.
The reason is that shell can not open already opened log File for the STDOUT Stream (STDERR is always first).
You should use either "command >my.log 2>myErr.log" or "command >my.log 2>&1"

No, he could do

iwgetwfojb.exe 123 2>&1 which will send STDERR to STDOUT

So I assume he is piping them together and then dumping the STDOUT to the file he posted.

Of course what I am writing is for Unix. Cygwin will work the same way, not certain about the code he is using

The "Process" class in .NET allows you to attach listeners to the object's stdout and stderr members (just like in Java). So you can consolidate all output into one string stream an write it out to a standard log, as configured by Log4Net.

The "Process" class in .NET allows you to attach listeners to the object's stdout and stderr members (just like in Java). So you can consolidate all output into one string stream an write it out to a standard log, as configured by Log4Net.

Be it as it may, RC 1 indicates some processing issue. I never saw TS Command dying without STDERR output.
So, IMO you definitely have some command execution problem and you are losing error output somewhere in the .NET obscurity.

No, he could do iwgetwfojb.exe 123 2>&1...

Yeah, that was the second option I've recommended to Tbag...

You guys got me thinking and instead of having the Process run the "iwgetwjobj.exe 1234" directly, I had it run a .bat file that I wrapped around the .exe. The contents of the bat file are basically:

iwgetwfobj.exe 52403 > C:\Temp\bin\foo.txt 2<&1

When I run that in DOS, I get the expected XML spit out into foo.txt

When I run that from IIS, the contents of foo.txt are:

"Could not connect to IWSERVER"

I verified that the environment settings in the DOS prompt are the same as those in the IIS runtime, so it's not that.

Any other ideas?

Adam Stoller

Yeah, I'm redirecting both STDOUT and STDERR to the same log, and all I get is the following.

Note that to make sure it's not the code but rather something environmental, I recently add a cygwin "ps.exe" command just before I run the iwgetwfobj command. The ps.exe command comes back just fine whereas the iwgetwfobj does not.
...

Are you trying to run the command from the DOS Command prompt, or from the Cygwin shell?

You might find problems trying to run some of the TS CLTs from Cygwin shells.

I'm trying to run the command from within an .NET application; the process runs as the user "ASPNET", which in and of itself shouldn't preclude execution, right?

In case there's some mojo related to that user, I added him to "Full Control" on the exe and "directory chain" in question on my dev environment; to no avail :-(

You guys got me thinking and instead of having the Process run the "iwgetwjobj.exe 1234" directly, I had it run a .bat file that I wrapped around the .exe. The contents of the bat file are basically:

iwgetwfobj.exe 52403 > C:\Temp\bin\foo.txt 2<&1

When I run that in DOS, I get the expected XML spit out into foo.txt

When I run that from IIS, the contents of foo.txt are:

"Could not connect to IWSERVER"

I verified that the environment settings in the DOS prompt are the same as those in the IIS runtime, so it's not that.

Any other ideas?

Can you dump out your environment variables in that script ? Also run a dir y: in that script and dump the contents.

It behaves as if it is executing on a different system other than the TeamSite server.

Are you trying to run the command from the DOS Command prompt, or from the Cygwin shell?

You might find problems trying to run some of the TS CLTs from Cygwin shells.

I have never had an issue running anything from cygwin except that I need to include the .bat if I am running something like iwodserverreser

The environment variables (per DOS's "> set") and "dir Y:" are as follows:


2008-01-04 15:57:16,168 DEBUG DotCom.Web.WorkflowUtil.Iwov.CommandLineUtils [(null)] - 
Executing command: 'C:\Temp\bin\iwgetwfobj.bat 52403'
2008-01-04 15:57:16,246 DEBUG 
.DotCom.Web.WorkflowUtil.Iwov.CommandLineUtils [(null)] - 
I read this from our process: 
ALLUSERSPROFILE=C:\Documents and Settings\All Users
APR_ICONV_PATH=C:\Program Files\Subversion\iconv
CommonProgramFiles=C:\Program Files\Common Files
COMPUTERNAME=xxxxxxxx
ComSpec=C:\WINNT\system32\cmd.exe
IWOD60HOME=C:\Interwoven\OpenDeployNG
IWODHOME=C:\Interwoven\OpenDeployNG
JAVA_HOME=C:\Program Files\Java\j2re1.4.2_14\
LDMS_LOCAL_DIR=C:\Program Files\LANDesk\LDClient\Data
NUMBER_OF_PROCESSORS=4
OS=Windows_NT
Os2LibPath=C:\WINNT\system32\os2\dll;
Path=C:\oracle\ora92\bin;C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem;C:\Program Files\Common Files\Interwoven\lib;C:\Interwoven\TeamSite\bin;C:\Program Files\Common Files\Interwoven\lib;C:\Program Files\WinVi;C:\Interwoven\TeamSite\iw-perl\bin;C:\program files\java\j2re1.4.2_14\bin;C:\Interwoven\TeamSite\cssdk;C:\Program Files\Subversion\bin
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
Path_Old=C:\oracle\ora92\bin;C:\Program Files\Oracle\jre\1.3.1\bin;C:\Program Files\Oracle\jre\1.1.8\bin;C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem;C:\Program Files\Common Files\Interwoven\lib;C:\Interwoven\TeamSite\bin;C:\Program Files\Common Files\Interwoven\lib;C:\Program Files\WinVi;C:\Interwoven\TeamSite\iw-perl\bin
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel
PROCESSOR_LEVEL=15
PROCESSOR_REVISION=0304
ProgramFiles=C:\Program Files
PROMPT=$P$G
SystemDrive=C:
SystemRoot=C:\WINNT
TEMP=C:\DOCUME~1\xxxxxxx\ASPNET\LOCALS~1\Temp
TMP=C:\DOCUME~1\xxxxxxxx\ASPNET\LOCALS~1\Temp
TS_ENV=aarf
USERDOMAIN=xxxxxxxx
USERNAME=ASPNET
USERPROFILE=C:\Documents and Settings\xxxxxxxx\ASPNET
windir=C:\WINNT

 Volume in drive Y is IFS Volume
 Volume Serial Number is E774-2000
 Directory of Y:\
03/15/2007  12:53p      DIR          default
08/20/2007  04:10p      DIR          external
               0 File(s)              0 bytes
               2 Dir(s)  28,697,202,688 bytes free

--- Contents of foo.txt: --- 
Could not connect to IWSERVER

2008-01-04 15:57:16,246 DEBUG DotCom.Web.WorkflowUtil.Iwov.CommandLineUtils [(null)] - 
The process exit code is: '0'

How about adding the server name

iwgetwftobj -s servername 123

Could not connect to IWSERVER...

Every time I saw this error (and another similar one) mentioned it has been related to the "SYSTEMROOT" Environment Variable.
Note that the name has all capital letters, that's how it should be!

Depending on MS Server it's either C:\WINDOWS or C:\WINNT. I *believe* that in your case (Win 2003, right?) it should be 'C:\WINDOWS'
(not 'C:\WINNT') in order for TS CLT to work. Try to reset this Variable to C:\WINDOWS in your batch file right before calling iwgetwfobj,
see if that helps

Those were good ideas, nipper and Boris.

When I tried the "-s flag" to specify the server, whatever servername I gave it ended up being echoed in the "Cannot connect to ____" message.

In otherwords, iwgetwfobj.exe -s localhost 123 => "Cannot connect to localhost"

And iwgetwfobj.exe -s myservername 123 => "Cannot connect to my servername"

And iwgetwfobj.exe -s myservername.my.domain 123 => "Cannot connect to myservername.my.domain"

I also tried setting the SYSTEMROOT environment var to C:\WINNT (this particular box is Windows 2000 SP4...despite what my signature says) and that didn't seem to have any impact either.

Any other ideas?

I also tried setting the SYSTEMROOT environment var to C:\WINNT (this particular box is Windows 2000 SP4...despite what my signature says) and that didn't seem to have any impact either.

Just for the sake of it, have you tried to set SYSTEMROOT to C:\Windows? Ignore your Environment native "SystemRoot" settings.
Environment Variables are case-sensitive, SYSTEMROOT is a different one