[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: |
Tue, 8 Jan 2019 23:40:40 -0800 |
>
> 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
>
>
>
>
- "return" should not continue script execution, even if used inappropriately, Robert Hailey, 2019/01/05
- Re: "return" should not continue script execution, even if used inappropriately, Chet Ramey, 2019/01/06
- Re: "return" should not continue script execution, even if used inappropriately, Dennis Williamson, 2019/01/06
- Re: "return" should not continue script execution, even if used inappropriately, Robert Elz, 2019/01/07
- Re: "return" should not continue script execution, even if used inappropriately, Robert Elz, 2019/01/07
- Re: "return" should not continue script execution, even if used inappropriately, Greg Wooledge, 2019/01/07
- Re: "return" should not continue script execution, even if used inappropriately, Robert Elz, 2019/01/07
- Re: "return" should not continue script execution, even if used inappropriately,
don fong <=
- Re: "return" should not continue script execution, even if used inappropriately, Robert Elz, 2019/01/10
- Re: "return" should not continue script execution, even if used inappropriately, don fong, 2019/01/20
- Re: "return" should not continue script execution, even if used inappropriately, Greg Wooledge, 2019/01/21
- Re: "return" should not continue script execution, even if used inappropriately, Robert Elz, 2019/01/20
- Re: "return" should not continue script execution, even if used inappropriately, konsolebox, 2019/01/24
- Re: "return" should not continue script execution, even if used inappropriately, don fong, 2019/01/24
- Re: "return" should not continue script execution, even if used inappropriately, konsolebox, 2019/01/24
- Re: "return" should not continue script execution, even if used inappropriately, Robert Elz, 2019/01/24
- Re: "return" should not continue script execution, even if used inappropriately, don fong, 2019/01/25
- Re: "return" should not continue script execution, even if used inappropriately, Robert Elz, 2019/01/25