On Saturday 16 April 2016 22:18:34 David Wright wrote:
> On Sat 16 Apr 2016 at 19:06:42 (-0400), Gene Heskett wrote:
> > On Saturday 16 April 2016 14:02:16 Thomas Schmitt wrote:
> > > Gene Heskett wrote:
> > > > There are too many places where a conditional would be needed
> > >
> > > The classic way is to use only gestures which are supported by the
> > > Bourne shell and to avoid certain peculiarities of some shells.
> > > In ./configure scripts of source packages one can see gestures
> > > like
> > >
> > > if test "x${InMail}" = xgene
> > >
> > > which avoids to compare empty variable content.
> >
> > In normal everyday operation, the variable ${InMail} will not be
> > empty.
>
> That may or may not be a useful observation. However, sod's law
> dictates that when it *is* empty, it'll be in five years time when
> you've forgotten how and why you converted your script, and you
> desparately need it to work _now_.
Each new incoming email is another pass thru the loop. There are 3
possible names for the mailfile itself as procmail determines that.
This script launches an inotifywait instance with directions to return
the name of the modified by being written to mailfile. So unless I kill
it from a terminal, the inotifywait will define that name. If I kill it,
all 3 IF's fail, and a new instance of inotifywait is launched to
replace that one. Not that big a script, but it helps to make my email
handling fully automatic here. Pulling the mail is fetchmails job and
ity hands the incoming off to procmail, which filters it thru spamd,
clamav and thence to the correct mailfile in /var/spool/mail.
This script, by noticing the change in the mailfile, sends kmail a go get
mail from ${InMail} via dbus/dcop or whatever interprocess comm flavor
is in the distro, which gets it/them and sorts it to the correct
mailedir folder. No manual intervention by me other than running this
at bootup time.
All I have to do is tap the + key to read that email, and if I can
contribute to the thread, click the correct answering format and start
typing. When I am done, a ctrl+return sends it smtp style to the
selected mail server, defined on a per folder basis.
I suspect that if I kill the inotifywait, that ${InMail} actually remains
unchanged from the previous instance, and kmail likely gets sent to read
an empty mailfile in that event, a few milliseconds wasted but kmail
doesn't seem to mind. I did have some tracing echo's in there at one
time, but they don't last long as that spams the terminal it was
launched from.
> Going back a step or two:
>
> "This bash script has lived in ~/bin for years, but the mention of
> dash as a replacement for bash made me want to test it with dash by
> changing the bang line to #!/bin/sh, which is of course (this is
> wheezy) a softlink to /bin/dash."
>
> Debian took a decision long ago to make dash the default shell for
> *system* scripts. In that sense only, dash replaced bash, and the
> replacement took a while because all the bashisms had first to be
> removed from those scripts headed by #!/bin/sh. Water under the
> bridge now.
>
> Grepping /var/lib/dpkg/info/*.p* can be a quick way of finding
> examples of dash's ways and means. However, you're probably wasting
> your time converting your own scripts unless you need the efficiency.
Efficiency of the present method seems adequate so that would not drive
the change, but losing bash completely would upset the applecart long
before it got to the cider press.
>
> And this statement:
>
> "However, I'll go on record as opposing any motions to remove bash,
> the old man on the mountain of cli shells still gets the job done."
>
> is an unfounded fear. The default login shell is bash, as usual.
So it is not likely to go away before I do. At 81, I know my time is
limited. How much is probably up to a higher authority.
This discussion has been fruitfull and I thank you, David, as well as the
other respondents who tried to make sense out of my scribbling's.
> Cheers,
> David.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
