Very Computer

> if IFS is : then when running sh what should the list be when it sees
>     for var in /sbin:/usr/sbin:$PATH
> and on what does it depend?

> Context:

> I have been using WINE for some time.  As is normal, it has a configure
> script generated by autoconf.  The documentation for autoconf describes how,
> when using AC_PATH_PROG, you should add locations to the path it searches,
> which is using : as the separator.
> The resulting configure script is flagged as /bin/sh and includes the above
> "for clause"

> I know that at some point in the past a past version of the configure script
> worked "correctly" because my config.cache contains the correct answer.  But
> currently the script is only using the IFS when expanding the $PATH, so the
> first element of the list is /sbin:/usr/sbin:<the first entry in my path>
> and it is followed by the other entries in my path.

> (This is on Redhat Linux 7.1 with possibly a couple of upgrades in there
> somewhere)

> Anyone any idea what's going on?

> TIA

> Bill

>> if IFS is : then when running sh what should the list be when it sees
>>     for var in /sbin:/usr/sbin:$PATH
>> and on what does it depend?
>[snip]
> The behavior of:

>       for var in /sbin:/usr/sbin:$PATH

> is inconsistent between shells.  The original Bourne shell (and
> bash1 - the sh on RH 6.x) will split this as /sbin /usr/sbin
> /bin /usr/bin ... etc.  Later shells,  like bash2,  which I believe
> is now the sh on RH 7.1, will only split variables,  not text.
> What does work portably for all shells is to turn the above into
> a variable expresion that will be split.  Since $0 must exist,
> then:

>       for var in ${0:+/sbin:/usr/sbin:$PATH}

> will split correctly on all bournish shells.  Tested on Bourne, HP's
> posix sh, ksh88, ksh93, bash1 and bash2.

>>> if IFS is : then when running sh what should the list be when it sees
>>>     for var in /sbin:/usr/sbin:$PATH
>>> and on what does it depend?
>>[snip]
>> The behavior of:

>>       for var in /sbin:/usr/sbin:$PATH

>> is inconsistent between shells.  The original Bourne shell (and
>> bash1 - the sh on RH 6.x) will split this as /sbin /usr/sbin
>> /bin /usr/bin ... etc.  Later shells,  like bash2,  which I believe
>> is now the sh on RH 7.1, will only split variables,  not text.
>> What does work portably for all shells is to turn the above into
>> a variable expresion that will be split.  Since $0 must exist,
>> then:

>>       for var in ${0:+/sbin:/usr/sbin:$PATH}

>> will split correctly on all bournish shells.  Tested on Bourne, HP's
>> posix sh, ksh88, ksh93, bash1 and bash2.

>     Of course, if a literal string is being used, why would you put
>     colons instead of spaces?

> --

>          =================================================================

>>>       for var in /sbin:/usr/sbin:$PATH

>>> is inconsistent between shells.  The original Bourne shell (and
>>> bash1 - the sh on RH 6.x) will split this as /sbin /usr/sbin
>>> /bin /usr/bin ... etc.  Later shells,  like bash2,  which I believe
>>> is now the sh on RH 7.1, will only split variables,  not text.
>>> What does work portably for all shells is to turn the above into
>>> a variable expresion that will be split.  Since $0 must exist,
>>> then:

>>>       for var in ${0:+/sbin:/usr/sbin:$PATH}

>>> will split correctly on all bournish shells.  Tested on Bourne, HP's
>>> posix sh, ksh88, ksh93, bash1 and bash2.

>>     Of course, if a literal string is being used, why would you put
>>     colons instead of spaces?

> Presumably,  the script is being autogenerated.

> >>> will split correctly on all bournish shells.  Tested on Bourne, HP's
> >>> posix sh, ksh88, ksh93, bash1 and bash2.

> >>     Of course, if a literal string is being used, why would you put
> >>     colons instead of spaces?

> > Presumably,  the script is being autogenerated.

>     My question stands.

>> will split correctly on all bournish shells.  Tested on Bourne, HP's
>> posix sh, ksh88, ksh93, bash1 and bash2.

>    Of course, if a literal string is being used, why would you put
>    colons instead of spaces?