Hi All... thanks to all that replied...

On 09/03/10 22:46, Denys Vlasenko wrote:
> On Fri, Sep 3, 2010 at 6:05 AM, Stuart Longland <[email protected]> wrote:
>> The logic I'd like to use is something like this:
>>
>> evt_a_seen=0
>> evt_b_seen=0
>> ( sleep 0.5 ; do_something ) &
>>
>> listener-prog | while read event; do
>>        case "${event}" in
>>                EVENT_A)
>>                        evt_a_seen=1
>>                        ;;
>>                EVENT_B)
>>                        evt_b_seen=1
>>                        ;;
>>        esac
>> done
>>
>> if [ ${evt_a_seen} = 0 ] || [ ${evt_b_seen} = 0 ]; then
>>        exit 1
>> fi
>>
>
> It's not a bug.
> As to a work-around, sometimes it is feasible to do this:
> 
> listener-prog | {
> while read event; do
>         case "${event}" in
>                 EVENT_A)
>                         evt_a_seen=1
>                         ;;
>                 EVENT_B)
>                         evt_b_seen=1
>                         ;;
>         esac
> done
> 
> if [ ${evt_a_seen} = 0 ] || [ ${evt_b_seen} = 0 ]; then
>         exit 1
> fi
> ...
> }
> 

That looks like it'll probably work fine in my situation, I'll give it a
try on Monday.  Having the situation explained, it makes sense now as to
why it didn't work.

In some other parts, I've used constructs like

for var in $( foo ); do
        blah
done

but that doesn't work in the above case since listener-prog returns one
entry per line.  The difference in terms of variables being set inside
the for loop I guess is that there are no pipes involved... $( foo )
gets evaluated, then that is passed to the for loop.  I could of course
change it to ensure each event has no spaces in it, and then for loops
would quite successfully in that case.

On 09/03/10 17:44, Christopher Barry wrote:
> while read event; do
>       case "${event}" in
>               EVENT_A)
>                       evt_a_seen=1
>                       ;;
>               EVENT_B)
>                       evt_b_seen=1
>                       ;;
>       esac
> done < <(listener-prog)

This method looks interesting too... however...
On 09/03/10 18:11, Bob Dunlop wrote (describing the same technique):
> Unfortunately Ash doesn't support named pipes.  I think Zsh also supports
> named pipes if you have that available.

I take it the "<(foobar)" is a form of named pipe?  I see I've got
plenty of reading to do. :-)

On 09/04/10 02:21, Harald Becker wrote:
> There exists a man page for ash, try google with "ash manpage" or use
> the following link:
> 
> http://linux.die.net/man/1/ash
> 
> But keep in mind, there are a few differences between real ash and the
> version included in busybox ... look ahead for another mail to this topic.

That link is one I intend to have a look at... is there somewhere that
describes the 'Busybox ash' scripting language?  I know there'll be
differences, ash in Busybox implements some bash features but not all,
and I'd imagine there are some ash features that are missing in Busybox
ash.  If there isn't such a document... where can I find out how they
differ?  This would be a useful thing to include on the Busybox site.

There is a bug ... it's in my understanding of how ash works, not in ash
itself. :-)

Regards,
-- 
Stuart Longland (aka Redhatter, VK4MSL)      .'''.
Gentoo Linux/MIPS Cobalt and Docs Developer  '.'` :
. . . . . . . . . . . . . . . . . . . . . .   .'.'
http://dev.gentoo.org/~redhatter             :.'

I haven't lost my mind...
  ...it's backed up on a tape somewhere.
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox

Reply via email to