Re: AC_PROG_SED

[Tim Van Holder]

Oh dear - my DOS/DJGPP-advocacy spider-sense is going into overdrive. I
need to pay closer attention to the lists; I should have seen this in
libtool and patched it there :-)
This has several issues; several of them can be resolved by adapting the
macro to better match one of the current autoconf ones (AC_PROG_INSTALL,
for example).

> +# AC_PROG_SED
> +# --------------
> +# Check for a fully-functional sed program, that truncates
> +# as few characters as possible.  Prefer GNU sed if found.
> +AC_DEFUN([AC_PROG_SED],
> +[AC_MSG_CHECKING([for a sed that does not truncate output])
> +if test "x$SED" != "x"; then
> +  :
> +else
> +# Loop through the user's path and test -x for sed and gsed.
> +# Then use that list of sed's as ones to test for truncation.
> +  _sed_list=""
> +  save_ifs="$IFS"; IFS=':'
> +  for pat in $PATH; do
> +    IFS="$save_ifs"

autoconf provides a PATH_SEPARATOR variable that should be used for path
walks instead of a hardcoded ':'.  In fact, you could/should probably
use the AS_PATH_WALK() macro.

> +    if test -x "$pat/sed"; then

autoconf has the AS_EXECUTABLE_P() macro that should be used instead of
'test -f'.  test -x is not the right test in any case (might find a
directory 'sed' in the path).  I know you tack on a 'test -f' later, but
still...
Plus, as of 2.52 (or CVS, not entirely sure), such program checks should
also loop through ac_executable_extensions to make sure programs are
found on systems that have executable extensions.

> +  trap "rm -f /tmp/$$-sed-out /tmp/$$-sed-in /tmp/$$-sed-in-nl /tmp/$$" 0 2 
> 13

More hardcoding - prefer $TMPDIR over /tmp.

> +  if (echo "testing\c"; echo 1,2,3) | grep c >/dev/null; then
> +    if (echo -n testing; echo 1,2,3) | sed s/-n/xn/ | grep xn >/dev/null; 
> then
> +      ac_n=
> +      ac_c='
> +'
> +      ac_t=' '
> +    else
> +      ac_n=-n
> +      ac_c=
> +      ac_t=
> +    fi
> +  else
> +    ac_n=
> +    ac_c='\c'
> +    ac_t=
> +  fi

These are set up at configure startup (called ECHO_N, ECHO_C and
ECHO_T).

> +  _max=0
> +  _count=0
> +  # Add /usr/xpg4/bin/sed as it is typically found on Solaris
> +  # along with /bin/sed that truncates output.

Is that wise?  If /usr/xpg4/bin/sed is in the path, you already have it
in the list; if not, do we really want to ignore PATH and just select a
program we know might exist?

> +  for _sed in $_gsed $_sed_list /usr/xpg4/bin/sed; do

I don't think $_gsed is ever set; remnant from a previous version?

> +    test ! -f ${_sed} && break
> +    cp /dev/null /tmp/$$-sed-in

Do all cp's support copying special files?

> +    echo $ac_n "0123456789$ac_c" >/tmp/$$-sed-in

And doesn't this already create the file from scratch?  So why the cp at
all?

> +    while /bin/true; do

More hardcoding... any particular reason why the /bin/ is needed?

> +if test ! -x $SED; then
> +  # Error out if $SED is not executable.
> +  AC_MSG_ERROR([cannot execute $SED.])

Automake has never cared about that so far, I think; mainly because the
sed found here is requested by the user, so it only needs to be
executable at build time, not necessarily at configure time.
If configure wants to use $SED itself, then a 'test -x' may be
warranted.