Open azzaea opened 6 years ago
The last push checks that:
Hi- where is the fix for this? Thanks
I needed the workflow to kind of fail safely should the user erroneously specified the path to one of the executables. By safely, I mean that the error message should direct the user to which parameter in the runfile had a problem with path specification. Code is below:
// Modifying the pure swift/t function to accept strings as well (since for tcl everything is a string, this is straight forward) - I need to call this in my exec_check function to guarantee the 'fail-safe' aspect
@pure
(string t) file_type(string f)
"turbine" "0.0.2"
[ "set <<t>> [ file type [ lindex <<f>> 0 ] ]" ];
(boolean exec_ok) exec_check (string exec, string parameter){ // Checking function definition
file_exists(exec) => // This merely tests 'exec' is an entity in the file system, so not sufficient alone
assert(string_count(file_type(exec), "file", 0, -1) ==1, // If exec is not a file, exit and give warning
strcat("The executable: \n\t", exec,
"\n Referred to by the parameter: \n\t", parameter,
"is not properly specified in your runfile!"));
exec_ok = true;
}
Is there a better way to do/think about this?
It seems the pipeline is unable to tell when the executable of one of the programs being called (say bwa) is non-existing. These checks were already in place in the bash version of the pipeline, but we skipped this part while building the Swift/T equivalent.
The tricky part is that the error messages resulting from erroneous usage are silently dropped, without alarming the user of the problem. To be more specific, the error message does get printed, but in place of the expected output; and since nothing gets produced (i.e., no exit code from the app function), the pipeline simply hangs, and the user stays in the dark.
Practical example when bwa path is erroneously specified in the runfile: