packaging scripts and others like upsdrvsvcctl/nut-driver-enumerator.sh.in should use the EGREP they located during configure/build

[nbriggs]

scripts/upsdrvsvcctl/nut-driver-enumerator.sh.in contains grep invocations like

scripts/upsdrvsvcctl/nut-driver-enumerator.sh.in:if set | grep -E '^(shell|version|t?csh)' | grep -E 't?csh' >/dev/null ; then
scripts/upsdrvsvcctl/nut-driver-enumerator.sh.in:        echo "$SVCINST_PROPS" | grep -E "^${SVCINST}${TABCHAR}"'$' >/dev/null && echo "$SVCINST"
scripts/upsdrvsvcctl/nut-driver-enumerator.sh.in:        echo "$SVCINST_PROPS" | grep -E "^${SVCINST}${TABCHAR}" >/dev/null || echo "$SVCINST"
scripts/upsdrvsvcctl/nut-driver-enumerator.sh.in:        echo "$SVCINSTS" | grep -E "^${SVCINST_PROP}"'$' >/dev/null || echo "$SVCINST_PROP"
scripts/upsdrvsvcctl/nut-driver-enumerator.sh.in:        echo "$SVCINST_PROPS" | grep -E "^${SVCINST}${TABCHAR}"'$' >/dev/null && echo "$SVCINST"
scripts/upsdrvsvcctl/nut-driver-enumerator.sh.in:        echo "$SVCINST_PROPS" | grep -E "^${SVCINST}${TABCHAR}" >/dev/null || echo "$SVCINST"

However it has gone to some trouble during configure step to determine what the functional names of EGREP, FGREP, and GREP are -- and on a Solaris system those are

scripts/upsdrvsvcctl/Makefile:EGREP = /usr/gnu/bin/grep -E
scripts/upsdrvsvcctl/Makefile:FGREP = /usr/gnu/bin/grep -F
scripts/upsdrvsvcctl/Makefile:GREP = /usr/gnu/bin/grep

not just plain grep. So... it would be helpful if the transformation from nut-driver-enumerator.sh.in to nut-driver-enumerator.sh took this into account.

[jimklimov]

Thanks! (First reaction) The emoticons of GitHub sorely lack a "facepalm" icon :-D

On one hand, this issue may be seen as a follow-up from #1660 to use grep -E because some systems issued warnings at any egrep shorthand use - however (Second reaction - looking at code) "going through trouble" seems to be part of automake core, not much noted consciously. There is one AC_PROG_EGREP in configure.ac (since the beginning of time, 2005 or before), and a few mentions that arguably disregard it in docs/Makefile.am and docs/man/Makefile.am by defining EGREP = grep -E (those are mine, likely from that ticket).

The uppercase variables are only $(EGREP)'s used in those two Makefiles, and a $(GREP) once in scripts/python/Makefile.am, and a bit from before such detection in ci_build.sh.

In short, such automake-detected variables are practically not used in written code at the moment. Same for SED and AWK by the way.

[jimklimov]

BTW, does the current situation cause any practical issues? Is there some incompatibility with the grep etc. implementation that it finds in PATH? (arguably that would be a bug - depending on particularly GNU grep etc.)

I was running NUT builds on Solaris 10, OpenSolaris and later illumos distros, installed via old-style make package artifacts, and there were no hiccups noted, especially with NDE scripts (get a lot of occasional testing in such loops as part of pre-/post- install/remove scripts of the package).

[nbriggs]

Yeah, unfortunately it does cause a problem - /usr/gnu/bin is not on root's path (for various reasons) and -E is not an option accepted by Solaris' /usr/bin/grep --

grep -E test /tmp/test
grep: illegal option -- E
Usage: grep [-c|-l|-q] -bhinsvw pattern file . . .

I have /usr/gnu/bin on the path while I'm building and packaging it, so grep -E is ok, but after installing, at runtime, the script scripts/upsdrvsvcctl/nut-driver-enumerator.sh fails because it has the standard root PATH.

My. workaround was to go through all the scripts that it installed and change all grep to /usr/gnu/bin/grep. Which is fine for now, but not a desirable long-term solution, hence the issue.

[nbriggs]

I'm building on Solaris 11.4.81.193.1 on a 32-processor SPARC box - after upgrading a 3 year old software installation to the latest Solaris CBE build. Oracle updated many things that cause recompiles... like openssl transition to openssl3, python2 removed, new python3 version, various system libraries got version updates and the old versions were removed, ...

[jimklimov]

That's very odd, which Solaris release is this about? I think since Solaris 10 (maybe before) the /usr/xpg4/bin/grep also supported -E -- I wonder if that was dropped in some later releases and/or non-Oracle distros? Or if your installation has some other implementation (IIRC there were many to juggle, e.g. ccs, maybe other xpg numbers?)

UPDATE: Got your post above while writing mine. CC @alanc

BTW, does that system offer a /usr/bin/egrep that would work? Can you see if it is a link to /usr/bin/grep (so one binary that decides what to do based on argv[0]), or a separate program? Note that at face value things in /usr/bin may be hardlinks to an ISA handler program that picks a real binary from a subdirectory based on needed architecture.

[nbriggs]

BTW, does that system offer a /usr/bin/egrep that would work?

It certainly has an egrep, but whether that would work for the uses it's being put to in NUT I haven't investigated. For building open source software you generally have to put the gnu tools first on the PATH. The problems come up with situations like here, where configuration discovers the absolute path for the right version but then doesn't incorporate that into the installed versions of helper scripts.

In /usr/bin, the *grep family are all separate programs, not hard links to one executable (I checked the link counts and inode numbers).

On Solaris the equivalent of the Linux "alternative" command is the "package mediators" -- same general functionality, mediators set up the symbolic links for alternative implementations or versions. That's not what's being done for the grep family either.

There are /usr/xpg{4,6,7}/bin directories, with various executables that conform to the different specs - though the grep family is only in /usr/xpg4/bin/ -- and those are a single implementation with grep, egrep, fgrep all hard-linked together. But again, the default path for root does not include /usr/xpg4/bin - so if the NUT configuration step were to find that, it would still be necessary to substitute the absolute path in the installed script rather than relying on PATH being the same at runtime and configuration time.

[alanc]

On Solaris, your choices for egrep are:

• /usr/bin/egrep - available on all releases since Solaris 1.0 in the early 1990's
• /usr/xpg4/bin/grep -E - available on Solaris 2.5 & later
• /usr/gnu/bin/grep -E or /usr/gnu/bin/egrep - available on Solaris 11.0 & later

When building FOSS for Solaris, we certainly end up putting /usr/gnu/bin first in $PATH quite often in order to deal with scripts that expect support for grep -E, GNU extensions to gettext, etc.

[jimklimov]

Thanks Alan. On OpenIndiana and OmniOS I see /usr/bin/grep and /usr/xpg4/bin/grep as one being a symlink to the to the other, so wondered if in proper Solaris it was a third program or also a convenience link to one of the implementations.

[alanc]

No, on Solaris itself, /usr/bin/grep is still the ancient SunOS version, without support for -E and -F yet.

[nbriggs]

I'm looking at fixing up the following files

        modified:   Makefile.am
        modified:   clients/Makefile.am
        modified:   docs/Makefile.am
        modified:   docs/docinfo.xml.sh.in
        modified:   docs/man/Makefile.am
        modified:   scripts/systemd/nut-server.service.in
        modified:   scripts/upsdrvsvcctl/nut-driver-enumerator.sh.in

to use the autotools generated @EGREP@ and $(EGREP). There are cases like grep -vE where I'm assuming that if $(EGREP) is working that $(EGREP) -v will also work.