[ProgClub programming] Announcing the base() shell function

Jedd Rashbrooke jedd.rashbrooke at gmail.com
Sun Jun 23 16:03:31 AEST 2019


 Slow day, eh John?


On Sun, 23 Jun 2019 at 11:58, John Elliot V | ProgClub <jj5 at progclub.org>
wrote:

> On 23/6/19 8:06 am, Jedd Rashbrooke wrote:
> > After you run 'base' what's the very next thing(s) you do?
>
> Run something in bin, e.g.
>
>  jj5 at tact:~/repo/svn/my-repo/my-project/src/web/res$ base
>  jj5 at tact:~/repo/svn/my-repo/my-project$ bin/my-process.sh
>
> Also commit to source control.
>

 Okay, so with git you don't need to be in the root directory to commit, so
that might be a limitation of svn that I'm unfamiliar with.

 However the first bit is kind of interesting - if the (sole) goal of going
to the root directory is so you can run something from the checked out bin/
directory (and that does sound kind of dangerous, but I'm sure you know
your workflow) then having a way of temporarily add $(version control
root)/bin to the path could be handy, and certainly less trivial than 'svn
--show-item wc-root'


I think I will pick pillar.i.sysid.


 To be candid I really don't know what you're talking about here, but I'm
sure you'll be fine.


On Sun, 23 Jun 2019 at 13:27, John Elliot V | ProgClub <jj5 at progclub.org>
wrote:

> On 22/6/19 5:15 pm, Jedd Rashbrooke wrote:
> > Elegance is a consensus activity.
>
> It's really not.


 It was a tongue-in-cheek allusion to your earlier dismissal of your
spelling mistake as following the herd.

 I'm not sure elegance *is* entirely a consensus activity, but it's
probably more so than language definition.


> > You could ask a random selection of informed people whether they find a
> > 70 line bash function that may work in some situations is more or less
> > elegant than a one line alias that will work in every instance.
>
> lol. You don't think it's a little presumptuous of you to speak for all
> of the other people who might have an opinion?
>

 Lucky I didn't do that, then.  I would hate to appear presumptuous.

 I did suggest that if elegance was something you needed herd consensus to
measure, then asking a bunch of people would be a good way to determine if
your claim of 'more elegant' was widely shared.

 I strongly suspect it wouldn't be, but I'm not speaking on anyone else's
behalf.



> I expect results would vary based on which programming languages people
> knew, what kind of work they did, how much experience they had, and so
> forth.
>

 Absolutely.

 PHP neither encourages nor rewards consistency, so extrapolating
Sapir-Whorf, I can understand that things like pick-your-own-spelling, etc,
are an unfortunate product of the environment.


But there would certainly be plenty of people who appreciated a well
> documented, error checked, general solution to a bunch of cryptic,
> messy, limited, unmaintainable, error prone, poorly named, highly
> dependent, special cases that didn't even meet the specification's
> requirements ("because those requirements are stupid," obviously). The
> number of lines of code in the solution is perhaps one small
> consideration, not the alpha and the omega.
>

 Most developers agree that there's a strong correlation between LoC and
bugs - so as a surrogate, it's worthwhile to try to reduce the former.

 Are you suggesting two lines whose intent is self-evident ('show-toplevel'
and 'show wc-root') are a 'bunch of cryptic, yada yada'?

 We may have to agree to disagree on this one, as I really can't understand
your fixation with wrapping cruft around simple one-liners.

 In terms of documentation, I know that good developers I've worked with
over the past few decades would eschew constructs such as:

  # 2019-06-21 jj5 - if we've reached the file system root, we're done
  #
  if [ "$PWD" == '/' ]; then

     break;

  fi;

 Mostly because the comment distracts from the function.

 Comments are reserved to identify non-obvious intent, special cases,
purpose -- the Why, rather than the How (which should be apparent from the
code).

 I'd suggest even a non-developer would be able to work out what that the
purpose of that if construct is.

 Redundancies are just another place for code to diverge from inline
comments, to slow down the reader as they search for something non-obvious
and potentially dangerous that warranted explanation.

 Actually, a reader may wonder what 'done' here means - successfully
accomplished something, failed to do something, finished with the inner
loop, etc.  Presumably because the author has typed more characters
*describing* a simple conditional than the *actual* conditional and action,
it's got to be important.

 Anyway, I mention all this just so you can understand why I didn't write a
few lines of comments around:

 alias srslywtfdoesthisneeddocumentation="cd `git rev-parse
--show-toplevel`"

 Aside - bash doesn't require trailing ; on each line.


On Sun, 23 Jun 2019 at 13:46, John Elliot V | ProgClub <jj5 at progclub.org>
wrote:

> lol. I misinterpreted "top level" directory. I thought you meant "/" and
> were observing that I "cd .." before checking if I'm in "/" (which I
> also potentially do, thus my note about the Null Object Pattern).
>

 I did mean /

 I'm aware the world won't end if you 'cd ..' while in / ... but it does
seem like a dangerous assumption to make, and the sign of an inelegant
algorithm that you'd need two cd ..'s in such a very, very tiny function.

 Given it's a 'reference implementation', there aren't any bugs, just
surprising features.  And that's okay.



On Sun, 23 Jun 2019 at 13:32, John Elliot V | ProgClub <jj5 at progclub.org>
wrote:

> This is a good example of you picking something which doesn't matter and
> leveling accusations against me over it.
>

 John, basically absolutely nothing in this thread matters.

 You dreamed up a silly problem, wrote an excessively long-winded way of
dealing with it, failed to do a simple web search to see if solutions
already exist, and are now .. well, I don't what you're trying to do now.

 This kind of folly is why in March this year you said you'd provisioned a
Graylog server in 2018, but hadn't got to it yet - at the same time saying
you'd be reading up on Prometheus, Zabbix, etc.

 If you had *not* had a few instances since then where you'd found yourself
in need of centralised logs, or performance / capacity monitoring tooling,
it'd be more defensible to be spending days putzing around with bash
aliases to run 'cd' (and explaining why said putzing is totally worth it).



On Sun, 23 Jun 2019 at 14:15, John Elliot V | ProgClub <jj5 at progclub.org>
wrote:

> On 23/6/19 1:46 pm, John Elliot V | ProgClub wrote:
> > Why have multiple calls to base() leave you in a sub project, the base
> > of which you are already in?
>
> And if you scramble to adapt your initial special case solution to meet
>

 Trust me, I won't be scrambling.  As noted more than once I can't imagine
a single use case for this function, I just wanted to draw your attention
to the fact that better functionality was already available in your
existing tools.

 And as you showed before, 'svn' is *in the pathname* on the line that you
type the 'base' command, so you already know you're in an svn checkout.

 You already know the root directory of the checkout too, I expect, based
on the rest of that path.

 An alias for 'take me to the root of this svn repo' and another for 'take
me to the root of this git repo' would be more than fit for purpose.

 j.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.progclub.org/pipermail/programming/attachments/20190623/bf5cbde6/attachment-0001.html>


More information about the programming mailing list