Re: Substring search in dash [ _NOT_ bash ] shell

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

i wrote:
> > if you cannot find a dash tutorial then get a tutorial for bash or sh and 
> > test in dash whether the proposals apply properly.

Greg Wooledge wrote:
> First, there are more bad tutorials out there in the wild than good
> tutorials, by at least one order of magnitude.

But the conclusion can hardly be "Use no tutorial and test in dash whether
the proposals apply properly".


> Second, trying to work backwards from a bash tutorial to a POSIX sh/dash
> programming style is going to be maddening.

It will keep the reader from acquiring bashisms.
(Of course a shell tutorial should always state what is portable to
 other shell variations and what is a peculiarity of the particular shell.
 But, well, orders of magnitude ...)


> Third, even dash has a few extensions to the POSIX shell syntax.

And it will hardly ever drop support for them.
The original request was explicitely for "dash" and not for POSIX shell.


> Kernighan & Pike's "The Unix Programming Environment".
> 
> for i in $@

Ouch. Indeed, Bourne shows similar reluctance to use quotation marks:

  for i in *
  do  if test -d $d/$i
  ...

Nevertheless the examples still work in descendants of Bourne's shell.
Not better than in the past, but not worse either.


> It is terrifying!  It's every single BAD shell practice all thrown together
> into a single example!

I feel with you.

Especially the "set" stunt is perverted and invites for due punishment
when the failure will hurt most.


> 40 years of this.

At least we proved that one can survive it.
For me it's only 31 years now. In the beginning it was a bit frightening.


> You are redirecting stdout, not stderr.

Yeah. As said. My fingers were in plaintext mode. No parser active.

I redirected stdout so that grep does not print its findings.
stderr is not redirected so that one has a chance to notice own errors.

Main reason for my post was to explain that "case"-"esac" does not
have the same one-liner syntax as "if"-"fi".
It seems Richard needs to state it as one-liner.


> Do not use -o and -a in a test command.
> http://mywiki.wooledge.org/BashPitfalls#pf6

As if anybody would dare to touch the old "test" command. :))

Rather i avoid "[" brackets, not to allow any implementor an excuse.
But in plaintext mode i wanted to stay near to the given original example.
It worked when i tested in dash and bash.


> The main problem with writing for sh is that nothing works the way
> you expect.

Whenever i am not sure how to state it in shell or whether shell does
it fast enough, i break out the C compiler. (Which still understands
the C examples in Bourne and Kernighan-Ritchie.)


> That is sh.

Awful indeed ... as long as you do not compare it to GUI-only systems.

Shell is good glue code. Not more. Not less.
Dialog leads to scripting smoothly.


Have a nice day :)

Thomas