> > Encapsulate your code in a main function and deal with it. > yes, exactly. and that supposedly "crazy" python convention (its bash equivalent) is the best way i know of to "deal with it".
On Thu, Jan 24, 2019 at 4:08 PM konsolebox <konsole...@gmail.com> wrote: > Encapsulate your code in a main function and deal with it. > > -- konsolebox/m > > On Mon, Jan 21, 2019, 12:39 PM Robert Elz <k...@munnari.oz.au wrote: > >> Date: Sun, 20 Jan 2019 17:43:04 -0800 >> From: don fong <df...@dfong.com> >> Message-ID: < >> cahqakpxao-pbdr2e0tnhh_iouhlwdxq_fccbzo1gxrhpfv9...@mail.gmail.com> >> >> | i don't see how this helps. the point is to have one file of code >> that >> | behaves differently depending on whether it's dotted in or executed >> at the >> | top level. >> >> That's fine, if you are writing something to work like this, you >> just make sure that it will work when run either way. That means >> rthat you cannot do a "return" outside of a function in the script. >> >> This is easy to accomplish, the code just needs to be written >> to meet both sets of requirements (if you want to finish in a reliable >> way, you execute to EOF, and don't use either exit or return). >> >> | the script should do nothing but define stuff when dotted in; >> | but call the main function (or some other function) when run at the >> top >> | level. "sh -c '. script'" doesn't accomplish that. >> >> No, but it allows you to test a script that is not written to be able >> to be run either way, someone's script that is only intended to be >> executed as ". script" which you then want to test. In many cases >> you might need to add more than just the '.' command - depending >> on what is in the script (as I said way back in my first message on >> this subject). >> >> kre >> >> >>
