FE system

The 'feAppMenus' subsystem


FE = Freedom Environment

Poke this image to change font.

Poke off-image to change back.
Javascript is disabled. Please enable Javascript
in order to see image changes on 'mouse-overs'.

FE Home page > The FE Downloads page >

This 'feAppMenus' Download page

! Note !
Some text here may be touched up or revised occasionally
--- especially after a new release.
Some screenshots may be replaced someday,
by images with nicer, anti-aliased fonts.

< Go to the 'FE AppMenus' Download Link
and Instructions, below. >

( Skip the Introduction )


In 2009, I finally 'took the plunge' and migrated my mail, bookmarks, etc. from a (main) Microsoft Windows machine to a (main) Linux machine.

I have documented reasons why I went to Linux, along with install notes, on an Ubuntu Install notes page

I have outlined, on the 'FE Nautilus Scripts' download page and on the FE 'xpg' utility download page, how I came to develop some utilities that I decided to release on a subsystem-by-subsystem basis --- to make sure at least some of my utilities are made available to the public.

Since I am not getting any younger (pushing the big 7 oh), I put 'the pedal to the metal' to get this next subsystem release 'out the door' --- out my doorway to the Internet --- soon after the releases of 'FE Nautilus Scripts' and 'xpg'.

Together with this 'FE AppMenus' subsystem DOWNLOAD page, I have prepared an 'FE AppMenus subsystem' description page that discusses the features of that subsystem in quite a bit of detail.

The 'feAppMenus' description adds to the FE library of subsystem descriptions --- the previously released descriptions being

The 'feAppMenus' download file and install instructions are below.

For more details on install and 'preferences' options (after the installation files are put in place), see the 'feAppMenus' description page.

Or see the 'feAppMenus' help file --- called 'feAppMenus.hlp' --- in the 'helps' directory of the installation.

That file is shown via the 'Help' button on the 'feAppMenus' 'toolchest' GUI.

    (The FE 'xpg' text browser utility is used to QUICKLY show that plain-text help file.)

and Install Instructions :

The install file is a self-extracting shell script.

It would be nice if we could simply name it with a '.sh' suffix. But it appears that most web browsers (or, actually, web servers) will assume that it is an all-text file, when, in fact, it has a gzipped tar file appended to the script portion of the file.

When a web browser asks for the file from the web server, if the file has the '.sh' suffix, the file will be downloaded in 'ascii' mode instead of 'binary' mode. The binary data in the file (the gzipped tar stuff) gets corrupted.

As a workaround, the '.sh' file is provided with a suffix of '.sh.exe' --- in hopes that the web-browser/web-server combo will think the file is a 'binary' file and download it in a 'binary' mode that does not corrupt the file.

    This seems to work. The '.sh.exe' file downloaded fine for me, using the Seamonkey2 web browser on Ubuntu Linux --- on a little Acer netbook.

* feAppMenus *

Right click here, on the link to the '.sh.exe' file, and, in the popup menu of your web browser, choose to save this self-extracting shell script in a download directory on your machine. (Your web browser will offer an option such as 'Save Link Target As ...'.)


For good measure (that is, as an alternative), the install file is also provided with the suffix '.sh.tar'.

So if the '.sh.exe' file does not work for you (say, the web-server/web-browser 'dance' tries to do something 'funny' with files with a '.exe' suffix), right click here, on the '.sh.tar' file link, and, in the popup menu of your web browser, choose to save this self-extracting shell script in a download directory on your machine.

To see the quick version of installing 'feAppMenus', go to the brief SUMMARY section at the bottom of this web page.

To see a movie on how to install 'feAppMenus', click here. (Alternatively, right-click this link and save the movie file to local storage.)

OR, go to the FE Videos page to see the install videos for the several FE subsystems.

The install procedure for each subsystem is similar --- namely, prepare and run a self-extracting script, in 3 quick steps.

    The '2011oct05' release of 'feAppMenus' is a pretty mature release --- corresponding to a 0.8, say, release of systems using that kind of release numbering system.

    However, since the author has been the only user (known to the author) of the scripts (and 'chestdef' files) in the 2010 and early 2011 releases, the 'feAppMenus' system has not had the benefit of usage and feedback from lots of users. Hence, it would not be appropriate to call it a '1.0' release.

    Aiming for a 'mature' release :

    The 'AppMenus' FE subsystem installation has been set up so that the startup scripts of the many 'toolchests' within it will automatically figure out the install directory from the full name of the startup script being used to start these utilities.

    This auto-setting of the install directory should work even if one goes to an feAppMenus 'scripts' directory, in a terminal window, and starts a script via a command like './feAppMenus' or './appCats_chest.sh' --- for example, when testing changes to the 'chestdef' startup scripts --- or changes to the 'make_chest.tk' script that those scripts call to make the GUI 'toolchests'.

    In the terminal window, you will be able to see programmer-supplied debug messages and shell interpreter messages, including error messages that may be generated from changes that you may make to the installation files.

    I am trying to avoid having me (the installation files preparer) or the user hardcode the install directory name (fully-qualified) into the many possible startup scripts --- especially since there could be 30 or more startup scripts in the FE AppMenus subsystem.

    Another advantage of this strategy is that the FE subsystem would still work, even if the user renamed the install directory (from 'feAppMenus_yyyymmmdd' to 'feAppMenus', say) or moved it to another location.

      (The main requirement is that the 'flat', essentially one-level SUB-directory structure of the FE subsystem, and the subdirectory names and filenames, be preserved.)

The install steps, in detail :

Your home directory or the 'Desktop' directory of your home directory will do, as the download directory. BUT ...

    To keep an organized directory structure, you may find it better to make a directory named 'DOWNLOADS', for example, in your Home directory.

    Then save ALL your 'third party' application install files there, from then on.

    By 'third party', I mean applications that are NOT distributed via a monolithic package management system of your Linux/Unix system --- like the FE apps are not.

    Seamonkey2 (a Mozilla.org web browser, son of Netscape) is another example of such an app.

    In mid-2010, it was not available in the 'Ubuntu Software Center' nor via the 'Synaptic Package Manager'.

    I downloaded the Seamonkey2 Linux install file from the Seamonkey website into my '$HOME/DOWNLOADS' directory --- and I installed it into a '$HOME/apps' directory that I created for apps that I want to preserve during Linux upgrades.

    I preserve the apps simply by not overlaying my home directory (and by backing up my home directory as a precaution).

    Similarly, the FE subsystem self-extracting install scripts can be put in


    and most of the FE files will be installed in


    --- with a few more in


    as indicated below.

    So, the files for this FE subsystem will be in

    • '$HOME/apps'
    • '$HOME/.freedomenv'

    So all files of the FE subsystems are in your home directory.

    All the files get backed up if you backup your home directory.

    Furthermore, the files are preserved (not wiped out) if you preserve your home directory when you update your operating system.

Again, to see the quick version of installing the 'feAppMenus' subsystem, go to the brief SUMMARY section at the bottom of this web page.

Installation details follow.

Preparing the downloaded
'.sh' install file for execution :

First, rename the file --- remove the '.exe' or '.tar' suffix.

    If you are positioned at your download directory with the Nautilus file manager, simply right click on the install file, choose 'Rename' in the popup menu, and use the Backspace or Delete key to remove the last 4 characters from the filename.

    Alternatively, if you are in a terminal window, positioned at the download directory, you can use the 'mv' (move/rename) Linux/Unix command in a form like this :

    mv   whatever.sh.exe   whatever.sh

    When you download the self-extracting script file to your file system, it may lose its execute permissions. [This is a nice security feature, making it harder for people to run rogue programs on your computer.]

    You can make sure the '.sh' file is executable as follows.

    • Navigate to it in the Nautilus file-manager --- if you're not there already.

    • Right-click on it and choose 'Properties' at the bottom of the Nautilus options window that pops up.

    • Go to the 'Permissions' panel on that 'Properties' window and make sure the checkbox labelled 'Allow executing file as program' is turned on.

    Altnernatively, in a terminal window, when you are positioned in the directory in which you put the '.sh' install file, issue the 'chmod 755' command on the filename of the self-extracting script. The format :

    chmod   755   whatever.sh

Content of the '.sh' file :
(Skip to the next section to see
how to execute the install script.)

While you are in that terminal window, you can check out the script lines of the file by issuing the 'head -225' command against the file.

You will see about 222 lines of script text (lots of comment lines) --- and then some gobbledy-gook characters in the terminal window.

That gobbledy-gook is the starting contents of the gzipped tar file that contains the 'feAppMenus' installation files.

The self-extracting script is a combination of text lines and binary data.

If you try to view the install script with a text editor, like 'gedit', it will not view the file, because the editor detects the binary data and thinks it is dealing with a binary file.

The authors of 'gedit' do not allow you to try to display the file --- partly because 'lines' in (some) binary data files are thousands of bytes long.

    As an interesting note (at least I think so), the FE 'xpg' utility is not as finicky as 'gedit'. If a binary file is not too large (in some sense or another), 'xpg' WILL show the binary file.

    Of course, most of the bytes in the file show as gobbledy-gook characters in the 'xpg' text area. But you CAN read strings of human-readable text in the binary file.

    In particular, I tried 'xpg' on the 'feAppMeus' self-extracting script file. It brought that combined text-and-binary file up quickly with no complaints (error messages). I could see the text of the script at the top of the file.

    In fact, when I scrolled down to the part of the file where the binary data started, the 'xpg' window did not complain or go bye-bye --- even when I scrolled to the bottom of that binary data.

    Similarly, on some of the other FE self-extracting script files --- like the ones for the 'FE Nautilus Scripts' releases --- I have been able to scroll through the entire self-extracting script file, with 'xpg'.

How to execute the '.sh' install script :

If you are still in a terminal, positioned at the download directory that contains the self-extracting script file (after doing the 'mv' and 'chmod' commands on the '.sh' file, say), you could execute the '.sh' script right there via the command line.

Enter a command of the form


That is, type a dot and slash, then type (or 'mouse-paste') the '.sh' filename and press Enter.

You will see some output from the execution of the script, including

  • 'mkdir' commands that make the 'feAppMenus_yyyymmmdd' install directory, under $HOME/apps

  • the 'tail' command that is used to extract the gzipped tar file from the '.sh' file --- putting the '.tgz' file in the '/tmp' directory

  • output of the 'file' command applied to the extracted file --- confirming (hopefully) that the extracted file is indeed a 'gzip compressed data' file

  • the output of 'ls -l' on that extracted file --- to show the number of bytes in that gzipped tar file     (It should be 198,541 bytes for the 2011oct05 file.)

  • the output of 'tar ztvf' on the extracted '.tgz' file --- to show the 'table of contents' of the extracted file

      (The table of contents will simply be the directory names and filenames that make up the installation --- along with some file permissions information.)

  • a 'cd' command that sets up the 'working directory' of the install script at the 'feAppMenus' install directory, for execution of the following un-tar command

  • the output of 'tar zxvf' on the extracted '.tgz' file, which gunzips the file into a tar file and then extracts the contents of that tar file into the install directory

      (The output of 'tar zxvf' will look a lot like the 'table of contents' output, the output of 'tar ztvf' --- but without the file permissions info.)

      (The 't' in the tar command stands for table of contents, the 'x' for extract.)

  • the 'mkdir' commands that make a '.freedomenv' directory in your home directory --- and subdirectories named 'common' and 'feAppMenus' under that directory --- if they did not exist already.

  • two 'cp' commands that copy the 'set_FEDIR.shi' and 'set_feDIR.tki' shell 'include' files from the installation directories 'includes_sh' and 'includes_tk', respectively, to the '$HOME/.freedomenv/common/' and '$HOME/.freedomenv/feAppMenus/' directories.

      (The 'set_FEDIR.shi' shell 'include' file is the code mentioned above, that figures out the install directory from the name of the FE script being called --- that name being available in the $0 variable of the calling script. More than you wanted, or needed, to know, eh?)

      (The 'set_feDIR.tki' Tk script 'include' file does a similar thing for the '.tk' scripts of the FE subsystems.)

  • the 'mkdir' command that makes a 'bin' directory in the $HOME/apps directory, if a 'bin' directory did not exist already

  • a 'link' command that makes a link from file 'feAppMenus' in the 'bin' directory to the 'feAppMenus' startup script in the



Some of the many ways to implement that 'feAppMenus' startup script are described further below.

Note that the above description amounts to 'full-disclosure' of the install process for the 'feAppMenus' subsystem.

(More than you wanted to know, eh?
But it helps me remember how the install works.)

An alternative to running the
install script by typing its name
in a terminal-shell window
(namely, a GUI mouse-click method) :

If you are positioned at the '.sh' install script (that is, positioned in your download directory) with a GUI file manager like Nautilus, you could double-click on the '.sh' file --- after making sure that it has execute permission, as described above --- and choose the option to 'Run in a terminal'.

You will see the messages described above appearing in the terminal that pops up.

    If the terminal window just flashes and does not stay open (or the installation goes so fast that the terminal window does not even flash), navigate to the '$HOME/apps' directory, and see if the 'feAppMenus_yyyymmmdd' directory was created.

    Check whether the 'scripts' subdirectory of that directory was created, containing the 'feAppMenus' script.

    And check the 'tkGUIs' subdirectory of the install directory, which should contain the 'make_chest.tk' file.

    If those directories and files exist, then the installation probably went OK.

Where the application files 'land' :
(via a safer-than-most install strategy)

When the self-extracting shell script file executes, it automatically puts a set of directories in a


directory --- that is, under your home directory --- where yyyymmmdd represents a release date.


Note that you do not have to change to 'root' to do the install.

In fact, I never like having to switch to 'root' to do an install.

    When I have to supply the root password to do an install, I am being put in the position of having to trust the people who put the install package together that they are not going to use that all powerful permission to do serious damage to the root-owned directories and files on my machine.

    And I am trusting that the installation program is NOT going to install key-loggers or Linux/Unix viruses/trojan-horses on my machine, hidden in that massive directory structure.

    Or, 'they' could install a 'hidden' program that sends data to an organization (or person), over the Internet, or do some other useless-to-me thing, whenever their program is 'triggered', hidden among all those directories (and when I have my connection to the Internet on).

      [ I, and my wife, have been a victim of these several things on MS Windows. I now setup separate 'admin' and 'user' accounts on MS Windows, similar to 'root' and 'user' on Linux/Unix. ]

    Too much software involves nuisance processing, if not outright criminal-intent processing.

    Do you hear that Microsoft, Google, and a large number of software vendors and computer makers (HP, Dell, ...)?

    Cut the nonsense out in software installations ---- including pre-installed software!

    At least prompt us, before taking liberties with our computers.

    For example, let us decide whether we want your programs to start up as part of our computer's boot up process.

    Maybe we don't want your 'stuff' shoved in our faces every time we log on --- or every time we start up an app in which your (never-going-to-be-used-by-me) stuff has been included as an intrusive plugin.

    Hear that, Mozilla Firefox and Google and computer makers??

So rest easy. This install does not require you to open yourself to damage like mangling of your root-owned directories --- or commandeering of root-owned processes.

And nothing is added to your computer's startup processes.

YOU are the one who decides when the 'feAppMenu' components are run.

For some simplicity, this install does not ask for an install directory. It simply makes an 'apps' directory in your home directory, if you do not have one.

And it makes a directory called 'feAppMenus_yyyymmmdd' under the 'apps' directory of your home directory:


    Having apps like this in your home directory can be a real boon at Linux OS upgrade time.

    If you follow the procedure of preserving your home directory (as a separate disk partition) during a Linux OS upgrade, then you do not have to re-install the FE 'AppMenus' subsystem installation files, after your Linux upgrade.

    Since these installation files are not in a system directory like '/usr', they will not be wiped out in a Linux system upgrade.

    And even if you allow the Linux OS upgrade to wipe out your home directory, if you simply drag your 'apps' directory onto a USB stick (or some other storage device) before the Linux upgrade, you can simply drag it back to your home directory after the Linux upgrade is complete.

Size of the installation :

After installation, the 'feAppMenus' files occupy less than 1 Megabyte of space.

The 2011oct05 self-extracting install script is only 206,228 bytes in size.

About 194 KB (96%) of that is the compressed installation files.

The installation files, after extraction from the compressed file that was appended to the self-extracting install script, expand to much less than a megabyte in size.

These are miniscule sizes compared to applications like GIMP or Firefox, which are typically more than 50 Megabytes in size.

I contend that you can get a lot of bang, for zero bucks, from this small set of small files.

The sub-directories of the FE 'AppMenus' install :

The install directories go under that 'feAppMenus_yyyymmmdd' directory --- fullname $HOME/apps/feAppMenus_yyyymmmdd.

It is a simple, almost-'flat' directory structure --- only one level of directories (except for the 'images' directory --- which contains 'bullets' and 'icons' directories).

The directory names are

  • chestdef_scripts
  • chestdefs
  • helps
  • images   (with 'bullets' and 'icons' subdirectories)
  • includes_sh
  • includes_tk
  • scripts
  • tkGUIs

With the exception of the 'chestdef_scripts' and 'chestdefs' directories (which contain about 30 files each), there are less than 10 files in each directory.

The main file for the user to be aware of is the main startup script 'feAppMenus' in the 'scripts' directory.

Running 'feAppMenus' :

If you want to make an 'alias' for the 'feAppMenus' startup script in your '.bashrc' or '.bash_aliases' file, you can use an 'alias' statement like

alias feam="$HOME/apps/bin/feAppMenus"

You can also make a desktop icon for 'feAppMenus', if you wish --- in the usual way for your desktop environment (say Gnome or KDE).

Gnome :

    For Gnome 2, you can right-click on the desktop and choose 'Create Launcher ...'.

    In the 'Create Launcher' window that pops up, in the 'Name:' field enter a name like 'feAppMenus', and in the 'Command:' field, enter the name


    which is a link to the startup script for the 'feAppMenus' system.

      Note that there is a 'Browse...' option, so you do not have to key in the fully-qualified name of the startup script.

      You can simply navigate to the 'apps/bin' directory of your home directory, and click on the 'feAppMenus' filename.

    Then click 'OK'.

      (If you want to use a different icon from the standard Gnome launcher icon --- a platform on a spring --- click on that launcher icon in the upper left of the 'Create Launcher' window and choose a different icon, before you press OK.)


    For KDE, you can right-click on the desktop and choose 'CreateNew -> Link to Application'.

    In the 'General' panel that pops up, fill in a short name, like 'feAppMenus', which will appear on the screen under your desktop icon.

    (You can click on the default gear-icon in the panel, and choose a different icon from a large array of icons.)

    Then click on the 'Application' panel and click on the 'Browse' button to find the 'feAppMenu' script (a link to that script) that is to be associated with the icon :

    $HOME/apps/bin/feAppMenus .

After you have your desktop icon (for Gnome, KDE, or whatever) :

    You can click on the 'feAppMenus' icon to bring up the starting 'FE App Menus' chest-of-drawers --- which looks like the image at the top of this web page.

You can also make feAppMenus available via a 'quick-launch' icon on the Gnome2 panel across the top of the desktop.

Simply right-click on the top Gnome panel and use 'Add to Panel ...'. I leave the rest of the steps as an exercise. The steps are similar to creating an icon on the Gnome 2 desktop.

SUMMARY of the Install Steps :

The detailed install description above may sound like a lot, but the install takes only a few steps after downloading the self-extracting install file to your computer :

  • rename the file to remove the '.exe' or '.tar' suffix, leaving the '.sh' suffix intact

  • make sure the '.sh' file has execute permission

  • double-click on the '.sh' file to execute it
    (or right-click and Open)

and all three of these steps can be done in Nautilus or some other capable GUI file manager.

That is, the install can be done with mostly mouse clicks --- rather than using the command line.

The only keyboard use would be the Backspace or Delete key to remove the suffix.

When you double-click on the '.sh' self-extracting install file, there is no need for a progress bar.

The install occurs in a fraction of a second.

To see a movie on how to install 'feAppMenus', click here.

(Alternatively, right-click on this link and save the movie file to local storage.)

OR, go to the FE Videos page to see the install videos for the several FE subsystems.

The install procedure for each subsystem is similar --- namely, prepare and run a self-extracting script, in 3 quick steps.

For more info on the nature and features of the 'feAppMenus' subsystem, and 'licensing' info, please see the FE 'AppMenus' subsystem description page.

Or, see the 'feAppMenus.hlp' text file in the 'helps' directory of the 'feAppMenus' installation.

That file is shown via the 'Help' button at the bottom of each of the 'feAppMenus' toolchest GUIs.

(setting a desktop icon or command alias)

In the releases after 2011may01, the 'feAppMenus' script will be accessible via either a 'link' with the pathname


or via the 'actual' pathname

$HOME/apps/feAppMenus_yyyymmmdd/ scripts/feAppMenus

where yyyymmmdd represents a release date and $HOME represents your (the installer's) home directory.

You can proceed to set up

  • a desktop icon in your desktop environment

  • a Gnome2 or MATE upper-panel quick-launch icon
    (or other desktops' equivalent)

  • a command alias

by using either of these types of pathnames.

Using the first type (the short name) means you do not have to deal with changing 'yyyymmmdd' release names.

For details on how to do these setups, see the section called Running 'feAppMenus' above.

When there is a NEW release of 'feAppMenus' to install, you can simply proceed to do the install. Then make sure the link file


has been changed to point to the new 'feAppMenus' script, in the new yyyymmmdd directory --- the full file pathname being

$HOME/apps/feAppMenus_yyyymmmdd/ scripts/feAppMenus

For example, you could use the 'ls -l' command to check that the 'soft-link' '$HOME/apps/bin/feAppMenus' is pointing to that name. Example:

ls -l $HOME/apps/bin/feAppMenus


If I install a new release of the 'FE AppMenus' system on one of my computers, here is what I do. You may want to use this technique if you download a new release.

Assume that we have just installed the new release as described above.

It should not have 'collided' with a previous release, since each release directory name is different, say


and older release


In addition, there is the 'script soft links' directory

  • $HOME/apps/bin

The new install method (after 2011 May) makes a link from the 'feAppMenus' startup script to a 'release-ID-independent' file,


where $HOME represents your home directory name.

By using that soft-link, instead of a fully-qualified name like

$HOME/apps/feAppMenus_yyyymmmdd/ scripts/feAppmenus

we do not have to remember to do steps like the following.

  • change the script name for the desktop icon (or quick-launch panel icon) that you use to start the feAppMenus system.

  • change the alias that you set for the feAppMenus startup command

With the new install method (after 2011May01), I can simply use

alias feam="$HOME/apps/bin/feAppMenus"

and not have to change the alias with each new release.

Similarly, for a Gnome2 (or MATE) Desktop icon, say you right-click on the 'feAppMenus' desktop icon and, in the popup menu that appears, choose 'Properties' at the bottom.

In the 'feAppMenus Properties' panel that appears, there is a 'Basic' sub-panel with a 'Command:' entry field.

You can simply use


in the 'Command:' entry field and not have to change the command name with each new release.

If you added 'feAppMenus' as a quick-launch icon in the Gnome2 (or MATE) panel at the top of the screen (the 'top panel'), you could use the same technique to avoid having to update the properties of that icon with new releases of feAppMenus.

We are now ready to use the NEW installation, via desktop (or 'top panel') icon or via command alias.

Some previous releases

Just in case there is some deficiency in the latest release of the 'feAppMenus' system, here are some previous install files --- self-extracting scripts.

You can right-click on any of these links and use 'Save Link Target As ...' (or the equivalent) to save the file in your downloads directory.

Then use the 3 simple 'Summary' steps described above to install the (older) 'feAppMenus' system.

FE . . . . The Dr. Feelgood of Software.
( cures for many ailments )

Bottom of this
FE 'AppMenus' subsystem Download page.

FE = Freedom Environment

To return to a previously visited web page, click on the Back button of your web browser a sufficient number of times. OR, use the History-list option of your web browser.
OR ...

< Go to Top of Page, above. >

Page history

Page was created 2010 Sep 07.

Page was changed 2014 May 01.

Page was changed 2018 Aug 15.
(Added css and javascript to try to handle text-size for smartphones, esp. in portrait orientation.)

Page was changed 2019 Jun 10.
(Specified image widths in percents to size the images according to width of the browser window.)