Well I didn't see any part of that discussion that describes that. Also it's a C thing. Please don't disgrace.
-- konsolebox/m On Fri, Jan 25, 2019, 9:20 AM don fong <df...@dfong.com wrote: > 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 >>> >>> >>>
