Re: Shell script cleanups/style changes?

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 2, 2007, 20:37 UTC
Message-ID: <7vlkctvfk9.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <86bqdqkygp.fsf@lola.quinscape.zz>

David Kastrup <dak@gnu.org> writes:

Show 7 quoted lines

> 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.