On Friday, January 9, 2015 at 11:24:24 PM UTC, Christoph Junghans wrote:
> 2015-01-09 15:38 GMT-07:00 abrukhno <[email protected]>:
> >> >> I guess
> >> >> exec 3>&1 4>&2 >> "$CSGLOG" 2>/dev/null
> >> >> will do what you want.
> >> >>
> >> >> We could add an option like cg.inverse.error_log_file and use
> >> >> exec 3>&1 4>&2 >> "$CSGLOG" 2> "$CSG_ERRORLOG"
> >> >
> >> > - that might be useful, but maybe you don't put quotes around
> >> > $CSG_ERRORLOG ?
> >
> > - For the time being I've simply overridden inverse.sh within my_scripts
> > directory, replacing the call to enable_logging() with its body altered as
> > follows (since I cannot override functions_common.sh this way):
> > ===
> > ...
> > export CSGLOG="$log"
> > if [[ -f $CSGLOG ]]; then
> > exec 3>&1 4>&2 >> "$CSGLOG" 2>&1
> > echo "\n\n#################################"
> > echo "# Appending to existing logfile #"
> > echo "#################################\n\n"
> > msg --color blue "Appending to existing logfile ${CSGLOG##*/}"
> > else
> > exec 3>&1 4>&2 >> "$CSGLOG" 2>/dev/null
> > echo "\n\n#################################"
> > echo "# Creating new logfile & dumping errors #"
> > echo "#################################\n\n"
> > msg "For a more verbose log see: ${CSGLOG##*/}"
> > fi
> > ===
> > Works fine, where I can chose to dump errors or not, by either having or
> > not pre-existing inverse.log (so that if I've got an error, next time this
> > will show up in the appended inverse.log)
> We had overwriting of function_common.sh at some point, but it was too
> error-prone as the user would have to re-incorporate our changes all
> the time.
- never mind, I have it working the way I like by now :)
> >
> > BTW, why do you need "\n\n" in echo strings? - they show up "as is", i.e.
> > no extra lines around the message (if that was the purpose).
> Should be "echo -e", now fixed in the code.
>
> >
> >> > otherwise, can it create a file named "/dev/null" instead of dumping the
> >> > output into the null device? I've tried "inverse.log 2>inverse.err" for
> >> > $CSGLOG (via tag cg.inverse.log_file in settings.xml) and got the file
> >> > named "inverse.log 2>inverse.err" (without quotes)
> >> The quotes are to support spaces in the file names. And your trick
> >> won't work in bash anyhow:
> >> $ xxx="1 2> 2"
> >> $ echo hallo > $xxx
> >> -bash: $xxx: ambiguous redirect
> >
> > - what you say, I won't be able to set $CSG_ERRORLOG to "/dev/null" anyway,
> > but could only split the log into stdout and stderr outputs? not sure if
> > this would be that useful (if only to ease viewing inverse.log without the
> > tools' progress reports)
> What I was saying is that setting cg.inverse.log_file to something
> line "file1 2> file2" will never work.
- ok, but what the beginning of enable_logging() does then? (see next below)
> >
> > Perhaps, my last question/suggestion here: isn't the starting bit of
> > enable_logging() supposed to invoke "2>/dev/null" after the name provided
> > in cg.inverse.log_file tag (maybe when it wasn't found?)? - it doesn't
> > though.
> > ===
> > local log
> > if [[ -z $1 ]]; then
> > log="$(csg_get_property cg.inverse.log_file 2>/dev/null)"
> > else
> > log="$1"
> > fi
> > ===
> > Anyways one could get around the errors logging by doing "2>/dev/null" only
> > in the case when cg.inverse.log_file is not found in settings.xml (or has a
> > specific name, like inverse_no_stderr.log), and "2>&1" otherwise.
> No, that should like too much magic to me.
- in fact, I prefer it the way I did by overriding.
> As said previously, we could add something like
> cg.inverse.error_log_file, however I think your case is pretty
> special.
> Can you do a benchmark, how much faster using /dev/null actually is?
- let me see some finished iterations done with different outputs,
but even if on clusters buffering takes care of the overheads, I often tune the
settings/options by running preliminary iterations on my PC or laptop, where
there buffering is only modest.
Besides, as I said before, getting and browsing a log of some hundreds Mb of
"reading frame" progress reports, is not a good style anyway.
> Beside the fact I don't like the idea of throwing all error messages away.
- no problem, I can get the errors by re-running for them the second time.
It would be actually cumbersome to edit settings.xml every time to switch
between the two modes (+/-errors)
Cheers & Happy New Year btw! :)
>
> Christoph
> >
> > Andrey
> >
> >> >
> >> > - out of curiosity, do you ever actually use descriptors 3 and/or 4, or
> >> > is it there just in case for the future uses?
> >> This is use in the "msg" function:
> >> $ grep ">&[34]" functions_common.sh
> >> echo -e "${color}$*${off}" >&4
> >> echo -e "${color}$*${off}" >&3
> >> Their use is that inside the script the redirect to log file is
> >> automatic and not every command needs to redirect with
> >> "&>" separately.
> >>
> >> Christoph
> >>
> >> >
> >> > Thanks
> >> >
> >> >> >
> >> >> > Andrey
> >> >> >
> >> >> >> Christoph
> >> >> >>
> >> >> >> >
> >> >> >> > Thanks
> >> >> >> >
> >> >> >> > Andrey
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > --
> >> >> >> > You received this message because you are subscribed to the Google
> >> >> >> > Groups "votca" group.
> >> >> >> > To unsubscribe from this group and stop receiving emails from it,
> >> >> >> > send an email to [email protected].
> >> >> >> > To post to this group, send email to [email protected].
> >> >> >> > Visit this group at http://groups.google.com/group/votca.
> >> >> >> > For more options, visit https://groups.google.com/d/optout.
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Christoph Junghans
> >> >> >> Web: http://www.compphys.de
> >> >> >
> >> >> > --
> >> >> > You received this message because you are subscribed to the Google
> >> >> > Groups "votca" group.
> >> >> > To unsubscribe from this group and stop receiving emails from it,
> >> >> > send an email to [email protected].
> >> >> > To post to this group, send email to [email protected].
> >> >> > Visit this group at http://groups.google.com/group/votca.
> >> >> > For more options, visit https://groups.google.com/d/optout.
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Christoph Junghans
> >> >> Web: http://www.compphys.de
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> > Groups "votca" group.
> >> > To unsubscribe from this group and stop receiving emails from it, send
> >> > an email to [email protected].
> >> > To post to this group, send email to [email protected].
> >> > Visit this group at http://groups.google.com/group/votca.
> >> > For more options, visit https://groups.google.com/d/optout.
> >>
> >>
> >>
> >> --
> >> Christoph Junghans
> >> Web: http://www.compphys.de
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "votca" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to [email protected].
> > To post to this group, send email to [email protected].
> > Visit this group at http://groups.google.com/group/votca.
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Christoph Junghans
> Web: http://www.compphys.de
--
You received this message because you are subscribed to the Google Groups
"votca" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/votca.
For more options, visit https://groups.google.com/d/optout.
