Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#10241 closed defect (fixed)

Remove unportable '-q' option to grep on SAGE_ROOT/spkg/install

Reported by: drkirkby Owned by: GeorgSWeber
Priority: major Milestone: sage-4.6.1
Component: build Keywords:
Cc: leif, jhpalmieri Merged in: sage-4.6.1.alpha1
Authors: David Kirkby Reviewers: Dmitrii Pasechnik
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description (last modified by drkirkby)

Although the -q option to grep is defined by POSIX, many older greps do not implement this. Even the man page of grep on a Linux machine says not to use -q or -s on scripts that are supposed to be portable.

The grep in /usr/bin on Solaris does not support the option. This is done by Sun to maintain backward compatibility with older versions which did not support it. So this causes a problem.

drkirkby@hawk:~/sage-4.6.1.alpha0$ make
spkg/pipestatus "cd spkg && ./install all 2>&1" "tee -a ../install.log"
grep: illegal option -- q
Usage: grep -hblcnsviw pattern file . . .

POSIX says:

-q
    Quiet. Nothing shall be written to the standard output, regardless of matching lines. Exit with zero status if an input line is selected.

so it is quite easy to work around. In general,

The -q option only suppresses the output. The exit code is then used to determine if there was a match or not - 0 if if there was a math, 1 if there was not.

That exit code works on Solaris too, so it's only necessary to drop the -q and send the output to /dev/null.

grep -q sometext somefile

needs to be changed to

grep sometext somefile > /dev/null

See also:

http://www.gnu.org/software/hello/manual/autoconf/Limitations-of-Usual-Tools.html#grep

Attachments (2)

install (8.7 KB) - added by drkirkby 12 years ago.
Revised install file, which avoids the unportable grep -q
install.diff (534 bytes) - added by drkirkby 12 years ago.
Unified diff, for review purposes only. The install file is not in a repository

Download all attachments as: .zip

Change History (12)

Changed 12 years ago by drkirkby

Revised install file, which avoids the unportable grep -q

Changed 12 years ago by drkirkby

Unified diff, for review purposes only. The install file is not in a repository

comment:1 Changed 12 years ago by drkirkby

  • Authors set to David Kirkby
  • Status changed from new to needs_review

comment:2 Changed 12 years ago by drkirkby

  • Description modified (diff)

This needs review.

comment:3 Changed 12 years ago by jhpalmieri

  • Type changed from PLEASE CHANGE to defect

comment:4 Changed 12 years ago by dimpase

  • Status changed from needs_review to positive_review

looks and works good.

comment:5 Changed 12 years ago by jdemeyer

  • Reviewers set to Dmitrii Pasechnik

comment:6 Changed 12 years ago by jdemeyer

  • Merged in set to sage-4.6.1.alpha1
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:7 follow-up: Changed 12 years ago by leif

Post-mortem comment: ;-)

In general I'm not very happy with avoiding POSIX options just because some people don't set their PATH properly.

IMHO Sage's configure should handle such. We're not building gcc, nor do we support last millenium's systems...

(Btw, egrep and echo -n aren't very portable in that sense either. If we only use the smallest subset of all systems or program versions one could think of, the code gets unreadable and harder to maintain.)

Fortunately, sage-upgrade won't get very large (I hope), but that's not the case for other uses of grep -q. Abusing sed is IMHO not an option (see above).

comment:8 in reply to: ↑ 7 ; follow-up: Changed 12 years ago by jdemeyer

Replying to leif:

Post-mortem comment: ;-)

In general I'm not very happy with avoiding POSIX options just because some people don't set their PATH properly.

What has this to do with setting PATH?

comment:9 in reply to: ↑ 8 ; follow-up: Changed 12 years ago by leif

Replying to jdemeyer:

Replying to leif:

Post-mortem comment: ;-)

In general I'm not very happy with avoiding POSIX options just because some people don't set their PATH properly.

What has this to do with setting PATH?

Ask Oracle... ;-)

(The POSIX-conformant versions aren't in the default PATH, for "compatibility" reasons.)

comment:10 in reply to: ↑ 9 Changed 12 years ago by drkirkby

Replying to leif:

Replying to jdemeyer:

What has this to do with setting PATH?

Ask Oracle... ;-)

(The POSIX-conformant versions aren't in the default PATH, for "compatibility" reasons.)

Of course the fact the default path does not always have POSIX options is a little unfortunate, but does mean Solaris has excellent backward compatibility. A 20 years old SunOS binary will still run today on Solaris.

I do occasionally build Sage on the 2005 edition of Solaris 10, and it works on the latest revision.

The same can not be said for Linux, where it seems that there is a never ending battle of keeping things working as the operating systems are updated.

  • ECL does not work on Fedora 14 - #10185
  • Readline not work on the latest Arch or openSUSE #9530
  • etc, etc etc.

I've yet to see one single example of where Sage builds on an old version of Solaris, but not on a newer one. It should also be noted that Linux does not ship with POSIX commands - ls, df, du being 3 simple examples. But there are tons of them.

https://www.opengroup.org/platform/single_unix_specification/uploads/40/13450/POSIX_and_Linux_Application_Compatibility_Final_-_v1.0.pdf

Like it or not, to create portable code, it is best to test on multiple platforms and whenever possible work around non-portable options. In a case like grep it is trivial.

Some common examples of non-portable code are given at

http://www.gnu.org/software/hello/manual/autoconf/Limitations-of-Usual-Tools.html#grep

Dave

Note: See TracTickets for help on using tickets.