> > df...@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 <k...@munnari.oz.au> wrote: > Date: Mon, 7 Jan 2019 08:55:58 -0500 > From: Greg Wooledge <wool...@eeg.ccf.org> > Message-ID: <20190107135558.reqhfhr5vy3ih...@eeg.ccf.org> > > | https://mywiki.wooledge.org/BashFAQ/109 > > Which only works when the shell is bash... > > df...@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 > > > >
