forthebadge forthebadge Gem Version

This gem was last updated on the 11.04.2024 ( notation), at 15:40:51 o'clock.

About the environment_information gem

This project is called EnvironmentInformation (environment information).

Its primary goal is to gather information about the environment that ruby is presently running on - in other words, the host system and its capabilities.

This gathered information can then be shown to the user on the commandline, or via a ruby-gtk widget, or via a sinatra-interface on the www. The main focus for this project is on the commandline-usage, though. For example, the file at bin/fenvi, which is part of this project, can be used to quickly show all versions of different programs on the target computer system.

To provide a short overview how this may look, taken on the KDE konsole and bash, have a look at the following image on a black background:

Invocation example:


Generated output (only showing the first five entries):

atk       2.32.0      
bash      5.0.0       
binutils  2.32        
bison     3.4.1       
bzip2     1.0.8

Do note that by default colours will be used, so atk may appear in green, and the associated version will be shown in a blue colour (actually steelblue, by default). If you do not want to use colours, you can disable them for the current invocation run, like in this way:

envi --no-colours
envi --no-colors
envi --disable-colours
envi --disable-colors

Take note that you can tweak most of the behaviour of EnvironmentInformation via specific commandline flags.

To obtain a listing of the available options, you can invoke the main executable called envi (bin/envi) via:

envi --help

What is meant with the term environment?


The term environment, within the context of the environment_information gem, is the (software) environment that can be discovered by the ruby version found within the $PATH variable, on the given computer system at hand.

Recall that there may be situations where there is more than one version of ruby installed, on a given computer system, in different locations - e. g. /usr/bin/ versus /usr/local/bin/ versus /home/ or /opt/ setups. Thus, $PATH should be kept in mind in the event that you have multiple ruby versions on the given computer system at hand, as the incorrect ruby version may be discovered, in certain situations. Furthermore keep also in mind that multiple binaries may exist at the target system, e. g. bzip at /bin but also at /usr/bin or elsewhere.

Thus, I recommend to always ensure that $PATH is correctly set on the target machine. First come, first serve, so it is a good advice to keep PATH clean, and 'logical'.

At any rate, the information that will be gathered by the EnvironmentInformation project may also be stored more persistently in a standalone .html file, if you so desire to. This .html file could then be used for static display of the information (but may become quickly outdated, so keep this in mind as well).

The Environment information project may include any of the following as its output:

  • The GCC Version in use on the given computer host system.
  • The (Linux) Kernel in use.
  • Which Ruby Version is used.
  • Which Rubygem version is used.
  • The path to the rubygem directory.
  • What the Host CPU Model is (on Linux at the least).
  • What is the the GTK, GLIB and gdk-pixbuf version, respectively.
  • Which dhcpcd version is available.
  • What Xorg components are available, such as libX11, libxcm, libxp, libxau.

And so on and so forth - and a lot more.

Why are there many different ways to query the version of a locally installed programs?

The main reason as to why different ways have to be supported is because different software is installed in different ways, making use of information in, well - different ways.

For example: not every software comes with a .pc file, so we can not rely on .pc files uniformly for every installed program. Sometines no commandline-binary is provided, so the --version flag can not be used either; and if no .pc file exists for a given program, we may have to query the name of the .so files (on a linux system), and infer the version from that.

The main class in this project is class EnvironmentInformation, which resides under module EnvironmentInformation.

The actual query of the version is done on the toplevel, so for example:


would display the version of GCC at hand.

The code there will typically try to query .pc files via pkg-config, but may sometimes try to infer the version from the .so file at hand, and sometimes it will try to run the system binary (or an associated binary) with a -V or -v or --version flag, and parse that output.

Typically the components that will be displayed, are handled by code that resides in the file display.rb. The instance variable @display_these_components keeps track of which components will be displayed, so that information about these disparate programs and components can be tracked.

There are in general only two entries that are of interest to class EnvironmentInformation here:

(a) The name of the program.
(b) The associated specific program version, as String, of that program.

So, for example, we may see a key→value association like:

ruby => 2.5.1

If you need a String representation of the dataset then you can use the method .string? or .stringified, which will give you a String instead. The .stringified method exists primarily due to convenience alone, for people who don't want to do much conversion on their own and just be done with it).

There are various additional helper methods, such as a reader-method called .main_string? or .string (they are equivalent to one another, aka one is an alias).

This should allow you to re-use the information from this gem in other projects, such as if you wish to get the String of all available programs, and display this on a webpage. Or, alternatively, just use a toplevel method call, such as:


How to make use of the project

There are, essentially, three recommended ways how to use the main class of this project:


From the commandline, just call envi directly and pass in specific commands to this executable (optionally).

For instance: invoke the envi-executable with the argument "ALL" or "--all" and the class will show all information that could be found. This is personally my favourite way how to invoke this class. I even combine it with "FALL" or "RALL" (--really-all or --really-everything), which will also compare the programs versions that are available, if the RBT project is available (gem install rbt), and then inform me as to which programs are not up-to-date on the local computer system at hand. This then allows me to compile/install these programs. This idea came to be because I liked the Linux from Scratch project a lot, and there you may often have to upgrade programs.

Note that --really-everything may be hard to type. I suggest to use an alias in that case, or just the upcased variant FALL or RALL. See the file menu.rb for more aliases to that.


The other use case is the "embedded use", i.e. for use in a .cgi page or perhaps for a ruby-on-rails webpage.

An example for the former follows:

_ = # The symbol allows us to prepare the class first.
_.set_n_tokens 58
_.disable_colours # <- Recommended, since the colours are thought for the commandline only.
_.dont_show_ruby_stuff # <- If you do not need information about ruby.

But you do not have to instantiate a new object; you can simply use another toplevel API, since as of September 2019.


For example, to query the glibc version, you could use this:

EnvironmentInformation.glibc? # => "2.29"

Which variant to prefer? This depends on your use case. If you need more flexibility then you should use the class; if you only need the version-string, number 3 may be best as it is the simplest.

You can also display some additional information, such as the version of GTK, Glib, Atk and Pango, by passing in "f" or "full" or "--full" on the commandline, without the quotation marks.

See the help section to this this script, which can be invoked by passing "help" or "--help" as argument to envi.

You can also pass this information through a block (as a Hash inside of that block), if you would like to:

_ = {{
  n_tokens: 58,
  use_colours: no,
  be_silent: true
  show_ruby_stuff: no

Do note that the following API also works, primarily due to convenience - you can try it in irb, of course:

require 'environment_information'


The executable version for class EnvironmentInformation is called envi. It will reside under bin/envi of this gem.

So you can invoke the script by typing "envi" from the commandline, without the quotes; if you installed it as a gem into a prefix other than /usr, it may be that the bin/ directory resides only in that gem, though. Setting an alias may help in this case.

Colours used by the EnvironmentInformation project

Support for colours in the environment_information gem is available through the following file:


Which, in turn, taps into the colours gem.

In theory other colour-related gems could be used as well, but this may require someone to write support-code for this, in regards to other gems.

Presently (August 2020; September 2022) this project only uses the colours gem (gem install colours), though.

You can specifically disable the use of colours for the current invocation run, for whatever the reasons, from the commandline, via either:

envi --disable-colours
envi --disable-colors
envi --nocolours
envi --nocolors
envi --no-colours

envi --really-all --disable-colours
envi --really-all --disable-colors

envi --all --disable-colours
envi --all --disable-colors

Note that envi refers to bin/envi, which is distributed as part of this gem.

Both UK and US spelling should work fine in regards to colours/colors; use whichever variant you prefer. As I was taught the UK spelling in school, I prefer the UK spelling in general.

Internally, the @use_colours variable is used to determine whether colours are to be used for the main class of this gem.

You can query the current setting via the following toplevel method (in ruby):


You can also query whether colours are used via envi as well (the bin/envi file) from the commandline, via:

envi --use-colours?
envi --use-colors?

The default assumption for commandline use of this gem is that the user uses a black/dark background in the terminal; and white colour for the text, or at the least some light/bright colour.

Not every uses uses a black background, though. In these cases the default colours used by the environment_gem are not optimal.

Because this may be a concern for some users, support was added to the environment_information gem to allow them to use different colours if they want to. So, not only can you disable colours altogether, but you can also fine-tune them to your liking, if you want to.

The file that will handle this is a .yml file and it normally resides at:


Currently (September 2022) it only covers two values - the colour for the left-hand display, and the colour for the right-hand display. This refers to the table-layout that you can see when you use the environment_gem (bin/envi) on the commandline. To the left side one will typically see the name of the program; to the right side the version of that program is shown. The two colour names used in the .yml file will determine this. You can change the names there; I use HTML colour names.

If the .yml file can not be found or is missing then the two default colours in use will be forestgreen (for the left side) and steelblue (for the right side).

A third entry exists called program_not_found, defaulting to lightslategrey. Most users probably may not need to change this, but in the event that you would like to, you can change it of course. In principle commandline support could be added to change the colours on an ad-hoc basis during a run of bin/envi, but for now I'll leave it how it is. If someone wants to be able to fine-tune the colours on the commandline, without wanting to modify the .yml file, let me know; I'll add support in this case then.

Note that you can combine this in various means.

For instance, to show information about EVERY program, and use a compact display without any newlines, while also disabling colours, use the following:

envi --rall --oneliner --disable-colours

The following image shows how this looks:

Yes, this is not very elegant and hard(er) to read, but imagine if you work on Linux runlevel 3, without a GUI. In this case this can be convenient to have in one terminal as you work.


There is an executable at bin/fast_envi, as part of this gem, which complements the executable at bin/envi. envi is simply an abbreviation to "environment information"; and fenvi stands for "fast environment information". That is exactly the primary use case for fenvi - it shall allow for maximum speed, without "maximal usability". The latter means that fenvi will not offer as much customization/flexibility as envi does. In fact - the EnvironmentInformation project was rewritten in September 2019 precisely to make the whole project much more performant and faster; the old code was too slow, for various reasons. (Note: I am using an alias called fenvi that refers to fenvi; the official name of the executable is fast_envi though.)

Nonetheless, fenvi also supports some commandline flags.

For example, if you wish to only show the registered xorg components and their corresponding versions, then you can issue the following flag:

fenvi --xorg

This would show all xorg components.

fenvi --help

Would show the help options. Right now this is limited to just two options (or perhaps a bit more than that in the long run).

Another option is:

fenvi --compare-to-program-versions

This can be used to quickly compare the program versions of the local computer system. Note that this functionality depends on the RBT gem:

gem install rbt

Determining which programs should be shown on your own

You can decide to only show the version of some programs, via the commandline specifically.

For example, say that you wish to see only the versions of ruby, python and perl, then you could try the following:

envi --use-these-programs=ruby,python,perl

If you wish to display the local versions of bash, binutils and bison, then you can try this:

envi --use-these-programs=bash,binutils,bison

If you wish to show all components that may be important for the LFS (linux from scratch) project then you can use this:

envi --use-these-programs=bash,binutils,bison,flex,bzip2,coreutils,diffutils,find,awk,gcc,grep,gzip,linux,make,m4,patch,perl,python,sed,tar,texinfo,xz

Since that is a bit annoying to type (it's quite long), you can also use the fake-symbol :lfs for this instead:

envi --use-these-programs=:lfs

Or, even simpler than that:

envi --lfs

In fact, this functionality has been added precisely to avoid using a shell script, such as this one:

The name fake-symbol is given because via the commandline you can only pass e. g. a String, not a Symbol, as bash does not know what a Symbol is. So if a string has a leading : then the EnvironmentInformation project will assume that the user wanted to convey a special meaning.

If you do not wish to save any local file then invoke EnvironmentInformation in this way:

envi --lfs --no-save

If you wish to show the local version of openssl as well, try adding this commandline flag:

envi --openssl

xorg components

To display the registered xorg components, you could use any of the following commandline flags:

envi --xorg-components
envi --xorg

Do note that not necessarily every xorg component is registered, but most of the xorg-components should be covered by now.

Reading from a local file

The EnvironmentInformation project can read from a local file containing the programs whose version you would like to show, on the commandline.

The commandline invocation goes like this:

envi --read-from-this-file=/Depot/j/
envi --file=/Depot/j/
envi --input-from=/Depot/j/

The reason as to why this functionality has been made available is so that people can use their own custom input to the main class of this gem, if they would like to.

A requirement for this to work is that there is a corresponding component that can query the version of a program. I am open for suggestions what to add, if anything is missing, as well as including a more generic way to make a query. Either way this depends on others to make suggestions.

Sorting the components alphabetically

You can display the components in an alphabetical manner, if you would like to, through this:

envi --sort-alphabetically

Sinatra interface

Since as of May 2019 there is now a small sinatra "interface" available.

To start it, try:

envi --sinatra

In order for this to work, you need to have sinatra installed, such as via this way:

gem install sinatra


gem install sinatra --user-install # into the home directory

It is not a mandatory dependency for this gem, so it is not registered to be a hard dependency in the .gemspec file.

The science cluster

There are also a few science-related applications, such as for hmmer or relion. To query their versions specifically you can issue:

envi --science

Show the URL of every registered program

You can, if you like to, show the remote URLs to the different programs, if you have the RBT project installed (gem install rbt).

Then, you should be able to do the following:

envi --everything --show-remote-url

This variant will not only display the local programs found, but will additionally also show the remote URLs on the commandline, on the right hand side, to the corresponding program at hand.

Only display the operating system in use

If you are only interested in seeing the operating system, try this commandline flag:

envi --os?

Showing additional programs on an ad-hoc basis

You can also show additional individual components via the --additional flag, like this:

envi --additional=php,python,perl

This would display the local versions of the installed programs php, python and perl. You can add any additional program as you see fit there, separated via ',' character - this will, however had, only work if that program has been registered in the environment_information gem.

Note that since as of September 2019 you can also add the name of the component directly. For example, to show the version of bash, you can invoke envi like this:

envi --bash

To also show php and python, you can do this:

envi --bash --php --python

Use whichever variant you prefer - the choices are up to the user.

Ruby-gtk bindings

A small gtk-widget exists, which can be started via either of:

envi --gui
envi --gtk

Note that this requires the ruby-gtk package, in particular gtk2, and possibly also the gem called gtk_paradise.

Installing these could be done through the following commandline invocations:

gem install gtk2
gem install gtk3
gem install gtk_paradise

You may need the "devel" packages (.h files) for this to work.

The gtk widget is really just extremely simple, and thus not too terribly useful, since it lacks functionality; I only wanted to be able to embed this information into other ruby-gtk applications. At some point in the future, the functionality may be extended - but for the time being, it will remain simple. Simple is beautiful, too.

Presently (September 2019) the gtk-bindings in the environment_information project only support ruby-gtk2, but in the future I may switch to ruby-gtk3 - or at the least offer means for the user to decide which variant is to be used.

No changelog entries any longer

In the past, changes to this project were listed specifically, together with the date - a short changelog.

However had, most users are probably more interested in the options and features that are supported as-is; the features that are available right now. Seeing every unimportant change made in the long forgotten past, is not that useful for most users. Additionally, for small projects, a changelog is not really that worthwhile to be had to begin with.

So, I have abandoned the concept of a changelog for this project. Do note that if there is something noteworthy that has been changed, it will be mentioned and documented here in this file ( anyway.

How to add new components/entries to this project

The file environment_information/constants/array_tracked_components.rb keeps track over all available entries.

The method called return_default_programs_on_a_linux_computer, defined in the file environment_information/base/misc.rb, will add all the entries that are, assumingly, useful on a linux computer by default.

If you want to change the entries, or add new ones, look there first. If you wish to register a new program, you have to add it onto the main Array (in the constants.rb file) first.

You will also have to add a method that does the actual query part for the program version at hand, within the environment_information/individual_components/ subdirectory.

It may be simplest to just copy one of those .rb files, by giving it the same name as the program you wish to see displayed. You will then have to change the content of that method too, in that new file, but this is quite trivial and takes at maximum five minutes (for those who have not seen it before; it takes significantly less time for those who already know what to change there). Entries that come with pkg-config .pc files are even simpler to add - this is much easier than manually parsing --version flags.

In the future I may switch to a yaml file rather than hardcode the entries in .rb directly, but for the time being, I will stick to the method described above.

Short display variant

If you only wish to quickly view the most important information about the local computer system, then you can use the following variant:

envi --short


Note that the EnvironmentInformation project has to sometimes guess how to obtain the necessary information, in order to determine which program is installed. For example, for programs such as readline there is no trivial way to determine which version is used, to EnvironmentInformation will attempt to read the .so files, and determine the version from the .so files. This may fail, depending on the setup of the host computer.

In general, the two best ways to determine the version of programs are via a --version flag or simply by using pkg-config to query the .pc file of the package. But this is not available for all programs, so ultimately EnvironmentInformation may not display completely accurate information on all given computer systems.

Clearing the old dataset

Via --clear on the commandline you can remove all old entries. This commandline flag thus resets class EnvironmentInformation to a totally clean, fresh state. Internally the method .reset() will be called on class EnvironmentInformation.

This allows you to show only one component, or a few components, for example. The following example demonstrates this.

Say that you wish to show only python and php, thus two programs only. Then you can use the following flag to achieve this, in this order:

envi --clear --python --php

The order is important because --clear will clear at the moment it occurs in ARGV, which holds the commandline-arguments issued on the commandline by the user.

Which packages will be checked by default?

The following provides a list of packages that are presently, in October of 2019, tracked.

In the past I did manually copy/paste the following listing, but since as of 15th of October 2019, the list is autogenerated via a macro.

This listing can be seen in the file:


These are the following programs:


You can also display these programs dynamically, such as through the following API:

require 'environment_information'

pp EnvironmentInformation.tracked_programs?

Note that since as of March 2019, environment_information will also attempt to find out the installed version for gmp, mpfr and mpc. This may fail, though, and will be silently ignored in these cases (at least for the time being).

You can use the following method to display a list of all programs that are registered, from the commandline:

envi --registered-components?

This will show every registered (and thus, available) component of this project.

As of February 2020, this project tracks at the least 105 different programs. More entries will be added in the future, but the primary focus will be on a Linux from Scratch / Beyond Linux from Scratch setup, so expect those programs that are installed first, to be added next, too.

Querying the components that will be shown

You can query the components that will be shown, by issuing one of the following commands:

envi --show-components?
envi --show-components

Note that this works exclusively, meaning that if you use this commandline switch, then you will ONLY get a query of the components that are available.

Replaying the information

Normally showing all information when issuing envi --RALL can take quite some time; on my computer system 18 seconds, before the rewrite in February 2020.

The reason as to why it takes that long is mostly because many different files have to be queried; their --version flag has to be called or their .pc file has to be checked, but most importantly querying data from the RBT project currently takes way too long. This is not an ideal situation, as nobody wants to wait.

Waiting 18 seconds is simply too long, though, but until that part in RBT is improved, I have added a --replay functionality for class EnvironmentInformation (via the commandline).

What this functionality does is to take an available (existing) .yml file that holds the information from the last invocation run, and then proceeds to display this information on the commandline to the user. This will evidently be much faster, since the information has already been stored before in a prior run.

This change required that the environment information project will also generate a .yml file by default.

Note that this functionality is not yet complete; I will extend this at a later time (written this part here as of December 2019).

You can disable saving into this .yml file via:

envi --no-yaml-file

To invoke the replay functionality, do:

envi --replay

Avoid the creation of local files

By default, the main class in this project may generate a few local files. This may not always be wanted, or possible (e. g. in a read-only filesystem), so an option has to exist that disables this functionality.

That option is called --no-save and can be used like this:

envi --lfs --no-save

Using another prefix

By default, the environment_information project will assume that the main prefix is / or /usr, respectively. In other words, it will assume that, for example, the binary called "bison" will reside at /usr/bin/bison. To be more correct, it will make use of the PATH environment variable, but for most users this will list /usr/bin/ first.

That way "bison --version" should work and be the same as "/usr/bin/bison --version".

For pkg-config .pc files, the main target will usually then be at /usr/lib/pkgconfig/.

Note that the above is not always a correct assumption. For example, the GoboLinux approach uses the /Programs/ hierarchy instead (but it also keeps legacy symlinks, so in fact GoboLinux works just like any other linux distribution too).

On my home setup, I tend to use /home/Programs/ since some time - mostly because I tend to relocate /home/ in general or may keep it on a separate partition.

For these latter use cases we require another way to quickly list all versions of different programs. On 14.01.2020 support for this has been (partially) added.

Invoke this like so:

envi --work-on-programs-directory-only

Note that this would use /home/Programs/ right now, which is hardcoded - and thus not flexible.

I am aware of this limitation, so expect more code changes in the future to extend this functionality.

One key idea for this is to set up /home/Programs/Toolchain/ and have that one work reliably to cross-compile different architectures, libc libraries and so forth. But for now, this subsection is a stub.

Rationale as to why some programs may work and some may not

Querying the specific version installed on a given computer system can be tricky. If a .pc file is available (pkg-config) then querying the version is quite trivial. If a binary is available then often --version or -V will work. But sometimes there is no binary, and no .pc file either. So what to do in such a case?

This is not simple to answer, since it may depend on the program at hand.

It may be possible to infer the proper version from the library at hand e. g. /usr/lib/ Here we could assume that the version will be 4.8.2, but this is not necessarily guaranteed to work, either.

In the past, before the rewrite of this project in February 2020, the environment_information project had used code that would check for such conditions - for example, for readline, and look for specific .so files under /usr/lib/ or elsewhere.

But the resulting code that had to be written for this, was not very elegant, and takes about 10-20 lines of code for checking this, including fall-backs, for each program that does not conform to --version or a .pc file. I am no longer sure whether it is worth to add that code, since it also may have to be maintained, and is not always perfect nor does it always work, depending on the computer system at hand. So, past this point, environment_information is not doing its best to query the version for all programs - it will try pkg-config and --version or -V in most cases, and if that fails then the environment_information project will assume that the program at hand is not installed.

This may be a false negative, but to me it appears to be better in the long run, in regards to maintainability of the whole project. After all one reason for the rewrite in 2020 was to simplify the whole project, and this objective has been achieved - all the commands are now stored in yaml files, and that is so much simpler to handle than the corresponding ruby methods that were used before that.

Adding new entries to EnvironmentInformation

New entries can be added into the following yaml file:


The two most commonly used variants there are version, for *bin/foo --version invocations, and pkgconfig, for querying pkg-config .pc files. However had, many programs make use of different invocation variants, don't come with a .pc file, and have no binaries. Querying the correct version of such files is difficult since there is no standard. This is a reason why the code has to handle these cases.

But in principle, adding a new entry is as simple as adding a new line into that .yml file (and registering that component in a second .yml file).

The toplevel main hash

EnvironmentInformation tries to store the information that it has collected into a hash, which can be accessed like this quickly:


By default this hash is empty, so you have to fill it up first, if you want to do so, via the following method:


hash = EnvironmentInformation.hash? # ← and here you can query it

The hash can then be used as basis for reporting at a later time, or replaying that information via the --replay commandline switch to the executable.

Dependencies of the EnvironmentInformation project

The sole dependency for the environment_information gem is on the colours gem.

Up until the beginning of March 2020, the EnvironmentInformation project also depended on the opn gem. However had, I noticed that in a restricted environment installation of gems can be difficult, so I made opn optional. If you have it installed then EnvironmentInformation will still try to make use of the Opn namespace; and if it is not installed then EnvironmentInformation will simply skip Opn completely.

Rationale behind the different queries

As was already explained, different programs require different ways to determine which version is installed. Some projects would allow more than one way, such as the --version flag, but also querying .pc files. Ruby, for example, supports both --version, and comes with a .pc file (if you compiled it from source, at the least).

So, which way to choose?

In my opinion, .pc files are better than --version, for at the least two reasons:

  • The resulting code to handle this is much simpler. .pc files are quite uniform, whereas the output of --version is very dissimilar between different programs.

  • Another reason is that invoking the binary, just to do a --version, is actually more expensive (CPU-wise) than it is to query a simple text file, which is essentially what .pc files are. So this is another reason in favour of .pc files.

For these reasons, and a few smaller ones, the EnvironmentInformation project will try to prefer .pc files whenever that is possible. We may retain code that can handle --version calls, though, if they need a special way to query.

Querying all registered pkg-config entries

To show all registered pkg-config entries (with .pc files) do this:

envi --pkgconfig

If you want to obtain an Array of all outdated programs on the target computer system, try this method:


You need to have initialized the main hash once, before being able to make use of that method.

Quickly showing the version of individual programs

You can show the version of individual programs like this:

envi --bash
envi --brotli

This will only work if the program has been registered, though - so the second variant will not work.

Also take note that this will be ultra-short output, so nothing will be saved into a local file. The idea here is that the user only wants to see the version of the program at hand, such as the bash shell.

Aliases to program names

For several reasons it may be useful to define some aliases or shortcuts to registered names. For example, the input name yacc should point to the program called bison, and the input name diff should really be an abbreviation for diffutils. This allows the user to use the environment_information project in a more convenient manner.

Currently these aliases are hardcoded, defined in the method called EnvironmentInformation.return_alias_to().

If no alias is found then the method will simply return the original input argument. This allows us to use this method as a 'sanitizer' or filter.

Support for KDE

If you have the RBT gem installed (gem install rbt) then you can invoke envi via:

envi --kde?

Since as of August 2022 this will try to show the versions of installed KDE applications.

This currently does not work very well; at a later point this will be polished and improved.

Bugs and other misbehaviours

I noticed a few bugs here and there over the years. For instance, sometimes there may not be any output and the program stops working suddenly. This sometimes happens because there is some error in the underlying way how EnvironmentInformation obtains the version-information. In the long run I intend to improve the situation, by no longer falling into such issues - but they are not easily reproducible on my system. Either way I added this subsection in November 2021, to lessen the confusion for users at the least a little bit. And, again, as said, in the long run the code will change so as to not run into such situations anymore.

To provide a specific example: there may be instances of emacs about, such as on antiX, which simply did not provide any output. When I compiled emacs from source, it worked fine - so always check that the program works as assumed it should work.

GUIs - Graphical User Interfaces

A few bindings to graphical user interfaces exist, to ruby-gtk3 and ruby-libui. These are mostly just demos, proof-of-concept. They are not really very elegant or sophisticated - I really only wanted to show how to embed the information gained from the commandline via a GUI as well.

Since as of 2024, a GUI via jruby-Swing is now part of this gem. The current GUI is very minimalistic:

Still not very elegant. But the advantage here is that this also works on windows, and I may add more code over time to make this more useful on windows as well. One day I would like to have a collection of different widget sets that all work on as many different operating systems as possible. Stay tuned for more updates in this regard in the future.

Generating a .html file

You can pass the flag --generate-html-file to the main class, in order to generate a standalone .html file. Note that the commandline output will still be shown, so it may be a bit spammy. I use this to mostly find out which versions are available, and to additionally generate a .html file in case this has to be uploaded or shown to someone else via the browser.

The method .add() in class EnvironmentInformation::Query

The method .add() in that class is used to add the particular components that you wish to display. By default all components will be added, but you can override this behaviour via various commandline flags.

Disabling individual components

If you want to NOT show certain components, for whatever the reason, you can use this commandline flag:


This would NOT show htop and awk.

If you input an unregistered name then class Query will not notify you about this and simply ignore it - at the least this is the current behaviour.

Contact information and mandatory 2FA (no longer) coming up in 2022 / 2023

If your creative mind has ideas and specific suggestions to make this gem more useful in general, feel free to drop me an email at any time, via:

Before that email I used an email account at Google gmail, but in 2021 I decided to slowly abandon gmail, for various reasons. In order to limit the explanation here, allow me to just briefly state that I do not feel as if I want to promote any Google service anymore when the user becomes the end product (such as via data collection by upstream services, including other proxy-services). My feeling is that this is a hugely flawed business model to begin with, and I no longer wish to support this in any way, even if only indirectly so, such as by using services of companies that try to promote this flawed model.

In regards to responding to emails: please keep in mind that responding may take some time, depending on the amount of work I may have at that moment. So it is not that emails are ignored; it is more that I have not (yet) found the time to read and reply. This means there may be a delay of days, weeks and in some instances also months. There is, unfortunately, not much I can do when I need to prioritise my time investment, but I try to consider all feedback as an opportunity to improve my projects nonetheless.

In 2022 decided to make 2FA mandatory for every gem owner eventually:


However had, that has been reverted again, so I decided to shorten this paragraph. Mandatory 2FA may exclude users who do not have a smartphone device or other means to 'identify'. I do not feel it is a fair assumption by others to be made that non-identified people may not contribute code, which is why I reject it. Mandatory 2FA would mean an end to all my projects on, so let's hope it will never happen. (Keep in mind that I refer to mandatory 2FA; I have no qualms for people who use 2FA on their own, but this carrot-and-stick strategy by those who control the rubygems infrastructure is a very bad one to pursue.