samtools / htslib

C library for high-throughput sequencing data formats
Other
789 stars 447 forks source link

One invocation of `expr` incorrectly uses `/^…/` #1592

Closed jmarshall closed 1 year ago

jmarshall commented 1 year ago

One of the expr invocations in version.sh produces the following warning from busybox's implementation of expr, as used on e.g. Alpine Linux:

expr: warning: '^\([0-9.]*\)$': using '^' as the first character
of a basic regular expression is not portable; it is ignored

Either this needs the same sort of X treatment as the invocation in Makefile's htslib.map rule has, or apparently these expr patterns are defined to be anchored to the beginning of the string anyway so perhaps the ^ could just be removed.

jkbonfield commented 1 year ago

The mind boggles where else you'd use ^ other than the first character (I guess character classes only), but yes expr is apparently not quite standard. If it's not needed anyway then the solution is trivial. That's the daily new thing learnt :-)

Thanks.

jmarshall commented 1 year ago

If ^ is not in a place in the RE that makes it an anchor, then it matches a literal caret.

I think the rationale on that page is saying that there exist historical expr implementations that interpreted it as an anchor despite their own documentation saying that in expr a leading ^ would be a literal caret.

Learning every day indeed :smile:

jkbonfield commented 1 year ago

Even just using expr for command line regexp matching is pretty esoteric and old school. :) I was (naively) assuming it'd be more portable and canonical than sed. Hah