A Dirty Guide to Gambas Scripting - Part 1

I've always had a soft spot for interpreted languages like Gambas Script and Python. The ability to write & edit code in a simple text editor (rather than with a full-blown IDE) and run the code directly from this text file can have benefits, especially when working with low power, headless computers like the Raspberry Pi.

Also, in my opinion, a Basic-like language such as Gambas is a better starting point for newbies than a somewhat terse language like Python.

With Gambas scripting, all you need to do is install the package gambas3-script(er), open a new text file, make it executable, add the shebang, and start writing code. (note: installing gambas3-script/scripter will also install gambas3-dev & gambas3-runtime)

The shebang is the first line in the file. It instructs the system to use the Gambas script interpreter to run the code, and looks like this:-

 #!/usr/bin/env gbs3

So as a simple first example, create a new text file called GambasScript_1.gbs and add this:-


Now save and make the file executable, which can normally be done by accessing file permissions via the file manager.

Open the folder containing this file in a terminal (again, this can normally be done from the file manager via a menu or maybe a hot key like <F4>).

Run the script from the terminal like this:-
 ./GambasScript_1.gbs

…OK, not earth shattering, but its a start.

A Dirty Guide to Gambas Scripting - Part 2

The code in part 1 is pretty pointless, as it simply runs "ls -l" in a terminal and displayed the output in a terminal.

However, there are a few situations where Gambas scripting may be more useful, e.g.;

• creating a Gambas script to perform a series of tasks may be easier for a Gambas programmer than trying to write code in a regular bash script. Gambas is also more powerful than bash scripting.
• it may be possible to display the output of a Gambas script (either locally or remotely) via a pre-existing application, rather than using a simple terminal window.

Picking up on the second point, in the next code example I'm going to illustrate a program that will periodically scan the local network and save all discovered devices in an html file, which can then be viewed either locally or remotely via a web browser.

For this Gambas script, we need routines to:-

• get details of the network devices using the command line program: nmap
• write data in html to a file
• implement a timer to repeat the network scan every x seconds

So, after creating a new text file (don't forget the shebang!) we need to create a timer, set an initial delay and start it running:-


We need to write html to a file, but because nmap takes quite a while to return data, we should initially create the file quickly, with some kind of "Please wait…" message. So this routine (I've called WriteReport) needs 3 arguments; the network base address, a string containing all devices, and a flag to indicate if the current call includes data.



The nmap command needs the base network address, something like:-
(change this argument to suit your own local network)

And since the web browser is not synchronised with the html file updates, we need to force the browser to refresh the page from time to time;



The web browser display looks something like this;

I have attached the full program;

(Click to enlarge)

As mentioned in part 1, this kind of approach to gathering and displaying data is particularly useful when working with low power, headless computers, such as the Raspberry Pi.

Great info Steve cheers.

I think it's important to understand something about scripting and using gbs3.

The most important difference with a script file is that when run the gbs3 interpreter creates a temporary project folder (in /tmp/gmbas100/) and compiles the project to there then runs it.
This makes (made) a difference in the applications path, using the path "./" does not point to where the script is and neither did Application.Path.
I had to beg Benoit to make Application.Path point to the original script path and not the temporary created folder. And he agreed Application.Path pointing to the temporary folder was useless so he changed it.
The Application.Path is now useable making scripting much more versatile

My scripting editor ScriptEd is good for making gambas script files, it has a couple of handy features like running the script to test at the click of a button, and it uses the gambas TextEditor component so is does the same gambas highlighting as the gambas IDE does plus some auto-formatting.