Programming tips and known problems

Backquoted expressions

Backquoted expressions that appear on a line by themselves are evaluated before any descriptors are parsed. That is, they are evaluated before the frame is fully current. Thus, the following can occur:

if a stand-alone backquoted expression produces output to the message line, it may appear before the frame being parsed is posted. This delay may or may not be significant and depends on the complexity of the frame definition file.
message -f statements in stand-alone backquoted expressions are ignored.
the built-in function getfrm, if used in a stand-alone backquoted expression, may be parsed before the frame ID it is supposed to return is available.

If a command run in a backquoted expression changes the stty(1) setting, the FMLI session may be corrupted. Frames may not display correctly and the command line may not function (the latter occurs if <<Return>> is mapped to <LINEFEED> or to <<Return>> <LINEFEED>).

If a daemon process is started via a shell script that FMLI code invokes in a backquoted expression, FMLI waits for this process until the UNIX system clears up zombies. While waiting, FMLI appears to be locked because the backquoted command that was exec'd created a child whose stdout is still connected to FMLI via a pipe. When the command becomes a zombie, FMLI continues reading the pipe that the (daemon) child still has open. FMLI does not know if its grandchildren are going to be daemons or if they are going to write to the pipe. To preserve the ability of grandchildren to ouput to FMLI, the following fix must be placed in the script executed by the backquoted expression, to redirect the stdout of the daemon:

nohup my_daemon > /dev/null &