Junio C Hamano <gits...@pobox.com> wrote:
> Ivan Tham <pickf...@riseup.net> writes:
>
> > Shell are widely used but comes with lots of different patterns. The
> > build-in pattern aim for POSIX-compatible shells with some additions:
> >
> > - Notably ${g//re/s} and ${g#cut}
> > - "function" from bash
> >
> > Signed-off-by: Ivan Tham <pickf...@riseup.net>
> > ---
> > Documentation/gitattributes.txt | 2 ++
> > t/t4034-diff-words.sh | 1 +
> > t/t4034/sh/expect | 14 ++++++++++++++
> > t/t4034/sh/post | 7 +++++++
> > t/t4034/sh/pre | 7 +++++++
> > userdiff.c | 5 +++++
> > 6 files changed, 36 insertions(+)
> > create mode 100644 t/t4034/sh/expect
> > create mode 100644 t/t4034/sh/post
> > create mode 100644 t/t4034/sh/pre
> >
> > diff --git a/Documentation/gitattributes.txt
> > b/Documentation/gitattributes.txt
> > index a53d093ca..1bad72df2 100644
> > --- a/Documentation/gitattributes.txt
> > +++ b/Documentation/gitattributes.txt
> > @@ -706,6 +706,8 @@ patterns are available:
> >
> > - `ruby` suitable for source code in the Ruby language.
> >
> > +- `sh` suitable for source code in POSIX-compatible shells.
>
> The new test you added seems to show that this is not limited to
> POSIX shells but also understands bashisms like ${x//x/x}. Perhaps
> drop "POSIX-compatible" from here
Those shells are still POSIX-compatible so I think it is true to put
that or otherwise, something like fish shell will break since it is
as well a shell but the syntax is totally different.
> > diff --git a/userdiff.c b/userdiff.c
> > index 8b732e40b..8d5127fb6 100644
> > --- a/userdiff.c
> > +++ b/userdiff.c
> > @@ -148,6 +148,11 @@ PATTERNS("csharp",
> > "[a-zA-Z_][a-zA-Z0-9_]*"
> > "|[-+0-9.e]+[fFlL]?|0[xXbB]?[0-9a-fA-F]+[lL]?"
> > "|[-+*/<>%&^|=!]=|--|\\+\\+|<<=?|>>=?|&&|\\|\\||::|->"),
> > +PATTERNS("sh",
> > + "^[ \t]*(function )?[A-Za-z_][A-Za-z_0-9]*[ \t]*()[\t]*\\{?$",
>
> There is something funky going on around parentheses on this line.
> The ones around "function " is meant to be syntactic metacharacters
> to produce a group in the regexp so that you can apply '?'
> (i.e. zero or one occurrence) to it. But I think the second pair of
> parentheses that appears later on the line, which enclose nothing,
> are meant to be literal? E.g. "hello (){\n\techo world;\n}\n" They
> would need some quoting, perhaps like
>
> ...[ \t]*\\(\\)[\t]*....
Ah, I think I forgot to escape the quoting of ( and ). I will send in another
patch for that.
> > + /* -- */
> > + "(\\$|--?)?([a-zA-Z_][a-zA-Z0-9._]*|[0-9]+|#)|--" /* command/param */
>
> TBH, I have no idea what this line-noise is doing.
That breaks word into "a", "$a" and "-a" as well as "$1" and "$#". I tried
supporting $? by adding +|#|\\?)--" but it doesn't seemed like it is working.
> $foobar, $4, --foobar, foobar, 123 and -- can be seen easily out of
> these patterns. I am not sure what --# would be (perhaps you meant
> to only catch $# and --# is included by accident, in which case it
> is understandable). It feels a bit strange to see that $# is
> supported but not $?; --foo but not --foo=bar; foobar but not "foo
> bar" inside a dq-pair.
Yes, getting --# will be very rare in shell. I think it is better to seperate
the --foo=bar into --foo and bar. I don't get what you man by the dq-pair.
> > + "|\\$[({]|[)}]|[-+*/=!]=?|[\\]&%#/|]{1,2}|[<>]{1,3}|[ \t]#.*"),
>
> And this one is even more dense.
Yes, that takes care of the operators, special symbols and stuff.
