-1

I have a vendor supplied too that emits this result:

40u (0xd926)
48u (0xd92e)
56u (0xd936)
64u (0xd93e)
104u (0xd966)
112u (0xd96e)
136u (0xd986)
144u (0xd98e)
153u (0xd997)
161u (0xd99f)
36l (0xd826)
44l (0xd82e)
52l (0xd836)
60l (0xd83e)
100l (0xd866)
108l (0xd86e)
132l (0xd886)
140l (0xd88e)
149l (0xd897)
157l (0xd89f)

You may recognize these as 802.11 channels.

I clean this list up by removing the parenthetical parts. Also, similar lists may contain entries that look like 56/80. I also need to remove the "/80" bits.

My result looks like:

40u 48u 56u 64u 104u 112u 136u 144u 153u 161u 36l 44l 52l 60l 100l 108l 132l 140l 149l 1571

In my ASH script (ASH not BASH) I have this where bandnick (2 or 5), bandwidth (20, 40, 80) and country (two letter country code) are 5, 80, and US in this case:

channels=`wl chanspecs -b $bandnick -w $bandwidth -c $country | cut -d' ' -f 1 | cut -d'/' -f 1 |  xargs echo -n`  

read response 

for t in $channels; do
     if [[ "$response" = "$t" ]]; then
        # stuff
     fi
done

When I run this code, answers up to "161u" are found in channels. "361" does not match.

I want to think this has to do with integer vs string compares, but nothing I have tried seems to work:

  1. remove quotemarks
  2. use -eq instead of = (lots or errors)
  3. add decorators to the test items [ "_$response" = "_$t' ]

Any suggestions on getting this to work?

Wes Miller
  • 2,191
  • 2
  • 38
  • 64

1 Answers1

0

Blush. I finally found what I wasn't seeing. The value 36l is three-six-ell not three-six-one. A pox on font designers who make ells loon like ones.

Thanks to anyone who read this and thought about the answer.

Wes Miller
  • 2,191
  • 2
  • 38
  • 64