David Kastrup <dak@xxxxxxx> writes:
> Hi, I wanted to ask what the general stance towards shell script
> cleanups and simplifications would be. For example, I find the expr
> usage quite inscrutable in commit, and there is no necessity of
> putting "shift" in every case branch instead of once behind it, and a
> lot of conditionals and other manipulations can be made much easier on
> the eye by using parameter expansion patterns that are, as far as I
> can see, available with every reasonable Bourne Shell and clones.
The shift in parameter parsing case arms were originally
generated by an automated tool. If it bothers you, feel free to
move them at the end, I would not mind. In fact, handcrafted
parameter parser in other scripts do use shift-at-the-end.
As to Bourne-ness of the shell script, please realize that your
maintainer is very old fashioned ;-), but is willing to be
taught new tricks within reason.
We try to limit ourselves to -, =, ?, + (and their colon "if
empty" variants when it really make sense) in parameter
expansion of shell variables. We also use % and # (and their
"match largest" variants).
Non POSIX substitions such as ${parameter/pattern/string} and
${parameter:offset} are not to be used. We do not want to
depend on bash.
We try to avoid [ ] and instead spell "test" explicitly; this is
just a personal taste, and not about portability but more about
readability.
After 1.5.3 git-commit.sh will hopefully become built-in, so I
would rather not touch the script. Certainly, the kind of
change that is "intended to be style-only but somebody needs to
make sure it does not introduce regression to everybody's shell"
is very unwelcome at this point.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
