what's with the loop with "in in" in u-boot.inc?

what's with the loop with "in in" in u-boot.inc?

[Robert P. J. Day]

  based on a recent post to this(?) list, i was curious about the
following loop construct in u-boot.inc:

        for config in ${UBOOT_MACHINE}; do
            for type in in ${UBOOT_CONFIG}; do
                if [ "${type}"x = "in"x ]
                then
                    continue
                fi

  the words "in in" above don't appear to be a typo, as the next
condition explicitly checks for the value "in" and skips it. what's
the rationale for that? i used "git blame" to examine the commit that
introduced that, but it says nothing about that curiosity.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: what's with the loop with "in in" in u-boot.inc?

[Bernhard Reutner-Fischer]

On March 7, 2015 3:04:52 PM GMT+01:00, "Robert P. J. Day" <rpjday@crashcourse.ca> wrote:
>
>  based on a recent post to this(?) list, i was curious about the
>following loop construct in u-boot.inc:
>
>        for config in ${UBOOT_MACHINE}; do
>            for type in in ${UBOOT_CONFIG}; do
>                if [ "${type}"x = "in"x ]
>                then
>                    continue
>                fi
>
>  the words "in in" above don't appear to be a typo, as the next
>condition explicitly checks for the value "in" and skips it. what's
>the rationale for that? i used "git blame" to examine the commit that

for may barf on empty iteration input.
One usually uses for i in ${foo} '';
and skips i with zero length. Any other is obviously fine, too though so nothing wrong or odd here.

HTH,

>introduced that, but it says nothing about that curiosity.
>
>rday

Re: what's with the loop with "in in" in u-boot.inc?

[Gary Thomas]

On 2015-03-07 10:48, Bernhard Reutner-Fischer wrote:
> On March 7, 2015 3:04:52 PM GMT+01:00, "Robert P. J. Day" <rpjday@crashcourse.ca> wrote:
>>
>>   based on a recent post to this(?) list, i was curious about the
>> following loop construct in u-boot.inc:
>>
>>         for config in ${UBOOT_MACHINE}; do
>>             for type in in ${UBOOT_CONFIG}; do
>>                 if [ "${type}"x = "in"x ]
>>                 then
>>                     continue
>>                 fi
>>
>>   the words "in in" above don't appear to be a typo, as the next
>> condition explicitly checks for the value "in" and skips it. what's
>> the rationale for that? i used "git blame" to examine the commit that
>
> for may barf on empty iteration input.
> One usually uses for i in ${foo} '';
> and skips i with zero length. Any other is obviously fine, too though so nothing wrong or odd here.

But this code is only executed if ${UBOOT_CONFIG} is non-empty
so this test is nonsense.

My guess is that the code originally tested for ${UBOOT_CONFIG}
being empty this way, then the if/then/else was added (look at
the indentation) and the original test was never removed (which
does no harm)

>
> HTH,
>
>> introduced that, but it says nothing about that curiosity.
>>
>> rday
>
>

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: what's with the loop with "in in" in u-boot.inc?

[Robert P. J. Day]

On Sat, 7 Mar 2015, Gary Thomas wrote:

> On 2015-03-07 10:48, Bernhard Reutner-Fischer wrote:
> > On March 7, 2015 3:04:52 PM GMT+01:00, "Robert P. J. Day"
> > <rpjday@crashcourse.ca> wrote:
> > >
> > >   based on a recent post to this(?) list, i was curious about the
> > > following loop construct in u-boot.inc:
> > >
> > >         for config in ${UBOOT_MACHINE}; do
> > >             for type in in ${UBOOT_CONFIG}; do
> > >                 if [ "${type}"x = "in"x ]
> > >                 then
> > >                     continue
> > >                 fi
> > >
> > >   the words "in in" above don't appear to be a typo, as the next
> > > condition explicitly checks for the value "in" and skips it. what's
> > > the rationale for that? i used "git blame" to examine the commit that
> >
> > for may barf on empty iteration input.
> > One usually uses for i in ${foo} '';
> > and skips i with zero length. Any other is obviously fine, too though so
> > nothing wrong or odd here.
>
> But this code is only executed if ${UBOOT_CONFIG} is non-empty
> so this test is nonsense.
>
> My guess is that the code originally tested for ${UBOOT_CONFIG}
> being empty this way, then the if/then/else was added (look at
> the indentation) and the original test was never removed (which
> does no harm)

  technically, it *is* possible that UBOOT_CONFIG contains a non-empty
string of spaces so, yes, that test still has some technical value
but ... you know ... yuck. movin' on ...

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================