[PATCH] CodingGuidelines: Fix a typo

[PATCH] CodingGuidelines: Fix a typo

[stepnem]

From: Štěpán Němec <stepnem@gmail.com>

`${parameter/pattern/string}' shell expansion uses glob patterns, so
talking about `regexp' is confusing.

Signed-off-by: Štěpán Němec <stepnem@gmail.com>
---
 Documentation/CodingGuidelines |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 8346c19..df50ccf 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -53,7 +53,7 @@ For shell scripts specifically (not exhaustive):
 
  - No strlen ${#parameter}.
 
- - No regexp ${parameter/pattern/string}.
+ - No substitution ${parameter/pattern/string}.
 
  - We do not use Process Substitution <(list) or >(list).
 
-- 
1.7.3.rc2.221.gbf93f.dirty

Re: [PATCH] CodingGuidelines: Fix a typo

[Jonathan Nieder]

stepnem@gmail.com wrote:

> `${parameter/pattern/string}' shell expansion uses glob patterns, so
> talking about `regexp' is confusing.

Okay.

> - - No regexp ${parameter/pattern/string}.
> + - No substitution ${parameter/pattern/string}.

A bit confusing, since ${parameter%word} and $parameter are
substitutions, too.

Maybe

 - No pattern substitution ${parameter/pattern/string}.

to match the bash manual, would be clearer?

Re: [PATCH] CodingGuidelines: Fix a typo

[Štěpán Němec]

Jonathan Nieder <jrnieder@gmail.com> writes:

> stepnem@gmail.com wrote:
>
>> `${parameter/pattern/string}' shell expansion uses glob patterns, so
>> talking about `regexp' is confusing.
>
> Okay.
>
>> - - No regexp ${parameter/pattern/string}.
>> + - No substitution ${parameter/pattern/string}.
>
> A bit confusing, since ${parameter%word} and $parameter are
> substitutions, too.

Not really. They are all parameter expansions. The former a "pattern
removal", the latter a plain expansion (yeah I know you can _call_ it a
substitution anyway, but I assume you were trying to be precise/match
the Bash manual wording here).

But I agree "pattern substitution" is even clearer, thanks.

BTW, when we continue on this slightly bike-shedding note, it would make
sense to unify the capitalisation of those termini technici in there
("Arithmetic Expansion", "Process Substitution"). Personally I would
prefer having them all in lower-case; it feels a bit funny to read "We
use Arithmetic Expansion". WDYT?

I hope the whitespace goes through undisturbed this time:

--- 8< ---
Subject: CodingGuidelines: Fix a typo

    `${parameter/pattern/string}' shell expansion uses glob patterns, so
    talking about `regexp' is confusing.

Signed-off-by: Štěpán Němec <stepnem@gmail.com>
---
 Documentation/CodingGuidelines |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 8346c19..e52474b 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -53,7 +53,7 @@ For shell scripts specifically (not exhaustive):

  - No strlen ${#parameter}.

- - No regexp ${parameter/pattern/string}.
+ - No pattern substitution ${parameter/pattern/string}.

  - We do not use Process Substitution <(list) or >(list).

--

Re: [PATCH] CodingGuidelines: Fix a typo

[Junio C Hamano]

Jonathan Nieder <jrnieder@gmail.com> writes:

> stepnem@gmail.com wrote:
>
>> `${parameter/pattern/string}' shell expansion uses glob patterns, so
>> talking about `regexp' is confusing.
>
> Okay.
>
>> - - No regexp ${parameter/pattern/string}.
>> + - No substitution ${parameter/pattern/string}.
>
> A bit confusing, since ${parameter%word} and $parameter are
> substitutions, too.

I had the same reaction.  Perhaps moving other parameter substitions
closer to these two would help?

	Side note: this is totally unrelated, but the below is --patience;
	our output without --patience is almost unreadable in this case.

 Documentation/CodingGuidelines |   27 +++++++++++++++------------
 1 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 8346c19..09ffc46 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -35,11 +35,22 @@ For shell scripts specifically (not exhaustive):
    properly nests.  It should have been the way Bourne spelled
    it from day one, but unfortunately isn't.
 
- - We use ${parameter-word} and its [-=?+] siblings, and their
-   colon'ed "unset or null" form.
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
 
- - We use ${parameter#word} and its [#%] siblings, and their
-   doubled "longest matching" form.
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No strlen ${#parameter}.
+
+   - No pattern replacement ${parameter/pattern/string}.
 
  - We use Arithmetic Expansion $(( ... )).
 
@@ -47,14 +58,6 @@ For shell scripts specifically (not exhaustive):
    of them, as some shells do not grok $((x)) while accepting $(($x))
    just fine (e.g. dash older than 0.5.4).
 
- - No "Substring Expansion" ${parameter:offset:length}.
-
- - No shell arrays.
-
- - No strlen ${#parameter}.
-
- - No regexp ${parameter/pattern/string}.
-
  - We do not use Process Substitution <(list) or >(list).
 
  - We prefer "test" over "[ ... ]".

Re: [PATCH] CodingGuidelines: Fix a typo

[Jonathan Nieder]

Junio C Hamano wrote:

> I had the same reaction.  Perhaps moving other parameter substitions
> closer to these two would help?

Yes, that looks like a definite improvement.