[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Re: better init.d/* : who carres ?



Russ Allbery <rra@stanford.edu> wrote:

> I find constructs like ${string#*=} particularly difficult to read,
> since they require that I remember what all the different punctuation
> characters inside this sort of parameter expansion do.  According to
> the bash manual, there are sixteen of them, and I had to read the
> description of ${parameter#word} three times before I completely
> understood what it said.

Dunno if I can post on the list, (I'm not a devel), but have an opinion
anyhow, so...

Two views of the difficulty:

1) The man page descriptions of these functions could probably be
improved.  

The trouble with obscure technical language is that when you complain,
it may inspire the snappy comeback that the complainer is too dumb to
understand the expert's smart terms**.  Warfare ensues.

(**which every so often turns out to be true.)

Many maintainers are happy to fix text, especially if you send a patch.
The difficulty is that if you don't understand what you're trying to
rewrite because the original text is vague, (which could be all there is
to go on), then you can't be certain how to rewrite it.  At that point
it helps to be able to ask the original author what they meant by
various words in their contexts.  Which can be a tedious process,
because authors who write vague descriptions also may tend to give curt
or vague answers when asked, which can lead to several rounds of
questions to understand a single word.  Mutual boredom or resentment may
ensue.


2) The syntax of those constructs IS cryptic, though they're useful
functions.

What follows describes a kludge for having one's cake and eating it, by
using little shell functions with easy syntax.  A lot can be done with
POSIX.

See attached file (5K) for some shell functions mostly modeled after
BASIC functions, but could be made to match familiar string function
syntax in most any language.  Examples:

        % . ashstring.sh -lib	# load functions in current shell
        % x="Hello World"
        % len "$x"	# length
        11
        % left "$x" 7	# left 7 chars
        Hello W
        % right "$x" 7	# right 7 chars
        o World
        % reverse "$x"
        dlroW olleH
        % splitchar "`reverse "$x"`"
        d l r o W   o l l e H
        % mid "$x" 2 4	# middle 4 chars, starting from 2nd
        ello
        % instr "$x" Wor  # what position is 'Wor'?
        7
        % ImGrep "foo.*" "$x" ; echo $?  # is 'foo' in string?
        1	# no
        % ImGrep "*llo*" "$x" ; echo $?	# is 'llo' in string?
        0	# yes
        #  Note: 'ImGrep' isn't BASIC, but doesn't have proper regexps
        #  -- it works via 'case' expressions.


In a sense it's an "additional library", which might be seen as excess
baggage, but the code itself is all just in-shell 'ash' (or 'dash')
functions -- low memory, often faster than using a  util, with no pipes,
and no external binaries.  I doubt the above functions have the best
possible syntax, (or behavior, not much error checking), but they're
easier to read than the shell code they're made up of; consider it a
"proof of concept".

For 'init' scripts, it raises a question of which string operations are
the most common and useful.  Some things are better done with external
utils like 'sed', but 'sed' or 'grep' may be overkill just to examine
one string.

Hope this is of interest...

Attachment: ashstring.sh
Description: application/shellscript


Reply to: