[Top][All Lists]
[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
Re: gnulib-tool nits, Paul Eggert, 2007/06/26