Groups > linux.debian.user > #166774 > unrolled thread

My script almost works but spams the terminal its launched from if useing dash.

Started by	Gene Heskett <gheskett@shentel.net>
First post	2016-04-16 17:30 +0200
Last post	2016-04-17 16:40 +0200
Articles	12 on this page of 32 — 10 participants

Back to article view | Back to linux.debian.user

Page 2 of 2 — ← Prev page 1 [2]

#166781

From	Gene Heskett <gheskett@shentel.net>
Date	2016-04-16 19:10 +0200
Message-ID	<roBTk-72V-17@gated-at.bofh.it>
In reply to	#166779

On Saturday 16 April 2016 12:44:55 Sven Joachim wrote:
>
> https://wiki.ubuntu.com/DashAsBinSh has some information how to make
> scripts portable.  The checkbashisms command in the devscripts package
> can help you detect common non-portable constructions in your scripts.
>
> Cheers,
>        Sven

A bookmarked now, much better explanatory link, thank you Sven.

I think for my stuff, I should export the value of /bin/sh, write a 
wrapper script to determine what /bin/sh is, and run the correct script 
to get the identical wanted functionality based on the value of the 
export.  There are too many places where a conditional would be needed 
so it would use command A or command B, and thats going to slow it down 
much more than just re-writing it into 2 scripts and running the correct 
one w/o all that gingerbread & bloat.

I have at least 3 background helper scripts, all of which would need to 
be fixed for the diffs.

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.

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>

[toc] | [prev] | [next] | [standalone]

#166783 — Re: My script almost works but spams the terminal its launched from if useing dash.

From	Linux-Fan <Ma_Sys.ma@web.de>
Date	2016-04-16 19:30 +0200
Subject	Re: My script almost works but spams the terminal its launched from if useing dash.
Message-ID	<roCcG-7aM-11@gated-at.bofh.it>
In reply to	#166781

[Multipart message — attachments visible in raw view] — view raw

[Sat, 16 Apr 2016 13:07:38 -0400] Gene Heskett <gheskett@shentel.net>
wrote:
> On Saturday 16 April 2016 12:44:55 Sven Joachim wrote:
> >
> > https://wiki.ubuntu.com/DashAsBinSh has some information how to make
> > scripts portable.  The checkbashisms command in the devscripts
> > package can help you detect common non-portable constructions in
> > your scripts.
> >
> > Cheers,
> >        Sven
> 
> A bookmarked now, much better explanatory link, thank you Sven.

In addition, I recommend consulting the standard whenever doubt arises:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html

... because there is a lot of outdated information on what is POSIX and
what is not. Fortunately, The Ubuntu Wiki link given above seems to be
OK.

> I think for my stuff, I should export the value of /bin/sh, write a 
> wrapper script to determine what /bin/sh is, and run the correct
> script to get the identical wanted functionality based on the value
> of the export.  There are too many places where a conditional would
> be needed so it would use command A or command B, and thats going to
> slow it down much more than just re-writing it into 2 scripts and
> running the correct one w/o all that gingerbread & bloat.

[...]

As far as I understand, just about all scripts which work under dash
also work under bash without changes. If your script is compatible
with dash, it does not need to check if it is running under bash,
because that will ``just work''. This means: If you do the work to port
the scripts to dash, you will likely not have to maintain a separate
version for bash.

HTH
Linux-Fan

-- 
http://masysma.lima-city.de/

[toc] | [prev] | [next] | [standalone]

#166786

From	"Thomas Schmitt" <scdbackup@gmx.net>
Date	2016-04-16 20:10 +0200
Message-ID	<roCPn-7M4-1@gated-at.bofh.it>
In reply to	#166781

Hi,

Gene Heskett wrote:
>         if [[ ${InMail} = 'gene' ]]

test(1) is supposed to be portable

          if test "${InMail}" = 'gene'

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

See also
  https://www.gnu.org/software/autoconf/manual/autoconf-2.64/html_node/Portable-Shell.html

Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#166803

From	Gene Heskett <gheskett@shentel.net>
Date	2016-04-17 01:10 +0200
Message-ID	<roHvI-2PY-25@gated-at.bofh.it>
In reply to	#166786

On Saturday 16 April 2016 14:02:16 Thomas Schmitt wrote:

> Hi,
>
> Gene Heskett wrote:
> >         if [[ ${InMail} = 'gene' ]]
>
> test(1) is supposed to be portable
>
>           if test "${InMail}" = 'gene'
>
Thats slightly different, printed for tomorrows experiments.  Thank you.
I need to reboot to bring in a fresh kernel that was updated earlier 
today.  But I'm out of giddy-up, haveing repaired a dishwasher MCU based 
control module today in my own dishwasher. The parts houses for such 
wanted 266.55 USD for one that may, or may not have had the same 
software.  But I found 3 of the teeny electrolytics in it, 10 u-f at 16 
volts, were reading at about .02 u-f, so now there are a triplet of 10 
u-f x 16 volt tantalum caps in it.  I don't enjoy working on a pcb that 
has no schematic, not even online, but then I am also a C.E.T. 
(Certified Electronics Technician), but will plead to quit a bit of rust 
in the wet ram (its 81 yo now) in the 44 years since I sat down cold 
without cracking a book, to take that test back in '72.

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

> See also
>  
> https://www.gnu.org/software/autoconf/manual/autoconf-2.64/html_node/P
>ortable-Shell.html
>
>
> Have a nice day :)
>
> Thomas

You too Thomas and thank you.

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>

[toc] | [prev] | [next] | [standalone]

#166809 — Re: My script almost works but spams the terminal its launched from if useing dash.

From	David Wright <deblis@lionunicorn.co.uk>
Date	2016-04-17 04:30 +0200
Subject	Re: My script almost works but spams the terminal its launched from if useing dash.
Message-ID	<roKDf-5iP-9@gated-at.bofh.it>
In reply to	#166803

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

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.

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.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#166811

From	Gene Heskett <gheskett@shentel.net>
Date	2016-04-17 06:50 +0200
Message-ID	<roMOJ-6YE-1@gated-at.bofh.it>
In reply to	#166809

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>

[toc] | [prev] | [next] | [standalone]

#166867 — Re: My script almost works but spams the terminal its launched from if useing dash.

From	David Wright <deblis@lionunicorn.co.uk>
Date	2016-04-18 16:00 +0200
Subject	Re: My script almost works but spams the terminal its launched from if useing dash.
Message-ID	<rphSy-6yD-9@gated-at.bofh.it>
In reply to	#166811

On Sun 17 Apr 2016 at 00:41:03 (-0400), Gene Heskett wrote:
> 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.

Which nicely illustrates the point of defensive programming.
It's not *your* script that will necessarily make the first mistake,
but you don't want procmail's unexpected input to derail your script
and produce a cascade of errors. Let's face it, shell error messages
are not the easiest to decode: that was the reason for your OP.

And pointing out how your procmail system can't get it wrong is no
defence. If you're using an unsafe test in one place, it's likely
there are other ones in your scripts (assuming this isn't the only
script you have).

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#166875

From	Gene Heskett <gheskett@shentel.net>
Date	2016-04-18 20:50 +0200
Message-ID	<rpmpc-1Hn-3@gated-at.bofh.it>
In reply to	#166867

On Monday 18 April 2016 09:49:29 David Wright wrote:

> On Sun 17 Apr 2016 at 00:41:03 (-0400), Gene Heskett wrote:
> > 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.
>
> Which nicely illustrates the point of defensive programming.
> It's not *your* script that will necessarily make the first mistake,
> but you don't want procmail's unexpected input to derail your script
> and produce a cascade of errors. Let's face it, shell error messages
> are not the easiest to decode: that was the reason for your OP.
>
> And pointing out how your procmail system can't get it wrong is no
> defence. If you're using an unsafe test in one place, it's likely
> there are other ones in your scripts (assuming this isn't the only
> script you have).
>
> Cheers,
> David.

Observant, David.  Its not the only one but the others are cron jobs, and 
re-arranging the 2>&1 to be the last argument has truly shut this one 
up. 18+ hours and a hundred or more incoming emails later, and I am 
still looking at the shell prompt in the window I restarted it in.  Life 
is good, its truly backgrounded for good.

Thank you.

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>

[toc] | [prev] | [next] | [standalone]

#166825

From	"Thomas Schmitt" <scdbackup@gmx.net>
Date	2016-04-17 14:10 +0200
Message-ID	<roTGy-3YX-15@gated-at.bofh.it>
In reply to	#166803

Hi,

Gene Heskett wrote:
> In normal everyday operation, the variable ${InMail} will not be empty.

Well, normally the 10 uF capacitors suffice for the projected
life time of the dishwasher. :))


The bashism "[[ ${InMail} = 'gene' ]]" hides the pitfall that whitespace
in a variable will normally yield more than word. (That's quite unexpected
from the general view of shell programming, but documented in man bash.)

With conservative shell gestures one should enclose variable evaluation
in " quotation marks in order to get the content as exactly one word:

  $ InMail="a b"
  $ if [[ ${InMail} = 'gene' ]] ; then echo yes ; else echo no ; fi
  no
  $ if test ${InMail} = 'gene'; then echo yes ; else echo no ; fi
  bash: test: too many arguments
  no
  $ if test "${InMail}" = 'gene'; then echo yes ; else echo no ; fi
  no

With empty text and no "-marks you get the contrary complaint about
0 words as evaluation result:

  $ InMail=""
  $ if test ${InMail} = 'gene'; then echo yes ; else echo no ; fi
  bash: test: =: unary operator expected
  no


Google "portable shell" tells me that the gesture

  test "x$variable" = xconstant

does not really target empty variable content but rather reserved
words as variable content.
The command test(1) (bash builtin or /usr/bin/test) seems to be quite
tolerant with syntax errors caused by reserved words where operants
are expected.
I fail to make it complain about content like
  $ InMail="("
  $ InMail="-f"
if i use proper "-marks.  


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#166826

From	"Thomas Schmitt" <scdbackup@gmx.net>
Date	2016-04-17 14:10 +0200
Message-ID	<roTGy-3YX-25@gated-at.bofh.it>
In reply to	#166803

Hi,

[Second try to send this mail. Looks like lists.debian.org had a
 few minutes of inconsciousness. No reply on ping or https.]

Gene Heskett wrote:
> In normal everyday operation, the variable ${InMail} will not be empty.

Well, normally the 10 uF capacitors suffice for the projected
life time of the dishwasher. :))


The bashism "[[ ${InMail} = 'gene' ]]" hides the pitfall that whitespace
in a variable will normally yield more than word. (That's quite unexpected
from the general view of shell programming, but documented in man bash.)

With conservative shell gestures one should enclose variable evaluation
in " quotation marks in order to get the content as exactly one word:

  $ InMail="a b"
  $ if [[ ${InMail} = 'gene' ]] ; then echo yes ; else echo no ; fi
  no
  $ if test ${InMail} = 'gene'; then echo yes ; else echo no ; fi
  bash: test: too many arguments
  no
  $ if test "${InMail}" = 'gene'; then echo yes ; else echo no ; fi
  no

With empty text and no "-marks you get the contrary complaint about
0 words as evaluation result:

  $ InMail=""
  $ if test ${InMail} = 'gene'; then echo yes ; else echo no ; fi
  bash: test: =: unary operator expected
  no


Google "portable shell" tells me that the gesture

  test "x$variable" = xconstant

does not really target empty variable content but rather reserved
words as variable content.
The command test(1) (bash builtin or /usr/bin/test) seems to be quite
tolerant with syntax errors caused by reserved words where operants
are expected.
I fail to make it complain about content like
  $ InMail="("
  $ InMail="-f"
if i use proper "-marks.  


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#166830

From	Gene Heskett <gheskett@shentel.net>
Date	2016-04-17 15:20 +0200
Message-ID	<roUMi-4TN-7@gated-at.bofh.it>
In reply to	#166826

On Sunday 17 April 2016 08:06:13 Thomas Schmitt wrote:

> Hi,
>
> [Second try to send this mail. Looks like lists.debian.org had a
>  few minutes of inconsciousness. No reply on ping or https.]
>
> Gene Heskett wrote:
> > In normal everyday operation, the variable ${InMail} will not be
> > empty.
>
> Well, normally the 10 uF capacitors suffice for the projected
> life time of the dishwasher. :))
>
No.  The fact that it even ran 5 years amazes me.  The use of 16 volt 
electrolytic caps in a 5 volt circuit is an extreme miss-use of that 
type of capacitor because at 5 volts, they do not have enough voltage 
across the oxide film to keep it "formed" so the oxide slowly reverts as 
its in an oxygen free environment since the electrolyte is an extremely 
pure, called technical grade, ethylene glycol. The net result is that 
the 10 uf goes away, often in less than 5 years.  These were down to 
about what they would have been had they been even bigger paper caps, or 
in the .02uf to .03uf range.

The higher voltage stuff was fine although my meter overflows at 1000 uf 
and up. I need to buy my own ESR meter.

Possibly interesting story about the capacitor shortage back in the 70's 
when OPEC rationed the oil.  As the tx supervisor at KXNE-TV-19 for the 
Nebraska ETV folks at the time, it was coming toward the first frost of 
the fall, and I needed to convert the tx coolant to about 30% 
antifreeze.  That antifreeze cannot be contaminated with the usual 
automotive rust and corrosion inhibitors as they would make it 
conductive, whereas pure water, distilled or de-ionized is a great 
insulator. Since that conversion takes a 55 gallon drum of the pure 
stuff, I got on the horn and started trying to run a barrel of it down, 
calling all over the country till I finally found a barrel of technical 
grade, even purer stuff, sitting on the Mobil Oil dock 150 miles away in 
Omaha NE.  Pricy but I bought it, no choice.  That barrel had been 
earmarked for a JIT shipment to Cornel-Dubilair some weeks later.  My 
buying the last barrel in captivity caused much of that capacitor 
shortage.  And until we sorted the OPEC embargo, no petroleum could be 
spared to make any more of it.  It doesn't take much in each cap so that 
barrel was about a years supply for C-D.  Aerovox, Sangamo, Sprague, 
were all in the same boat.

> The bashism "[[ ${InMail} = 'gene' ]]" hides the pitfall that
> whitespace in a variable will normally yield more than word. (That's
> quite unexpected from the general view of shell programming, but
> documented in man bash.)
>
> With conservative shell gestures one should enclose variable
> evaluation in " quotation marks in order to get the content as exactly
> one word:
>
>   $ InMail="a b"
>   $ if [[ ${InMail} = 'gene' ]] ; then echo yes ; else echo no ; fi
>   no
>   $ if test ${InMail} = 'gene'; then echo yes ; else echo no ; fi
>   bash: test: too many arguments
>   no
>   $ if test "${InMail}" = 'gene'; then echo yes ; else echo no ; fi
>   no
>
> With empty text and no "-marks you get the contrary complaint about
> 0 words as evaluation result:
>
>   $ InMail=""
>   $ if test ${InMail} = 'gene'; then echo yes ; else echo no ; fi
>   bash: test: =: unary operator expected
>   no
>
>
> Google "portable shell" tells me that the gesture
>
>   test "x$variable" = xconstant
>
> does not really target empty variable content but rather reserved
> words as variable content.
> The command test(1) (bash builtin or /usr/bin/test) seems to be quite
> tolerant with syntax errors caused by reserved words where operants
> are expected.
> I fail to make it complain about content like
>   $ InMail="("
>   $ InMail="-f"
> if i use proper "-marks.
>
So I should change my single quotes to double-quotes.  And use test. And 
dump the doubled brackets.

Changes made, test run underway. Fetchmail says one incoming, 3 secs 
later kmail beeps.  I think its working. :)  The second possible name 
won't be tested unless a niece in NYS sends me an email, but amanda will 
test the third option in the early morning hours tomorrow.

And I learned a bit more, so the day will not be a total loss.
>
> Have a nice day :)
>
You too, Thomas.

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>

[toc] | [prev] | [next] | [standalone]

#166837

From	"Thomas Schmitt" <scdbackup@gmx.net>
Date	2016-04-17 16:40 +0200
Message-ID	<roW1I-5QE-9@gated-at.bofh.it>
In reply to	#166830

Hi,

Gene Heskett wrote:
> they do not have enough voltage 
> across the oxide film to keep it "formed" so the oxide slowly reverts as 
> its in an oxygen free environment

I always preferred math over chemistry.

> So I should change my single quotes to double-quotes.

Rather not. At least not as general advise. Beware.

The single '-quotes enclose constants (with special meaning of $'...',
in bash but not in dash).
Their use case is to keep whitespace or special characters from being
converted.
'gene' does not really need them, because it is only one word.
But 'Gene Heskett' or ';(|[$' would need them to be handled as a single
argument to some program run or to avoid shell parser complaints.

  $ echo ;(|[$
  bash: syntax error near unexpected token `|'
  $ echo ';(|[$'
  ;(|[$

In bash only:

  $ echo $'xyz\010abc'
  xyabc

(octal 010 = decimal 8 = ASCII BS backspace did eat the "z")

The double "-quotes should often be put around variable evaluations in
order to make the variable content a single argument to some program
run. These quotation marks protect whitespace and some special
characters. But they do not prevent variable evaluation and similar
text conversions.

man bash says:

  Enclosing  characters  in  double quotes preserves the literal value of
  all characters within the quotes, with the exception of $, `,  \,  and,
  when  history  expansion  is enabled, !.  The characters $ and ` retain
  their special meaning within double quotes.  The backslash retains  its
  special  meaning only when followed by one of the following characters:
  $, `, ", \, or <newline>.  A double quote may be quoted  within  double
  quotes by preceding it with a backslash.  If enabled, history expansion
  will be performed unless an !  appearing in double  quotes  is  escaped
  using a backslash.  The backslash preceding the !  is not removed.

One may put each variable into its own "-pair or one may mix constant
text and variable evaluation inside a one pair of "-quotes.

I use the for-loop to demonstrate content and number of perceived
program arguments. Any program or sub script will see the words
between "in" and the first ";" as the argument list which is printed
here by the for-loops.
The appended echo commands produce spacer lines for better readbility.

  $ for i in a b c ; do echo "$i" ; done ; echo
  a
  b
  c

  $ x='X  Y  Z'
  $ for i in a $x c ; do echo "$i" ; done ; echo
  a
  X
  Y
  Z
  c

  $ for i in a "$x" c ; do echo "$i" ; done ; echo
  a
  X  Y  Z
  c

  $ for i in "a $x c" ; do echo "$i" ; done ; echo
  a X  Y  Z b

  $ for i in "a${x}c" ; do echo "$i" ; done ; echo
  aX  Y  Zb

Single quotes and double quotes can protect each other from the
shell parser:

  $ echo '"'"$x"'"'
  "X  Y  Z"
  $ echo "'"'"'"$x"'"'"'"
  '"X  Y  Z"'

(It can become as inflationary as Lisp brackets ...)

Have a nice day :)

Thomas

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

csiph-web

My script almost works but spams the terminal its launched from if useing dash.

Contents

#166781

#166783 — Re: My script almost works but spams the terminal its launched from if useing dash.

#166786

#166803

#166809 — Re: My script almost works but spams the terminal its launched from if useing dash.

#166811

#166867 — Re: My script almost works but spams the terminal its launched from if useing dash.

#166875

#166825

#166826

#166830

#166837