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
