I'm trying to capture exit code from an ssis execute process task into a variable. The exit code is a string, although the value itself is an integer, value of 0 or 1 is success, other mean failure.
As far as I know I cannot specify multiple success values within the "Success value property", so I decided to capture the exit code into a variable, pass it to Execute script task and evaluate there whether the exit code represents success or failure.
I've set up a string variable to capture the exit code of my app, with type string.
Unfortunately, the value is empty after Process task execution, no matter whether I put my variable directly into StandardOutputVariable or into Expressions tab:
On execution, in the Locals windows in debug mode I see the value is empty (e.g. {}).
Is there a way to overcome this?
I'd appreciate any feedback.
Whatever you are capturing in the variable, is not the exit code. It is the output value (StandardOutput).
For getting the exit code, what you have to do is, in the command arguments, add the below suffix
Executable: cmd.exe
Arguments: /C mycmd_with_parameters;echo %ERRORLEVEL%
%errorlevel% will be having the exit code of the executable. You are outputting that to standard output. More info on %Errorlevel%
There is one caveat:
When an external command is run by CMD.EXE, it will detect the
executable's Return or Exit Code and set the ERRORLEVEL to match. In
most cases the ERRORLEVEL will be the same as the Exit code, but there
are some cases where they can differ.
An Exit Code can be detected directly with redirection operators
(Success/Failure ignoring the ERRORLEVEL) this can often be more
reliable than trusting the ERRORLEVEL which may or may not have been
set correctly.
Now, you will get the exitcode of the executable as standardoutput and you can capture it to the variable, as you have configured.
The StandardOutputVariable of an Execute Process Task contains the terminal output. So, if you are using a bash executable, all ECHO results should be saved on that variable.
You can check the variable values during runtime debug.
Related
I'm trying to write a Tcl script which loads a simulation in ModelSim and then does some other stuff, so it needs to determine if the simulation loaded successfully or not. But the vsim command does not seem to return any value, at least that I can figure out how to capture. As a test, I did:
set rv [vsim $sim_name]
$rv is always empty, regardless of whether the sim loaded or not, so using catch doesn't work. My current workaround is to try something after loading that only works in a simulation context and that does return a value, and catch that instead. For example:
vsim $sim_name
if {[catch {log *} ...
But that's far from ideal. Is there a better way to detect whether or not vsim ran successfully?
For handling elaboration errors at the startup of simulations you can associate a callback using the onElabError command. Your callback can set a global variable that you examine later:
onElabError {global vsim_init_failure; set vsim_init_failure 1}
...
set vsim_init_failure 0
vsim $sim_name
if {$vsim_init_failure} ...
I am running a shell script which emits lots of line while executing...they are just status output rather than the actual output....
I want them to be displayed on a JTextArea. I am working on jython. The piece of my code looks like:
self.console=JTextArea(20,80)
cmd = "/Users/name/galaxy-dist/run.sh"
p = subprocess.Popen(cmd, stdout=subprocess.PIPE,stderr=subprocess.PIPE, shell=True)
self.console.append(p.stdout.read())
This will wait until the command finishes and prints the output. But I want to show the realtime out put to mimic the console. Anybody have the idea ?
You're making things more complicated than they need to be. The Popen docs state the following about the stream arguments:
With the default settings of None, no redirection will occur; the child’s file handles will be inherited from the parent. [my emphasis]
Therefore, if you want the subprocess' output to go to your stdout, simply leave those arguments blank:
subprocess.Popen(cmd, shell=True)
In fact, you aren't using any of the more advanced features of the Popen constructor, and this particular example doesn't need any parsing by the shell, so you can simplify it further with the subprocess.call() function:
subprocess.call(cmd)
If you still want the return code, simply set a variable equal to this call:
return_code = subprocess.call(cmd)
I have this snippet in my script:
puts "Enter Filename:"
set file_name [gets stdin]
set fh [open $file_name r]
#Read from the file ....
close $fh
Now, this snippet asks user for a file name.. which is then set as an input file and then read. But when the file with the name $file_name doesn't exists, it shows error saying
illegal file character
How do i check if fh is not null (I don't think there is a concept of NULL in tcl being "everyting is a string" language!), so that if an invalid file_name is given, i can throw a print saying file doesn't exists!
Short answer:
try {
open $file_name
} on ok f {
# do stuff with the open channel using the handle $f
} on error {} {
error {file doesn't exist!}
}
This solution attempts to open the file inside an exception handler. If open is successful, the handler runs the code you give it inside the on ok clause. If open failed, the handler deals with that error by raising a new error with the message you wanted (note that open might actually fail for other reasons as well).
The try command is Tcl 8.6+, for Tcl 8.5 or earlier see the long answer.
Long answer:
Opening a file can fail for several reasons, including missing files or insufficient privileges. Some languages lets the file opening function return a special value indicating failure. Others, including Tcl, signal failure by not letting open return at all but instead raise an exception. In the simplest case, this means that a script can be written without caring about this eventuality:
set f [open nosuchf.ile]
# do stuff with the open channel using the handle $f
# run other code
This script will simply terminate with an error message while executing the open command.
The script doesn't have to terminate because of this. The exception can be intercepted and the code using the file handle be made to execute only if the open command was successful:
if {![catch {open nosuchf.ile} f]} {
# do stuff with the open channel using the handle $f
}
# run other code
(The catch command is a less sophisticated exception handler used in Tcl 8.5 and earlier.)
This script will not terminate prematurely even if open fails, but it will not attempt to use $f either in that case. The "other code" will be run no matter what.
If one wants the "other code" to be aware of whether the open operation failed or succeeded, this construct can be used:
if {![catch {open nosuchf.ile} f]} {
# do stuff with the open channel using the handle $f
# run other code in the knowledge that open succeeded
} else {
# run other code in the knowledge that open failed
}
# run code that doesn't care whether open succeeded or failed
or the state of the variable f can be examined:
catch {open nosuchf.ile} f
if {$f in [file channels $f]} {
# do stuff with the open channel using the handle $f
# run other code in the knowledge that open succeeded
} else {
# run other code in the knowledge that open failed
}
# run code that doesn't care whether open succeeded or failed
(The in operator is in Tcl 8.5+; if you have an earlier version you will need to write the test in another manner. You shouldn't be using earlier versions anyway, since they're not supported.)
This code checks if the value of f is one of the open channels that the interpreter knows about (if it isn't, the value is probably an error message). This is not an elegant solution.
Ensuring the channel is closed
This isn't really related to the question, but a good practice.
try {
open nosuchf.ile
} on ok f {
# do stuff with the open channel using the handle $f
# run other code in the knowledge that open succeeded
} on error {} {
# run other code in the knowledge that open failed
} finally {
catch {chan close $f}
}
# run code that doesn't care whether open succeeded or failed
(The chan command was added in Tcl 8.5 to group several channel-related commands as subcommands. If you're using earlier versions of Tcl, you can just call close without the chan but you will have to roll your own replacement for try ... finally.)
The finally clause ensures that whether or not the file was opened or any error occurred during the execution of the on ok or on error clauses, the channel is guaranteed to be non-existent (destroyed or never created) when we leave the try construct (the variable f will remain with an unusable value, unless we unset it. Since we don't know for sure if it exists, we need to prevent the unset operation from raising errors by using catch {unset f} or unset -nocomplain f. I usually don't bother: if I use the name f again I just set it to a fresh value.).
Documentation: catch, chan, close, error, in operator, file, if, open, set, try, unset
Old answer:
(This answer has its heart in the right place but I'm not satified with it these months later. Since it was accepted and even marked as useful by three people I am loath to delete it, but the answer above is IMHO better.)
If you attempt to open a non-existing file and assign the channel identifier to a variable, an error is raised and the contents of the variable are unchanged. If the variable didn't exist, it won't be created by the set command. So while there is no null value, you can either 1) set the variable to a value you know isn't a channel identifier before opening the file:
set fh {} ;# no channel identifier is the empty string
set fh [open foo.bar]
if {$fh eq {}} {
puts "Nope, file wasn't opened."
}
or 2) unset the variable and test it for existence afterwards (use catch to handle the error that is raised if the variable didn't exist):
catch {unset fh}
set fh [open foo.bar]
if {![info exists fh]} {
puts "Nope, file wasn't opened."
}
If you want to test if a file exists, the easiest way is to use the file exists command:
file exists $file_name
if {![file exists $file_name]} {
puts "No such file"
}
Documentation: catch, file, if, open, puts, set, unset
Is there a convenient way to specify in a Tcl script to immediately exit in case any error happens? Anything similar to set -e in bash?
EDIT I'm using a software that implements Tcl as its scripting language. If for example I run the package parseSomeFile fname, if the file fname does't exist, it reports it but the script execution continues. Is there a way that I stop the script there?
It's usually not needed; a command fails by throwing an error which makes the script exit with an informative message if not caught (well, depending on the host program: that's tclsh's behavior). Still, if you need to really exit immediately, you can hurry things along by putting a trace on the global variable that collects error traces:
trace add variable ::errorInfo write {puts stderr $::errorInfo;exit 1;list}
(The list at the end just traps the trace arguments so that they get ignored.)
Doing this is not recommended. Existing Tcl code, including all packages you might be using, assumes that it can catch errors and do something to handle them.
In Tcl, if you run into an error, the script will exit immediately unless you catch it. That means you don't need to specify the like of set -e.
Update
Ideally, parseSomeFile should have return an error, but looks like it does not. If you have control over it, fix it to return an error:
proc parseSomeFile {filename} {
if {![file exists $filename]} {
return -code error "ERROR: $filename does not exists"
}
# Do the parsing
return 1
}
# Demo 1: parse existing file
parseSomeFile foo
# Demo 2: parse non-existing file
parseSomeFile bar
The second option is to check for file existence before calling parseSomeFile.
In this NT cmd shell\"batch file" I scrabbled together the other day, I'm using the call command to run sections of the script like functions--as I have done many times before in other scripts. But one of this is behaving strange and I can't figure out what might be wrong...
The problem is that the first time the function is called it properly returns the errorcode and sets the (global) variable %RESULT%, but every time it's called again later it fails to update the variable with the new errorcode.
Here's a stripped-down version of the code in question:
:FACL
REM run fileacl.exe with given OPTIONS (%1)
REM uses global variables %TARGET% and %LOGPATH%, sets global %RESULT%
setlocal
set _OPTIONS_=%*
fileacl.exe "%TARGET%" %_OPTIONS_% /SILENT >%LOGPATH%\temp.out 2>%LOGPATH%\temp.err
set _RESULT_=%ERRORLEVEL%
if defined DEBUG echo INSIDE FUNCTION: _RESULT_ = %_RESULT_%
endlocal & set RESULT=%_RESULT_% & goto :EOF
The function is called in lines like this:
call :FACL /LINE
if defined DEBUG echo AFTER TEST #1: RESULT = %RESULT%
...
call :FACL /INHERIT /REPLACE /FORCE
if defined DEBUG echo AFTER FIX #2: RESULT = %RESULT%
You see those if defined DEBUG... lines there? They show me that inside the function, subsequent calls are succeeding and thus printing out the expected %_RESULT_% of 0, but the global %RESULT% remains the same. Here's some example output:
TEST #1:
INSIDE FUNCTION: _RESULT_ = 107 <-- that's what I expect for the first call
AFTER TEST #1: RESULT = 107 <-- the variable was properly set after the first call
FIX #2:
INSIDE FUNCTION: _RESULT_ = 0 <-- command succeeded :)
AFTER FIX #2: RESULT = 107 <-- variable didn't change :(
RETEST:
INSIDE FUNCTION: _RESULT_ = 0 <-- succeeded again
AFTER RETEST: RESULT = 107 <-- still didn't change
You may ask: what else have you tried? Okay:
Removed the setlocal\endlocal tricks and just used the global %RESULT% variable
Explicitly undefined %RESULT% and %_RESULT_% (e.g. set RESULT=) before each time the function is called
...all with the same results. Is there something I'm missing here?
Can't be sure, because we can't see the actual code in context. But the behavior you are describing is to be expected if the FIX 2 CALL and ECHO are within a parenthesized block - perhaps as part of an IF statement or FOR loop.
If that is the case, then you need to use delayed expansion within the parentheses since the entire block is parsed prior to execution and the %RESULT% is expanded at parse time.
Use SET EnableDelayedExpansion to enable delayed expansion, and use !RESULT! instead of %RESULT% to get the value of RESULT at execution time instead of at parse time.