Parsing headaches:

I have this chunk of data retrieved from the backend which I need to
parse *reliably*. The goal is to read the SSID and the corresponsing
signal strength.

How should I proceed. This part of code will be done from within
Lazarus. Please, be informed that Lazarus generated GUI uses GTK* as a
base. The executable can is also statically built which means an
increased portability. Executables are about 3 MB. In the past I have
written such applications that dwarf what I am doing and still the
size is small.

Here is what I want to parse:

root@edbarx-pc:/home/edbarx# iwlist wlan0 scan | grep -B 4 ESSID

<<<<<<<<<
                    Channel:1
                    Frequency:2.412 GHz (Channel 1)
                    Quality=70/70  Signal level=-34 dBm
                    Encryption key:on
                    ESSID:"EB-TP-LNK67"
--
                    Channel:6
                    Frequency:2.437 GHz (Channel 6)
                    Quality=24/70  Signal level=-86 dBm
                    Encryption key:on
                    ESSID:"TNCAPA0332D"
--
                    Channel:11
                    Frequency:2.462 GHz (Channel 11)
                    Quality=30/70  Signal level=-80 dBm
                    Encryption key:on
                    ESSID:"Home WiFi"

>>>>>>>>>>>>>>>

On 20/08/2015, Steve Litt <slitt@???> wrote:
> On Thu, 20 Aug 2015 22:28:45 +0200
> Didier Kryn <kryn@???> wrote:
>
>> Le 19/08/2015 20:09, Edward Bartolo a écrit :
>> > The power inherent in C is due to it not
>> > getting in the way of the coder, and I like that.
>>
>
> [snip]
>
>>

>>      I didn't review your code. This has been done by others anyway.
>> My problem is that I don't see the big picture.

>
> My understanding is that the big picture is that Edward's making a very
> simple system for dealing with Wifi, both in your house and travelling
> from hotspot to hotspot. His solution has minimal dependencies and can
> be run by anyone with just about any Linux configuration. One reason he
> uses C is because there's no guarantee that Python or Ruby or Lua is
> installed on the system.
>
> Edward's front end obtains a list of Wifi transmitters, together with
> their signal strengths and encryption type, by spawning "iwlist $netdev
> scanning", where $netdev is typically but not always "wlan0". The user
> chooses one wifi transmitter from the front end, sends its ssid to the
> back end. The back end looks at its list of known ssids. If this ssid
> is known, it connects with the known password. Otherwise (and here I
> might be wrong), the back end signals the front end to query for the
> new password for the new ssid, and after the user puts in both, the
> front end sends it to the back end, that now does these two things:
>
> 1) Writes a new interface file, for this ssid, for future reference.
>
> 2) Connects to this ssid with the inputted password.
>
> My understanding is the back end is calling the ifup program, which I
> believe but am not sure, somewhere calls wpa_supplicant to do the work
> on Wifi. But I could be wrong about that.
>
> It's a pretty simple and, IMHO, robust architecture. One beauty of it
> is that, although Edward's using Lazarus to make a nice GUI front end
> for the thing, most people on this list could make a shellscript front
> end for it. Or zenity. Or Tcl/Tk. Or Python. Or whatever. If I
> understand correctly, his back end, and only his back end, is in C.
>

>>      I would also like to know what your understanding is of how the
>> things are handled by the cooperative interaction of ifup, ifdown and
>> wpa_supplicant. This is something for which I cannot find a
>> comprehensive description, and I think a full understanding is
>> necessary *prior* to endeavour what you are doing.

>
> You and I have a philosophical difference here. All too often, by the
> time people reach *full* understanding, the project languishes and
> nothing happens. Prior to the invasion of paid programmers in Open
> Source, the world was full of software written with a partial
> understanding, and incrementally improved (or rewritten) later.
>
> I wrote the original VimOutliner in 2 days, using Perl, Vim, and
> shellscripts. Kludge-city. If you'd seen that version 0.10, you'd have
> laughed.
>
> But unlike the other outliners of that era, VimOutliner worked, and
> worked fast. People started using it. People started depending on it.
> People a lot smarter than I started improving it. Within two years it
> was head and shoulders faster and more convenient and easier to use than
> any other outliner on the planet. That never would have happened
> without my two day kludge.
>
> Look at it another way. I was mouthing off about making a replacement
> for NetworkManager and Wicd. But I did nothing. Several others were
> talking about it, but they did nothing. Now Edward did it.
>
> There are different kinds of Open Source. When Redhat pays three years
> salary to Lennart and Kai and the gang, they can afford to take the
> time for full understanding. When a guy with a day job makes something,
> he gets it out there and the improvements come later. And for my money,
> I prefer the stuff made by unpaid guys with day jobs: They (we) don't
> have enough time to make entangled monoliths.
>
>> This is because
>> these 3 tools are doing a lot of things, and rather well and it is
>> a waste of time and talent to re-invent the wheel.
>
> He's not reinventing them at all. He's gluing them together so they're
> fast and convenient for a user walking his laptop from McDonalds to
> Starbucks.
>
> SteveT
>
> Steve Litt
> August 2015 featured book: Troubleshooting: Just the Facts
> http://www.troubleshooters.com/tjust
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>