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

[don fong]

>
> dfong@dfong.com said:
>   | there's a good reason for the "craziness": it enables individual
> testing of
>   | the script's functions.
>
> For that kind of use there's a trivial solution (as there often
> is for cases when people are sure that the current definition
> is inadequate).
>

to be clear, i wasn't asking how to do it, i was only explaining why the
"python craziness" is not crazy at all.


> The one piece of advice from that python related BashFAQ that Greg
> referred to which is worth following is ...
>
Bash can do this, but it's not a natural style, and you shouldn't be doing
> it.


to convincingly argue that "you shouldn't be doing this" requires more than
a raw opinion backed by nothing but a completely subjective notion of
"naturalness".

i'd note that the cited page begins this premise:
"There seem to be *two reasons* why people ask this: either they're trying
to detect user errors and provide a friendly message, or they're Python
programmers who want to use one of Python's most idiosyncratic features in
bash."

but the premise misses a powerful third reason.  i'm not a "python
programmer wanting to use an idiosyncratic feature of python", i'm a
programmer who wants to write testable code.  this so-called "unnatural"
pattern from python makes the functions within a module testable without
needing to write a wrapper script.  this is a very practical and worthwhile
advantage.

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).  this is, again, a practical disadvantage.  it's
just one more thing to break.

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


On Mon, Jan 7, 2019 at 5:47 PM Robert Elz <kre@munnari.oz.au> wrote:

>     Date:        Mon, 7 Jan 2019 08:55:58 -0500
>     From:        Greg Wooledge <wooledg@eeg.ccf.org>
>     Message-ID:  <20190107135558.reqhfhr5vy3ih45g@eeg.ccf.org>
>
>   | https://mywiki.wooledge.org/BashFAQ/109
>
> Which only works when the shell is bash...
>
> dfong@dfong.com said:
>   | there's a good reason for the "craziness": it enables individual
> testing of
>   | the script's functions.
>
> For that kind of use there's a trivial solution (as there often
> is for cases when people are sure that the current definition
> is inadequate).
>
> If you have a script "dotscr" and you want to test it, then
> you do ...
>
>         cat <<-EOF >run-dotscr
>         . ./dotscr
>         EOF
>
> and then
>
>         sh run-dotscr           # or bash, or mksh, or ...
>
> You can probably abbreviate that as
>
>         sh -c '. ./dotscr'
>
> What's more, if dotscr is as most scripts designed to be used
> via the . command, and has no actual executable code (in the
> sense that it consumes no input and produces no output, so
> aside from checking for syntax errors, the above does nothing
> useful) you can add extra commands into the run-dotscr script;
> or as extra commands after a ';' in the -c case,  to actually call
> the functions dotscr defines, or the variables it creates, or
> whatever it does which needs testing.
>
> Or alternatively, interactively ...
>
>         sh      # start a new shell (any appropriate shell)
>         . ./dotscr
>         # do whatever testing you lile
>         exit
>
> Also, of course, it is also possible to write a script that can be
> executed either via the '.' command, or as a standalone script,
> if that is the desire - in fact many (perhaps most) scripts not
> expressly designed to only work as "dot scripts" are like that.
>
> The one piece of advice from that python related BashFAQ that
> Greg referred to which is worth following is ...
>
>         Bash can do this, but it's not a natural style,
>         and you shouldn't be doing it.
>
> kre
>
>
>
>