bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "return" should not continue script execution, even if used inapprop


From: don fong
Subject: Re: "return" should not continue script execution, even if used inappropriately
Date: Sun, 20 Jan 2019 17:43:04 -0800

>
> Then use the "  sh -c '. script'  " version instead.
>

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.  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.

On Thu, Jan 10, 2019 at 2:53 PM Robert Elz <address@hidden> wrote:

>     Date:        Tue, 8 Jan 2019 23:40:40 -0800
>     From:        don fong <address@hidden>
>     Message-ID:  <
> address@hidden>
>
>
>   | to me, your suggested wrapper script pattern seems unnatural.  i don't
>   | always want users to have to carry around 2 files (the dottable
> library and
>   | the wrapper to dot it in).
>
> Then use the "  sh -c '. script'  " version instead.
>
>   | speaking of breakage, i'd also note that your suggested pattern has a
> bug,
>   | it assumes that run-dotscr will only be run from the directory where
> the
>   | file lives.  yes, the bug can be easily fixed.  but fixing it will make
>   | your script a bit less "simple and natural".
>
> Not really a bug, simply a simpliciation for the purposes of this e-mail
> exchange ... obviously you're expected to be smart enough to use the
> actual form that is needed to work in the environment in which the
> script is to be tested - whether that means using a full path name, or
> a PATH search, or whatever is appropriate for the situation (that is, the
> "./dotscr" part of the example should be the same thing you'd expect the
> user to type if they were to run it as an independent script.
>
> The purpose of the example was to illustrate the echnique, not to provide
> a ready made (complete) solution.
>
> kre
>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]