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 <sl...@troubleshooters.com> wrote: > On Thu, 20 Aug 2015 22:28:45 +0200 > Didier Kryn <k...@in2p3.fr> 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@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng