Re: [AMBER-Developers] having tleap fail when input files are not found

From: Scott Brozell <sbrozell.rci.rutgers.edu>
Date: Wed, 29 Mar 2017 02:44:23 -0400

Hi,

Yes, that is in the works, but is a low priority until the release.

scott

On Tue, Mar 28, 2017 at 12:16:17PM -0400, Hai Nguyen wrote:
> may be we can add regression tests for this too?
>
> Hai
>
> On Mon, Mar 27, 2017 at 3:32 PM, Scott Brozell <sbrozell.rci.rutgers.edu>
> wrote:
>
> > Hi,
> >
> > I pushed the fix. Thanks for the report,
> > scott
> >
> > On Sun, Mar 26, 2017 at 08:56:48PM -0400, Hai Nguyen wrote:
> > > Hi Scott,
> > >
> > > is it good to test yet? I tried dummy command:
> > >
> > >
> > > MSE = loadmol2 MSE.mol2
> > >
> > > savepdb MSE MSE.pdb
> > >
> > > quit
> > >
> > >
> > > but still don't see expected behavior (stop when file not found?)
> > >
> > >
> > > output log
> > >
> > > ....
> > >
> > > Welcome to LEaP!
> > >
> > > (no leaprc in search path)
> > >
> > > Sourcing: ./test.in
> > >
> > > Could not open file MSE.mol2: not found
> > >
> > > savePdb: Argument #1 is type String must be of type: [unit]
> > >
> > > usage: savePdb <object> <filename>
> > >
> > > Quit
> > >
> > >
> > > Hai
> > >
> > >
> > >
> > > On Sun, Mar 26, 2017 at 6:48 PM, Scott Brozell <sbrozell.rci.rutgers.edu
> > >
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > On branch tleap-f-abortonerror, I have added the basic functionality.
> > > > I recommend that we merge this into the master after the release and
> > > > give it a thorough test drive before releasing it. (We do not know
> > > > how much we are relying on the old behavior).
> > > >
> > > > Presently, there is no control switch - it is always on. It might be
> > > > useful to have a command line flag such as -a and/or a command such
> > > > as abortOnError. And currently, the only error that can cause an
> > > > abort is failing to open a file.
> > > >
> > > > Here are some details:
> > > >
> > > > fBasicsMyFopen aborts on error when commands are sourced from a file.
> > > > Presently this applies to commands inside a sourced file, ie inside
> > bla for
> > > > -f bla, but it does not apply to the file itself, ie, if bla cannot be
> > > > opened
> > > > then there is no abort; nor does it apply to the default startup leaprc
> > > > file.
> > > >
> > > > The isatty approach does not work because leap is
> > > > always running interactively, ie, stdin is a tty even when files are
> > > > being sourced.
> > > >
> > > > scott
> > > >
> > > > On Tue, Feb 21, 2017 at 03:27:40AM -0500, Scott Brozell wrote:
> > > > > Ok, I'll investigate.
> > > > >
> > > > > On Mon, Feb 20, 2017 at 04:38:17PM -0500, Hai Nguyen wrote:
> > > > > > +1 for exiting right away if getting error since the final prmtop
> > is
> > > > NOT ok
> > > > > > to use.
> > > > > >
> > > > > > On Mon, Feb 20, 2017 at 4:32 PM, Justin MacCallum <
> > > > justin.maccallum.me.com>
> > > > > > >
> > > > > > > We routinely use tleap non-interactively, and this behaviour
> > bites us
> > > > > > > occasionally. It would be great if there was a mechanism to
> > specify
> > > > that
> > > > > > > tleap should die with a suitable error code whenever ti would
> > > > otherwise
> > > > > > > print an error when called interactively.
> > > > >
> > > > > On Mon, Feb 20, 2017 at 11:48:10AM -0500, David Case wrote:
> > > > > > This is a long-standing behavior for tleap:
> > > > > >
> > > > > > > MSE = loadmol2 MSE.mol2
> > > > > > Could not open file MSE.mol2: not found
> > > > > >
> > > > > > ...soldier on, continue with the next command.
> > > > > >
> > > > > > The above behavior is appropriate for interactive use, to give the
> > user
> > > > > > the chance to correct a typing mistake. But it mainly causes
> > confusion
> > > > > > for non-interactive use, since the error message that almost
> > > > invevitably
> > > > > > will come often hides the true source of the error.
> > > > > >
> > > > > > Could we not use isatty() to make "not found" a fatal error for
> > > > > > non-interactive use? Can some kind soul with spare time try to do
> > > > this?
> > > > > >
> > > > > > [I know that there are some workflows that rely on the current
> > > > behavior,
> > > > > > e.g. they load files that may not exist but also may not be needed.
> > > > > > How much should we worry about breaking such behavior? Do we need
> > a
> > > > > > command-line switch (or a new "global" variable) to control whether
> > > > > > "non-found" is fatal?]

_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Mar 29 2017 - 00:00:02 PDT
Custom Search