Source-Changes archive

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

CVS commit: [netbsd-8] src/bin/sh



Module Name:    src
Committed By:   martin
Date:           Mon Sep 10 15:45:11 UTC 2018

Modified Files:
        src/bin/sh [netbsd-8]: expand.c parser.c syntax.c syntax.h

Log Message:
Pull up following revision(s) via patch (requested by kre in ticket #1015):

        bin/sh/expand.c: revision 1.124
        bin/sh/expand.c: revision 1.127
        bin/sh/parser.c: revision 1.148
        bin/sh/parser.c: revision 1.149
        bin/sh/syntax.c: revision 1.6
        bin/sh/syntax.h: revision 1.9 (partial)

First pass at fixing some of the more arcane pattern matching
possibilities that we do not currently handle all that well.

This mostly means (for now) making sure that quoted pattern
magic characters (as well as quoted sh syntax magic chars)
are properly marked, so they remain known as being quoted,
and do not turn into pattern magic.   Also, make sure that an
unquoted \ in a pattern always quotes whatever comes next
(which, unlike in regular expressions, includes inside []
matches),

 -

Part 2 of pattern matching (glob etc) fixes.
Attempt to correctly deal with \ (both when it is a literal,
in appropriate cases, and when it appears as CTLESC when it was
detected as a quoting character during parsing).

In a pattern, in sh, no quoted character can ever be anything other
than a literal character.   This is quite different than regular
expressions, and even different than other uses of glob matching,
where shell quoting is not an issue.

In something like
        ls ?\*.c
the ? is a meta-character, the * is a literal (it was quoted).  This
is nothing new, sh has handled that properly for ever.

But the same happens with
        VAR='?\*.c'
and
        ls $VAR
which has not always been handled correctly.   Of course, in
        ls "$VAR"
nothing in VAR is a meta-character (the entire expansion is quoted)
so even the '\' must match literally (or more accurately, no matching
happens - VAR simply contains an "unusual" filename).  But if it had
been
        ls *"$VAR"
then we would be looking for filenames that end with the literal 5
characters that make up $VAR.

The same kinds of things are requires of matching patterns in case
statements, and sub-strings with the % and # operators in variable
expansions.

While here, the final remnant of the ancient !! pattern matching
hack has been removed (the code that actually implemented it was
long gone, but one small piece remained, not doing any real harm,
but potentially wasting time - if someone gave a pattern which would
once have invoked that hack.)


To generate a diff of this commit:
cvs rdiff -u -r1.110.2.4 -r1.110.2.5 src/bin/sh/expand.c
cvs rdiff -u -r1.132.2.5 -r1.132.2.6 src/bin/sh/parser.c
cvs rdiff -u -r1.3.26.1 -r1.3.26.2 src/bin/sh/syntax.c
cvs rdiff -u -r1.7.2.1 -r1.7.2.2 src/bin/sh/syntax.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.




Home | Main Index | Thread Index | Old Index