Re: AC_PROG_SED

[Robert Boehne]

Tim:

Ok, ok, I should have caught at least *half* of those problems.
I'll rework and re-post.  This macro isn't in Libtool at the
moment, Libtool was the reason it was needed, and it seemed
more appropriate for Autoconf rather than Libtool.
In July we (Libtool) decided we needed such a macro but had
never actually written it.

Thanks,

Robert

Tim Van Holder wrote:
> 
> 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.

-- 
Robert Boehne             Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  address@hidden