FLDIGI Users Manual  4.0
Exec Macro

Table of Contents

The <EXEC> ... </EXEC> macro is designed to be used on the Linux OS as it supports fully functional pipes. Windows' version of file pipes is not fully POSIX compliant, but the function might work in the environment. Consider all that the following allows you to do from within fldigi and you might want to consider changing over to Linux.The <EXEC> macro defines an external child process (or processes) that will be called by fldigi when the macro key is invoked.

Exported variables

Fldigi exports a set of variables to the child process and adds ~/.fldigi/scripts to the PATH variable before running the shell code. This is the directory location for all executable scripts and programs which you might want to call from within the macro. Some examples will be given later. Open the macro editor for an undefined macro key and enter the following:

<EXEC>env | grep FLDIGI</EXEC>

Save the macro; call it ENV. Then press the newly defined macro key. All of the exported variables will be shown in the transmit window.

Here is an example of the results:


All of the above envelope variables can be referenced in a shell script that is called from within fldigi.

Detection of existing scripts

In anticipation of a collection of useful "fldigi scripts", the macro browser contains a <exec> </exec> macro line for each executable file found in the scripts directory. The EXEC macro allows the text that is read from the child process to be parsed for more fldigi macros. For example, try this macro:

<EXEC>cat foo</EXEC>

where foo is a file that contains:


This may have some interesting uses but, if it is undesirable, it can be suppressed with an extra layer of redirection. Instead of <EXEC>command</EXEC>, you would use <EXEC>noexp command</EXEC> where noexp is the following very simple script:

echo -n "<STOP>"
"$@"     # run the command
r=$?     # save its exit code
echo -n "<CONT>"
exit $?

There are three additional MACRO definitions that expand the capability of the <EXEC> command: <STOP>, <CONT> and <GET>. The <STOP> and <CONT> macros stop and resume the expansion of all <MACRO> strings. For example, <STOP><MYCALL><CONT><MYCALL> would only expand the second <MYCALL>.

By wrapping the command output in this way we can be sure that no text will be expanded. You might even use

"$@" | sed "s/<CONT>//g"

if you feel paranoid. You can "fork and forget" with an exec macro defined as: <EXEC>exec command -args >/dev/null</EXEC>

Any of the text that appears between the <EXEC> and </EXEC> can reference an executable program or shell command found in the ~/.fldigi/scripts directory.

Any text output that is returned by the program or script program (or the result of the in-line command) is always returned to the transmit buffer and appears as appended to the transmit window.

Querying an external database

The <GET> command captures returned text from the external process and parses it for the following content:


If either $NAME or $QTH is present the trailing text is transferred to the LOG_NAME or LOG_QTH widgets respectively. This means that you can create a script that accesses a local or net based database of callsign data and parse that data to form the above console output. Fldigi will accept that output, parse it and populate the associated log entries. Cool! Now for some examples. Here is a perl script that performs the above for the University of Arkansas on-line callsign database, ualr-telnet. The matching macro key definition for the above is:

<EXEC>ualr-telnet.pl $FLDIGI_LOG_CALL</EXEC><GET>

which I named "ualr ?"

Google Earth Map

Here is a really cool perl script, Google Earth Mapping, that accepts the current "Loc" field in the logging area and generates a Google Earth map which is displayed in your default browser.

The macro call is:


Custom dates/times

You can use <EXEC> to create custom date/time entries. For example, BARTG contesters use HM, but in other circumstances a user might prefer H:M or H.M etc. Create the following script file in the ~/.fldigi/scripts directory, call it mytime:

date --utc "+%H:%M"

date calls strftime, the same C function used by fldigi for the ZDT/LDT expansion, so it has an equally vast number of format strings to choose from. Look for them in its manual page.

Give "mytime" execute permissions with a file manager or with chmod: chmod u+x ~/.fldigi/scripts/mytime.

Test it on the command line and make sure it works correctly: ~/.fldigi/scripts/mytime

Restart fldigi. The mytime script will now appear at the end of the list in the macro browser, and can be entered with the << button as usual. Test that macro and you will see that <EXEC>mytime</EXEC> inserts the datetime in the specified format. Of course you could have entered:

<EXEC>date --utc "+%H:%M"</EXEC>

in the macro body text directly Many other uses for the <EXEC>...</EXEC> macro pair can be imagined when used the with ENV parameters. For example you could send Azimuth data to an automated antenna rotor. The exported variables should be sufficient for a script writer to create custom loggers and clients.

Return to Top of Page
Return to Main Page