On Tue, Nov 13, 2018 at 8:32 PM Brian Norris <briannor...@chromium.org> wrote: > > Hi Alexander, > > On Tue, Nov 13, 2018 at 12:36 AM Alexander Kapshuk > <alexander.kaps...@gmail.com> wrote: > > > > On Tue, Nov 13, 2018 at 2:09 AM Brian Norris <briannor...@chromium.org> > > wrote: > > > > > > On Mon, Nov 12, 2018 at 10:42:26AM +0200, Alexander Kapshuk wrote: > > > > An even simpler approach would be: > > > > > > > > { > > > > git --no-optional-locks status -uno --porcelain 2>/dev/null || > > > > git diff-index --name-only HEAD > > > > } | grep -qv scripts/package && > > > > printf '%s' -dirty > > > > > > > > Sample run: > > > > cmd > > > > sh: cmd: command not found > > > > > > > > { > > > > cmd 2>/dev/null || > > > > date > > > > } | grep -q 2018 && > > > > printf '%s' ok > > > > ok > > > > > > You lose accuracy here, because now you're skipping any line that > > > contains 'scripts/package', which would include, e.g., paths like > > > > > > tools/some/other-scripts/package > > > > > > Maybe if the grep expression were more like this? > > > > > > grep -qv '^\(.. \)\?scripts/package' > > > > > > I think it'd be safe enough to ignore paths that start with two > > > characters and a space, like: > > > > > > xy scripts/package > > > x/ scripts/package > > > > > > Brian > > > > Thanks for your input. > > I've found the following grep command, that uses extended regular > > expressions, to work as required: > > Is there any good reason you switched to extended? It looks like my > (basic regex) grep was equivalent. > > > { > > echo hello > > echo scripts/package > > echo '.. scripts/package' > > echo tools/some/other-scripts/package > > } | grep -Ev '^(.. )?scripts/package' > > > > [Output] > > hello > > tools/some/other-scripts/package > > > > If the participants of this email exchange consider the proposed > > implementation as fitting the bill, > > > > { > > git --no-optional-locks status -uno --porcelain 2>/dev/null || > > git diff-index --name-only HEAD > > } | grep -Eqv '^(.. )?scripts/package' && > > printf '%s' -dirty > > > > Was the original committer of the patch proposed here, > > https://lkml.org/lkml/2018/11/10/55, going to take it in, and resend it > > as v2 of the patch, or did you want me to submit the patch instead? > > I would be happy with either way. > > I can submit it. I expect Masahiro-san would prefer a proper v2 patch > for review, given how much would change from my v1. > > And this time, I'll actually test it with a non-dirty tree! (Of > course, my tree is naturally dirty when developing the patch, but I > missed testing post-commit...) > > Brian
Hi Brian, Thanks for taking my proposed patch in and submitting it. I went with the ERE because, in my opinion, the pattern looks 'cleaner' without having the metacharacters like '()?' escaped. EREs are POSIX-compatible, so should be supported by any POSIX-compliant shell. Your non-ERE version does generate the same output as my ERE one. So it just boils down to one's personal preference. Thanks.