Am 08.06.2012 um 00:27 schrieb Rayson Ho: > On Thu, Jun 7, 2012 at 6:15 PM, Reuti <[email protected]> wrote: >> But stdout is used internally by JSV already, you can't write to it without >> messing up the communication process. How does your JSV output it right now >> to stdout without messing it up? > > Well, it is more complicated than I wanted to explain in my previous email. > > My idea is/was not to change the JSV protocol (thus we are not > breaking anything), but redirect the stdout/stderr using pipes or > other methods...
Yes, I got this. But a simple "echo fubar" inside the JSV script will be forwarded to the parser already and the script breaks. One option could be to `echo` to file descriptor 3 or so and output all the collected lines after the JSV ran to stdout at that time. Personally I would like that "jsv_correct" outputs something. Or even something like "jsv_comment(mesage)", for now it must be send to the logfile instead. I see that this will change the JSV protocol. But it could be an RFE anyway. -- Reuti > > Rayson > > > >> >> >>> I haven't read the code yet >>> (real busy these days...), but it should be a small fix that we can >>> put in OGS/Grid Engine. >> >> Wouldn't it be better to adjust the JSV behavior for "jsv_correct" to output >> the specified string, instead of ignoring it? For "jsv_reject_wait" it's >> working to output the message. And for these -terse could just drop the >> specified message. >> >> -- Reuti >> >> >>> Rayson >>> >>> >>> >>> On Thu, May 31, 2012 at 12:30 PM, P. Golik <[email protected]> wrote: >>>> Sorry, let me try again. Normally, I would get the job id by calling >>>> something like >>>> >>>> $ id=$(echo echo 1 | qsub -l h_vmem=1g | cut -d " " -f3) && echo "id=$id" >>>> id=7222196 >>>> >>>> Now I add a JSV script that would print a warning or an error to the >>>> terminal >>>> >>>> $ id=$(echo echo 1 | qsub -l h_vmem=1g -jsv >>>> $SGE_ROOT/util/resources/jsv/jsv.sh | cut -d " " -f3) && echo "id=$id" >>>> Unable to run job: Job is rejected. It might be submitted later.. >>>> Exiting. >>>> id=hard >>>> >>>> The word ("hard") is the third word from JSV's error message "h_vmem as >>>> hard >>>> resource requirement has been deleted" that was printed to stdout. >>>> Anyway, if the job can be submitted, the warnings sent with >>>> jsv_log_warning() pollute the output on stdout. >>>> >>>> What I would like to have, is the following: >>>> >>>> $ id=$(echo echo 1 | qsub -l h_vmem=1g -jsv >>>> $SGE_ROOT/util/resources/jsv/jsv.sh | cut -d " " -f3) && echo "id=$id" >>>> WARNING: something went wrong, but JSV fixed it (this is written to stderr) >>>> id=7222196 >>>> >>>> But instead I get >>>> id=went >>>> >>>> Is there a way to send a warning to user's stderr from jsv.sh? >>>> >>>> I hope that was clearer. >>>> >>>> On Thu, May 31, 2012 at 5:50 PM, Rayson Ho <[email protected]> >>>> wrote: >>>>> >>>>> Can you give us the instructions to reproduce the problem?? (Simple, >>>>> step by step instructions would be ideal.) >>>>> >>>>> I got a JSV-related issue reported to me this morning, and if I can >>>>> easily reproduce the problem you've encountered, then I can look at >>>>> both of the JSV problems when I have time. >>>>> >>>>> Rayson >>>>> >>>>> >>>>> >>>>> On Thu, May 31, 2012 at 11:28 AM, P. Golik <[email protected]> wrote: >>>>>> Hi! >>>>>> >>>>>> I'm running a global JSV shell script for controlling user defined >>>>>> parameters. >>>>>> >>>>>> By default, JSV prints the output of jsv_log_{warning,info,...} to >>>>>> stdout. >>>>>> Unfortunately, we have to use some wrapper script that parses the output >>>>>> of >>>>>> qsub in order to get the job id. On the other hand, stderr seems to be >>>>>> used >>>>>> by JSV for communication. >>>>>> Is there an alternative way to print some warning to user's terminal >>>>>> without >>>>>> breaking the communication with JSV and without modifying stdout? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> _______________________________________________ >>>>>> users mailing list >>>>>> [email protected] >>>>>> https://gridengine.org/mailman/listinfo/users >>>>>> >>>> >>>> >>> >>> _______________________________________________ >>> users mailing list >>> [email protected] >>> https://gridengine.org/mailman/listinfo/users >>> >> >> >> _______________________________________________ >> users mailing list >> [email protected] >> https://gridengine.org/mailman/listinfo/users _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
