bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnulib-tool nits


From: Ralf Wildenhues
Subject: Re: gnulib-tool nits
Date: Sun, 24 Jun 2007 19:23:46 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

* Eric Blake wrote on Sat, Jun 23, 2007 at 11:31:12PM CEST:
> According to Bruno Haible on 6/23/2007 1:09 PM:
> > But then use IFS (so that PATH elements containing spaces are handled
> > correctly), ignoring empty fields from the cases C and D. In summary,
> > something like this:
> > 
> >   pathx=`echo ":$PATH:" | sed -e 's/:::*/:.:/g' -e 's/^://' -e 's/:\$//'`
> 
> Or, to avoid the sed when possible, you could do
> 
> case `echo ":$PATH:" in

Why is there a need to fork here?
  case :$PATH: in

>   *::*) pathx=`echo ":$PATH:" \
>                | sed -e 's/:::*/:.:/g' -e 's/^://' -e 's/:\$//'` ;;
> esac

I assume that using either/both of `which' or `type' are so non-portable
or unparseable that it is out of the question (for Autoconf).  Is that
the case?  I'm asking because in typical configure scripts,
_AS_PATH_WALK is expanded rather often, its use of $PATH_SEPARATOR makes
the above even longer, and if we have to fork anyway, and take care of
`echo' issues here, it may make sense to look for a decent path finder
algorithm in a preparation step.

>>> I think SUSv3 wording is saying that pdksh is right and bash is wrong.  :-/
>>
>>I cannot find any specification of it at all in POSIX: The relevant text at
[...]
>>   The shell shall treat each character of the IFS as a delimiter and use the
>>   delimiters to split ... into fields.
>>
>>   Each occurrence in the input of ':' ... shall delimit a field ..."
>>
>>It is not clear whether empty fields can occur at all, and under which
>>conditions they appear at the front or at the end of the result.

To me this sounds pretty unambiguous: each ':' delimits a field,
otherwise they would have written "any sequence of ..." as they did with
IFS white space.  That should certainly rule out result A.  Result C is
inconsistent wrt. interpretation at the beginning and the end of the
input.  And since I don't see where fields are to be nonempty, I don't
see how result B is what is meant by the standard.  Of course an
explicit example would have been helpful.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]