[2018-07-16 21:45 +0200] markus schnalke <mei...@marmaro.de> > [2018-07-16 20:56] Vasilii Kolobkov <polezaivs...@ko5v.net> > > [2018-07-16 12:23 +0200] markus schnalke <mei...@marmaro.de> > > > Although $((...)) ist part of POSIX. I'd like to avoid it, if > > > possible. All uses of $((...)) in our test cases can be easily > > > converted to expr(1). Would that be okay for you or do do you have > > > strong opinions pro $((...))? > > > > I hold no special feeling about arithmetic expressions in sh(1) - > > they do get clunky fast, but i still prefer shell constructs to > > involving some heavy hitters like awk. Mind sharing why you choose > > against them? > > POSIX's goal was to document the common behavior across various > Unix derivates. In situations, when different, incompatible > behavior was present, it sometimes chose one of the alternatives > or none, if one could live without. For the most part, it refused > to standardize new behavior, especially if there was no important > reason to do so. To me, arithmetic expressions in sh are kind of > superfluous. There already exist alternatives in POSIX that are > older and more widespread: expr(1) for the simple stuff, bc(1) > for the complex stuff, test(1) for boolean, and awk(1) for the full > power of $((...)). Their only downside is time performance, which > I hardly like to accept as a good motivation. > > Arithmetic expressions are an extension of the shell command > language, which introduces new syntax and a new thinking model, > whereas there already existed solutions, which either fitted > into the existing thinking model (expr(1), test(1)) or already > introduced new thinking models (bc(1), awk(1)). > > IMO arithmetic expressions were unnecessary to add (from the Unix > standard shell POV (not from David Korn's POV, as I like to > admit)). (Even more, their syntax is badly chosen, as it is too > close to $(...) and (...).) > > These are (conceptual) reasons I don't like arithmetic > expressions. > > And, of course, old shells don't support them. Which is a > (increasingly less important) practical reason.
Thanks a bunch for this piece of historical background, Markus! I've been late to the game to not know this (and lots more) part of the evolution. Makes total sense. > > The tr|sed|nl is such nice little gem i'd definitely go with it, > > readability objections well deserved still. > > The coolnes factor is definitely high. ;-) > > It's only acceptable if it is wrapped in a function with a name > that clearly describes what's going on. > > > > I'd rate the given options (in order of descending preference) - > > 1. tr|sed|nl 2. sh w/ expr(1) and 3. awk. What about you? > > First step, I'd say: Write some enum() or countto() or even still > name it seq() function in test/common.sh, which only accepts a > single argument and does what seq(1) does if it has exactly one > argument. Then use this helper function in the test cases. The > actual implementation becomes a minor topic thus. We can change > it easily then. Will do! ... with the cool one :) v, over and out
