environment_information 1.4.99
Sign up to get free protection for your applications and to get access to all the features.
Potentially problematic release.
This version of environment_information might be problematic. Click here for more details.
- checksums.yaml +7 -0
- data/README.md +1287 -0
- data/bin/envi +7 -0
- data/bin/fast_envi +7 -0
- data/doc/README.gen +1044 -0
- data/doc/todo/TODO_FOR_THE_ENVIRONMENT_INFORMATION_PROJECT.md +48 -0
- data/environment_information.gemspec +135 -0
- data/lib/environment_information/base/base.rb +166 -0
- data/lib/environment_information/class/class.rb +2829 -0
- data/lib/environment_information/colours/colours.rb +224 -0
- data/lib/environment_information/colours/sfancy.rb +19 -0
- data/lib/environment_information/colours/simp.rb +19 -0
- data/lib/environment_information/constants/array_tracked_components.rb +210 -0
- data/lib/environment_information/constants/constants.rb +17 -0
- data/lib/environment_information/constants/encoding.rb +21 -0
- data/lib/environment_information/constants/error_line.rb +17 -0
- data/lib/environment_information/constants/file_constants.rb +102 -0
- data/lib/environment_information/constants/misc.rb +86 -0
- data/lib/environment_information/constants/namespace.rb +14 -0
- data/lib/environment_information/constants/newline.rb +16 -0
- data/lib/environment_information/constants/regex.rb +30 -0
- data/lib/environment_information/constants/temp_directory.rb +52 -0
- data/lib/environment_information/gui/gtk2/environment_information.rb +35 -0
- data/lib/environment_information/gui/gtk3/environment_information.rb +34 -0
- data/lib/environment_information/gui/libui/environment_information.rb +74 -0
- data/lib/environment_information/gui/shared_code/environment_information_module.rb +409 -0
- data/lib/environment_information/misc_components/README.md +3 -0
- data/lib/environment_information/misc_components/cflags.rb +36 -0
- data/lib/environment_information/misc_components/cpuinfo.rb +64 -0
- data/lib/environment_information/misc_components/operating_system.rb +54 -0
- data/lib/environment_information/misc_components/operating_system_bit_type.rb +42 -0
- data/lib/environment_information/misc_components/ram.rb +30 -0
- data/lib/environment_information/misc_components/rubygems_installation_directory.rb +54 -0
- data/lib/environment_information/misc_components/screen_resolution.rb +50 -0
- data/lib/environment_information/project/project.rb +27 -0
- data/lib/environment_information/queries/README.md +2 -0
- data/lib/environment_information/queries/complex_version.rb +273 -0
- data/lib/environment_information/queries/pkg_config.rb +125 -0
- data/lib/environment_information/queries/simple_version.rb +217 -0
- data/lib/environment_information/requires/require_asciitable.rb +15 -0
- data/lib/environment_information/requires/require_the_constants.rb +7 -0
- data/lib/environment_information/requires/require_the_environment_information_project.rb +23 -0
- data/lib/environment_information/requires/require_the_individual_misc_components.rb +30 -0
- data/lib/environment_information/requires/require_the_toplevel_methods.rb +22 -0
- data/lib/environment_information/toplevel_methods/autogenerate_all_relevant_methods.rb +152 -0
- data/lib/environment_information/toplevel_methods/cd.rb +16 -0
- data/lib/environment_information/toplevel_methods/e.rb +43 -0
- data/lib/environment_information/toplevel_methods/hash.rb +60 -0
- data/lib/environment_information/toplevel_methods/internet_is_available.rb +30 -0
- data/lib/environment_information/toplevel_methods/is_on_roebe.rb +16 -0
- data/lib/environment_information/toplevel_methods/menu.rb +90 -0
- data/lib/environment_information/toplevel_methods/misc.rb +322 -0
- data/lib/environment_information/toplevel_methods/n_subcommands.rb +31 -0
- data/lib/environment_information/toplevel_methods/prefix_to_use.rb +39 -0
- data/lib/environment_information/toplevel_methods/register_this_component_is_missing.rb +61 -0
- data/lib/environment_information/toplevel_methods/remote_url_of_this_program.rb +45 -0
- data/lib/environment_information/toplevel_methods/replay_from_the_stored_file.rb +84 -0
- data/lib/environment_information/toplevel_methods/return_alias_to.rb +30 -0
- data/lib/environment_information/toplevel_methods/return_pkgconfig_based_programs.rb +28 -0
- data/lib/environment_information/toplevel_methods/return_remote_gtk2_version.rb +54 -0
- data/lib/environment_information/toplevel_methods/return_simple_version_based_programs.rb +28 -0
- data/lib/environment_information/toplevel_methods/return_version_of_this_program.rb +182 -0
- data/lib/environment_information/toplevel_methods/show_all_available_components.rb +192 -0
- data/lib/environment_information/toplevel_methods/write_what_into.rb +24 -0
- data/lib/environment_information/version/version.rb +25 -0
- data/lib/environment_information/www/sinatra_interface.rb +213 -0
- data/lib/environment_information/www/webobject_interface.cgi +29 -0
- data/lib/environment_information/yaml/array_default_programs_on_linux.yml +15 -0
- data/lib/environment_information/yaml/array_lfs_core_programs.yml +37 -0
- data/lib/environment_information/yaml/array_science_cluster.yml +12 -0
- data/lib/environment_information/yaml/array_tracked_non_programs.yml +13 -0
- data/lib/environment_information/yaml/array_tracked_programs.yml +215 -0
- data/lib/environment_information/yaml/array_tracked_xorg_components.yml +37 -0
- data/lib/environment_information/yaml/colours.yml +3 -0
- data/lib/environment_information/yaml/query_to_use_for_the_individual_components.yml +264 -0
- data/lib/environment_information.rb +5 -0
- data/test/testing_environment_information.rb +26 -0
- data/test/testing_missing_components.rb +9 -0
- data/test/testing_prefix_for_the_environment_information_project.rb +20 -0
- metadata +177 -0
data/doc/README.gen
ADDED
@@ -0,0 +1,1044 @@
|
|
1
|
+
ADD_RUBY_BADGE
|
2
|
+
|
3
|
+
## About the environment_information gem
|
4
|
+
|
5
|
+
This project is called **EnvironmentInformation** (**environment information**).
|
6
|
+
|
7
|
+
Its primary goal is **to gather information about the environment that ruby is
|
8
|
+
presently running on** - in other words, **the host system** and its
|
9
|
+
capabilities.
|
10
|
+
|
11
|
+
This gathered information can then be shown to the user on the commandline,
|
12
|
+
or via a ruby-gtk widget, or via a sinatra-interface on the www. The main focus
|
13
|
+
for this project is on the **commandline-usage**, though. For example, the
|
14
|
+
file at **bin/fenvi**, which is part of this project, can be used to
|
15
|
+
quickly show all versions of different programs on the target computer
|
16
|
+
system.
|
17
|
+
|
18
|
+
To provide a short overview how this may look, taken on the **KDE konsole**
|
19
|
+
and **bash**, have a look at the following image on a black background:
|
20
|
+
|
21
|
+
![alt text][screenshot1]
|
22
|
+
[screenshot1]: https://i.imgur.com/KiXIIVV.png
|
23
|
+
|
24
|
+
Invocation example:
|
25
|
+
|
26
|
+
fenvi
|
27
|
+
|
28
|
+
Generated output (only showing the first five entries):
|
29
|
+
|
30
|
+
atk 2.32.0
|
31
|
+
bash 5.0.0
|
32
|
+
binutils 2.32
|
33
|
+
bison 3.4.1
|
34
|
+
bzip2 1.0.8
|
35
|
+
|
36
|
+
Do note that by default **colours** will be used, so atk may appear
|
37
|
+
in green, and the associated version will be shown in a blue
|
38
|
+
colour (actually steelblue, by default). If you do not want to use
|
39
|
+
colours, you can disable them for the current invocation run, like
|
40
|
+
in this way:
|
41
|
+
|
42
|
+
envi --no-colours
|
43
|
+
envi --no-colors
|
44
|
+
envi --disable-colours
|
45
|
+
envi --disable-colors
|
46
|
+
|
47
|
+
Take note that you can tweak most of the behaviour of **EnvironmentInformation**
|
48
|
+
via specific **commandline flags**.
|
49
|
+
|
50
|
+
To obtain **a listing of the available options**, you can invoke the
|
51
|
+
main executable called **envi** (**bin/envi**) via:
|
52
|
+
|
53
|
+
envi --help
|
54
|
+
|
55
|
+
What is meant with the term **environment**?
|
56
|
+
|
57
|
+
**Definition**:
|
58
|
+
|
59
|
+
The term **environment**, within the context of the **environment_information gem**,
|
60
|
+
is **the (software) environment** that can be discovered by the ruby version
|
61
|
+
found within the **$PATH** variable, on the given computer system at hand.
|
62
|
+
|
63
|
+
Recall that there may be situations where there is more than one
|
64
|
+
version of ruby installed, on a given computer system, in different
|
65
|
+
locations - e. g. **/usr/bin/** versus **/usr/local/bin/**
|
66
|
+
versus **/home/** or **/opt/** setups. Thus, $PATH should be kept in mind in
|
67
|
+
the event that you have multiple ruby versions on the given computer system
|
68
|
+
at hand, as the incorrect ruby version may be discovered, in certain
|
69
|
+
situations. Furthermore keep also in mind that multiple binaries may exist
|
70
|
+
at the target system, e. g. bzip at /bin but also at /usr/bin or elsewhere.
|
71
|
+
|
72
|
+
Thus, I recommend to always ensure that **$PATH** is correctly set on the
|
73
|
+
target machine. First come, first serve, so it is a good advice to keep
|
74
|
+
PATH clean, and 'logical'.
|
75
|
+
|
76
|
+
At any rate, the **information** that will be gathered by the
|
77
|
+
**EnvironmentInformation** project may also be stored more persistently
|
78
|
+
in a **standalone .html file**, if you so desire to. This .html file
|
79
|
+
could then be used for static display of the information (but may
|
80
|
+
become quickly outdated, so keep this in mind as well).
|
81
|
+
|
82
|
+
The **Environment information** project may include any of the
|
83
|
+
following as its output:
|
84
|
+
|
85
|
+
- The **GCC Version** in use on the given computer host system.
|
86
|
+
- The (Linux) Kernel in use.
|
87
|
+
- Which Ruby Version is used.
|
88
|
+
- Which Rubygem version is used.
|
89
|
+
- The path to the rubygem directory.
|
90
|
+
- What the Host CPU Model is (on Linux at the least).
|
91
|
+
- What is the the **GTK*+, **GLIB*+ and **gdk-pixbuf** version, respectively.
|
92
|
+
- Which **dhcpcd version** is available.
|
93
|
+
- What Xorg components are available, such as libX11, libxcm, libxp,
|
94
|
+
libxau.
|
95
|
+
|
96
|
+
And so on and so forth - and a lot more.
|
97
|
+
|
98
|
+
Why are there many **different ways** to query the version of a locally
|
99
|
+
installed programs?
|
100
|
+
|
101
|
+
The main reason as to why **different ways** have to be supported is because
|
102
|
+
different software is installed in different ways, making use of
|
103
|
+
information in, well - different ways.
|
104
|
+
|
105
|
+
For example: not every software comes with a **.pc** file, so we can not
|
106
|
+
rely on .pc files uniformly for every installed program. Sometines no
|
107
|
+
commandline-binary is provided, so the **--version** flag can not be
|
108
|
+
used either; and if no .pc file exists for a given program, we may
|
109
|
+
have to query the name of the **.so files** (on a linux system),
|
110
|
+
and infer the version from that.
|
111
|
+
|
112
|
+
The main class in this project is **class EnvironmentInformation**,
|
113
|
+
which resides under **module EnvironmentInformation**.
|
114
|
+
|
115
|
+
The actual query of the version is done on the toplevel, so for example:
|
116
|
+
|
117
|
+
EnvironmentInformation.gcc?
|
118
|
+
|
119
|
+
would display the version of GCC at hand.
|
120
|
+
|
121
|
+
The code there will typically try to query .pc files via **pkg**-config,
|
122
|
+
but may sometimes try to infer the version from the .so file at hand,
|
123
|
+
and sometimes it will try to run the system binary (or an associated
|
124
|
+
binary) with a -V or -v or --version flag, and parse that output.
|
125
|
+
|
126
|
+
Typically the components that will be displayed, are handled by code
|
127
|
+
that resides in the file **display.rb**. The instance variable
|
128
|
+
**@display_these_components** keeps track of which components will
|
129
|
+
be displayed, so that information about these disparate programs
|
130
|
+
and components can be tracked.
|
131
|
+
|
132
|
+
There are in general only two entries that are of interest to
|
133
|
+
class EnvironmentInformation here:
|
134
|
+
|
135
|
+
(a) The name of the program.
|
136
|
+
(b) The associated specific program version, as String, of that program.
|
137
|
+
|
138
|
+
So, for example, we may see a key→value association like:
|
139
|
+
|
140
|
+
ruby => 2.5.1
|
141
|
+
|
142
|
+
If you need a **String** representation of the dataset then you can
|
143
|
+
use the method <b>.string?</b> or <b>.stringified</b>, which will give
|
144
|
+
you a **String** instead. The **.stringified** method exists
|
145
|
+
primarily due to **convenience** alone, for people who don't
|
146
|
+
want to do much conversion on their own and just be done with it).
|
147
|
+
|
148
|
+
There are various additional helper methods, such as a reader-method
|
149
|
+
called <b>.main_string?</b> or <b>.string</b> (they are equivalent to
|
150
|
+
one another, aka one is an alias).
|
151
|
+
|
152
|
+
This should allow you to re-use the information from this gem in
|
153
|
+
other projects, such as if you wish to get the String of all
|
154
|
+
available programs, and display this on a webpage. Or, alternatively,
|
155
|
+
just use a toplevel method call, such as:
|
156
|
+
|
157
|
+
EnvironmentInformation.glibc_version?
|
158
|
+
|
159
|
+
## How to make use of the project
|
160
|
+
|
161
|
+
There are, essentially, three recommended ways how to use the main
|
162
|
+
class of this project:
|
163
|
+
|
164
|
+
(1)
|
165
|
+
|
166
|
+
From the commandline, just call **envi** directly and pass in
|
167
|
+
specific commands to this executable (optionally).
|
168
|
+
|
169
|
+
For instance: invoke the envi-executable with the argument "ALL"
|
170
|
+
or "--all" and the class will show all information that could
|
171
|
+
be found. This is personally my favourite way how to invoke
|
172
|
+
this class. I even combine it with "FALL" or "RALL" (**--really-all**
|
173
|
+
or **--really-everything**), which will also compare the programs
|
174
|
+
versions that are available, if the RBT project is available
|
175
|
+
(**gem install rbt**), and then inform me as to which programs
|
176
|
+
are **not** up-to-date on the local computer system at hand. This
|
177
|
+
then allows me to compile/install these programs. This idea came
|
178
|
+
to be because I liked the Linux from Scratch project a lot, and
|
179
|
+
there you may often have to upgrade programs.
|
180
|
+
|
181
|
+
Note that **--really-everything** may be hard to type. I suggest to
|
182
|
+
use an alias in that case, or just the upcased variant **FALL** or
|
183
|
+
**RALL**. See the file <b>menu.rb</b> for more aliases to that.
|
184
|
+
|
185
|
+
(2)
|
186
|
+
|
187
|
+
The other use case is the "embedded use", i.e. for use in a
|
188
|
+
<b>.cgi page</b> or perhaps for a ruby-on-rails webpage.
|
189
|
+
|
190
|
+
An example for the former follows:
|
191
|
+
|
192
|
+
_ = EnvironmentInformation.new(:do_not_run_yet) # The symbol allows us to prepare the class first.
|
193
|
+
_.set_n_tokens 58
|
194
|
+
_.disable_colours # <- Recommended, since the colours are thought for the commandline only.
|
195
|
+
_.be_silent
|
196
|
+
_.dont_show_ruby_stuff # <- If you do not need information about ruby.
|
197
|
+
_.run
|
198
|
+
|
199
|
+
But you do not have to instantiate a new object; you can
|
200
|
+
simply use another toplevel API, since as of September 2019.
|
201
|
+
|
202
|
+
(3)
|
203
|
+
|
204
|
+
For example, to query the glibc version, you could use this:
|
205
|
+
|
206
|
+
EnvironmentInformation.glibc? # => "2.29"
|
207
|
+
|
208
|
+
Which variant to prefer? This depends on your use case. If you
|
209
|
+
need more flexibility then you should use the class; if you
|
210
|
+
only need the version-string, number 3 may be best as it is
|
211
|
+
the simplest.
|
212
|
+
|
213
|
+
You can also display some additional information, such as the version
|
214
|
+
of GTK, Glib, Atk and Pango, by passing in "f" or "full" or "--full"
|
215
|
+
on the commandline, without the quotation marks.
|
216
|
+
|
217
|
+
See the help section to this this script, which can be invoked by
|
218
|
+
passing "help" or "--help" as argument to envi.
|
219
|
+
|
220
|
+
You can also pass this information through a block, if you would like to:
|
221
|
+
|
222
|
+
_ = EnvironmentInformation.new(:do_not_run_yet) {
|
223
|
+
n_tokens: 58,
|
224
|
+
use_colours: no,
|
225
|
+
be_silent: true
|
226
|
+
show_ruby_stuff: no
|
227
|
+
}
|
228
|
+
_.run
|
229
|
+
|
230
|
+
Do note that the following **API** also works, primarily due to
|
231
|
+
convenience - you can try it in **irb**, of course:
|
232
|
+
|
233
|
+
require 'environment_information'
|
234
|
+
|
235
|
+
EnvironmentInformation[]
|
236
|
+
|
237
|
+
The executable version for class EnvironmentInformation is called <b>envi</b>.
|
238
|
+
It will reside under **bin/envi** of this gem.
|
239
|
+
|
240
|
+
So you can invoke the script by typing "envi" from the commandline,
|
241
|
+
without the quotes; if you installed it as a gem into a prefix
|
242
|
+
other than /usr, it may be that the bin/ directory resides only
|
243
|
+
in that gem, though. Setting an alias may help in this case.
|
244
|
+
|
245
|
+
## Colours used by the EnvironmentInformation project
|
246
|
+
|
247
|
+
Support for colours in the <b>environment_information</b> gem
|
248
|
+
is available through the following file:
|
249
|
+
|
250
|
+
environment_information/colours/colours.rb
|
251
|
+
|
252
|
+
Which, in turn, taps into the **colours** gem.
|
253
|
+
|
254
|
+
In theory other colour-related gems could be used as well, but this may
|
255
|
+
require someone to write support-code for this, in regards to other
|
256
|
+
gems.
|
257
|
+
|
258
|
+
Presently (August 2020; September 2022) this project <b>only</b> uses
|
259
|
+
the **colours** gem (**gem install colours**), though.
|
260
|
+
|
261
|
+
You can specifically **disable** the use of colours for the current
|
262
|
+
invocation run, for whatever the reasons, from the commandline,
|
263
|
+
via either:
|
264
|
+
|
265
|
+
envi --disable-colours
|
266
|
+
envi --disable-colors
|
267
|
+
envi --nocolours
|
268
|
+
envi --nocolors
|
269
|
+
envi --no-colours
|
270
|
+
|
271
|
+
envi --really-all --disable-colours
|
272
|
+
envi --really-all --disable-colors
|
273
|
+
|
274
|
+
envi --all --disable-colours
|
275
|
+
envi --all --disable-colors
|
276
|
+
|
277
|
+
Note that <b>envi</b> refers to <b>bin/envi</b>, which is distributed
|
278
|
+
as part of this gem.
|
279
|
+
|
280
|
+
Both UK and US spelling should work fine in regards to colours/colors;
|
281
|
+
use whicher variant you prefer.
|
282
|
+
|
283
|
+
Internally, the **@use_colours** variable is used to determine
|
284
|
+
whether colours are to be used for the main class of this gem.
|
285
|
+
|
286
|
+
You can query the current setting via the following toplevel
|
287
|
+
method (in ruby):
|
288
|
+
|
289
|
+
EnvironmentInformation.use_colours?
|
290
|
+
|
291
|
+
You can also query whether colours are used via <b>envi</b>
|
292
|
+
as well (the **bin/envi** file) from the commandline, via:
|
293
|
+
|
294
|
+
envi --use-colours?
|
295
|
+
envi --use-colors?
|
296
|
+
|
297
|
+
The default assumption for commandline use of this gem is that
|
298
|
+
the user uses a black/dark background in the terminal; and white
|
299
|
+
colour for the text, or at the least some light/bright colour.
|
300
|
+
|
301
|
+
Not every uses uses a black background, though. In these cases
|
302
|
+
the default colours used by the environment_gem are not optimal.
|
303
|
+
|
304
|
+
Because this may be a concern for some users, support was added
|
305
|
+
to the environment_information gem to allow them to use different
|
306
|
+
colours if they want to. So, not only can you disable colours
|
307
|
+
altogether, but you can also fine-tune them to your liking, if
|
308
|
+
you want to.
|
309
|
+
|
310
|
+
The file that will handle this is a .yml file and it normally
|
311
|
+
resides at:
|
312
|
+
|
313
|
+
environment_information/yaml/colours.yml
|
314
|
+
|
315
|
+
Currently (September 2022) it only covers two values - the
|
316
|
+
colour for the left-hand display, and the colour for the
|
317
|
+
right-hand display. This refers to the table-layout that
|
318
|
+
you can see when you use the environment_gem (bin/envi)
|
319
|
+
on the commandline. To the left side one will typically
|
320
|
+
see the name of the program; to the right side the version
|
321
|
+
of that program is shown. The two colour names used in
|
322
|
+
the .yml file will determine this. You can change the names
|
323
|
+
there; I use HTML colour names.
|
324
|
+
|
325
|
+
If the .yml file can not be found or is missing then the
|
326
|
+
two default colours in use will be <b>forestgreen</b>
|
327
|
+
(for the left side) and <b>steelblue</b> (for the
|
328
|
+
right side).
|
329
|
+
|
330
|
+
A third entry exists called <b>program_not_found</b>,
|
331
|
+
defaulting to <b>lightslategrey</b>. Most users probably may
|
332
|
+
not need to change this, but in the event that you would
|
333
|
+
like to, you can change it of course. In principle commandline
|
334
|
+
support could be added to change the colours on an ad-hoc
|
335
|
+
basis during a run of bin/envi, but for now I'll leave it
|
336
|
+
how it is. If someone wants to be able to fine-tune the colours
|
337
|
+
on the commandline, without wanting to modify the .yml file,
|
338
|
+
let me know; I'll add support in this case then.
|
339
|
+
|
340
|
+
Note that you can combine this in various means.
|
341
|
+
|
342
|
+
For instance, to show information about EVERY program,
|
343
|
+
and use a compact display without any newlines, while
|
344
|
+
also disabling colours, use the following:
|
345
|
+
|
346
|
+
envi --rall --oneliner --disable-colours
|
347
|
+
|
348
|
+
The following image shows how this looks:
|
349
|
+
|
350
|
+
<img src="https://i.imgur.com/dt3PhRY.png" style="margin: 2em">
|
351
|
+
|
352
|
+
Yes, this is not very elegant and hard(er) to read,
|
353
|
+
but imagine if you work on Linux runlevel 3, without
|
354
|
+
a GUI. In this case this can be convenient to have
|
355
|
+
in one terminal as you work.
|
356
|
+
|
357
|
+
|
358
|
+
## fenvi
|
359
|
+
|
360
|
+
There is an executable at **bin/fast_envi**, as part of this gem, which
|
361
|
+
complements the executable at **bin/envi**. envi is simply an abbreviation
|
362
|
+
to "environment information"; and fenvi stands for "fast environment
|
363
|
+
information". That is exactly the primary use case for fenvi - it shall
|
364
|
+
allow for maximum speed, without "maximal usability". The latter means
|
365
|
+
that fenvi will not offer as much customization/flexibility as envi
|
366
|
+
does. In fact - the EnvironmentInformation project was rewritten in
|
367
|
+
**September 2019** precisely to make the whole project much more
|
368
|
+
performant and faster; the old code was too slow, for various reasons.
|
369
|
+
(Note: I am using an alias called fenvi that refers to fenvi; the
|
370
|
+
official name of the executable is **fast_envi** though.)
|
371
|
+
|
372
|
+
Nonetheless, **fenvi** also supports some commandline flags.
|
373
|
+
|
374
|
+
For example, if you wish to only show the registered xorg components
|
375
|
+
and their corresponding versions, then you can issue the following
|
376
|
+
flag:
|
377
|
+
|
378
|
+
fenvi --xorg
|
379
|
+
|
380
|
+
This would **show all xorg components**.
|
381
|
+
|
382
|
+
fenvi --help
|
383
|
+
|
384
|
+
Would show the help options. Right now this is limited to just two
|
385
|
+
options (or perhaps a bit more than that in the long run).
|
386
|
+
|
387
|
+
Another option is:
|
388
|
+
|
389
|
+
fenvi --compare-to-program-versions
|
390
|
+
|
391
|
+
This can be used to quickly compare the program versions of the
|
392
|
+
local computer system. Note that this functionality depends on
|
393
|
+
the RBT gem:
|
394
|
+
|
395
|
+
gem install rbt
|
396
|
+
|
397
|
+
## Determining which programs should be shown on your own
|
398
|
+
|
399
|
+
You can decide to only show the version of some programs, via the
|
400
|
+
**commandline** specifically.
|
401
|
+
|
402
|
+
For example, say that you wish to see only the versions of **ruby**,
|
403
|
+
**python** and **perl**, then you could try the following:
|
404
|
+
|
405
|
+
envi --use-these-programs=ruby,python,perl
|
406
|
+
|
407
|
+
If you wish to display the local versions of **bash**, **binutils**
|
408
|
+
and **bison**, then you can try this:
|
409
|
+
|
410
|
+
envi --use-these-programs=bash,binutils,bison
|
411
|
+
|
412
|
+
If you wish to show all components that may be important for
|
413
|
+
the LFS (linux from scratch) project then you can use this:
|
414
|
+
|
415
|
+
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
|
416
|
+
|
417
|
+
Since that is a bit annoying to type (it's quite long), you can also
|
418
|
+
use the **fake-symbol** :lfs for this instead:
|
419
|
+
|
420
|
+
envi --use-these-programs=:lfs
|
421
|
+
|
422
|
+
Or, even simpler than that:
|
423
|
+
|
424
|
+
envi --lfs
|
425
|
+
|
426
|
+
In fact, this functionality has been added precisely to
|
427
|
+
avoid using a shell script, such as this one:
|
428
|
+
|
429
|
+
http://www.linuxfromscratch.org/lfs/view/development/chapter02/hostreqs.html
|
430
|
+
|
431
|
+
The name **fake-symbol** is given because via the commandline
|
432
|
+
you can only pass e. g. a String, not a Symbol, as bash does
|
433
|
+
not know what a Symbol is. So if a string has a leading :
|
434
|
+
then the EnvironmentInformation project will assume that the
|
435
|
+
user wanted to convey a **special meaning**.
|
436
|
+
|
437
|
+
If you do not wish to save any local file then invoke EnvironmentInformation
|
438
|
+
in this way:
|
439
|
+
|
440
|
+
envi --lfs --no-save
|
441
|
+
|
442
|
+
If you wish to show the local version of openssl as well, try
|
443
|
+
adding this commandline flag:
|
444
|
+
|
445
|
+
envi --openssl
|
446
|
+
|
447
|
+
## xorg components
|
448
|
+
|
449
|
+
To display the registered **xorg components**, you could use any of
|
450
|
+
the following commandline flags:
|
451
|
+
|
452
|
+
envi --xorg-components
|
453
|
+
envi --xorg
|
454
|
+
|
455
|
+
Do note that not necessarily every xorg component is registered,
|
456
|
+
but most of the xorg-components should be covered by now.
|
457
|
+
|
458
|
+
## Reading from a local file
|
459
|
+
|
460
|
+
The **EnvironmentInformation project** can read from a **local file**
|
461
|
+
containing the programs whose version you would like to show, on the
|
462
|
+
commandline.
|
463
|
+
|
464
|
+
The commandline invocation goes like this:
|
465
|
+
|
466
|
+
envi --read-from-this-file=/Depot/j/display_these_programs.md
|
467
|
+
envi --file=/Depot/j/display_these_programs.md
|
468
|
+
envi --input-from=/Depot/j/display_these_programs.md
|
469
|
+
|
470
|
+
The reason as to why this functionality has been made available
|
471
|
+
is so that people can use their own custom input to the main
|
472
|
+
class of this gem, if they would like to.
|
473
|
+
|
474
|
+
A requirement for this to work is that there is a corresponding
|
475
|
+
component that can query the version of a program. I am open for
|
476
|
+
suggestions what to add, if anything is missing, as well as
|
477
|
+
including a more generic way to make a query. Either way this
|
478
|
+
depends on others to make suggestions.
|
479
|
+
|
480
|
+
## Sorting the components alphabetically
|
481
|
+
|
482
|
+
You can display the components in an alphabetical manner, if you
|
483
|
+
would like to, through this:
|
484
|
+
|
485
|
+
envi --sort-alphabetically
|
486
|
+
|
487
|
+
## Sinatra interface
|
488
|
+
|
489
|
+
Since as of **May 2019** there is now a small sinatra "interface"
|
490
|
+
available.
|
491
|
+
|
492
|
+
To start it, try:
|
493
|
+
|
494
|
+
envi --sinatra
|
495
|
+
|
496
|
+
In order for this to work, you need to have sinatra installed, such as
|
497
|
+
via this way:
|
498
|
+
|
499
|
+
gem install sinatra
|
500
|
+
|
501
|
+
or
|
502
|
+
|
503
|
+
gem install sinatra --user-install # into the home directory
|
504
|
+
|
505
|
+
It is not a mandatory dependency for this gem, so it is not registered
|
506
|
+
to be a hard dependency in the **.gemspec** file.
|
507
|
+
|
508
|
+
## The science cluster
|
509
|
+
|
510
|
+
There are also a few science-related applications, such as for hmmer
|
511
|
+
or relion. To query their versions specifically you can issue:
|
512
|
+
|
513
|
+
envi --science
|
514
|
+
|
515
|
+
## Show the URL of every registered program
|
516
|
+
|
517
|
+
You can, if you like to, show the remote URLs to the different
|
518
|
+
programs, if you have the **RBT project** installed (**gem install rbt**).
|
519
|
+
|
520
|
+
Then, you should be able to do the following:
|
521
|
+
|
522
|
+
envi --everything --show-remote-url
|
523
|
+
|
524
|
+
This variant will not only display the local programs found,
|
525
|
+
but will additionally also show the **remote URLs** on the
|
526
|
+
commandline, on the right hand side, to the corresponding
|
527
|
+
program at hand.
|
528
|
+
|
529
|
+
## Only display the operating system in use
|
530
|
+
|
531
|
+
If you are only interested in seeing the operating system, try
|
532
|
+
this **commandline flag**:
|
533
|
+
|
534
|
+
envi --os?
|
535
|
+
|
536
|
+
## Showing additional programs on an ad-hoc basis
|
537
|
+
|
538
|
+
You can also show additional individual components via the **--additional**
|
539
|
+
flag, like this:
|
540
|
+
|
541
|
+
envi --additional=php,python,perl
|
542
|
+
|
543
|
+
This would display the local versions of the installed programs
|
544
|
+
**php**, **python** and **perl**. You can add any additional
|
545
|
+
program as you see fit there, separated via ',' character -
|
546
|
+
this will, however had, only work if that program has been
|
547
|
+
registered in the <b>environment_information</b> gem.
|
548
|
+
|
549
|
+
Note that since as of **September 2019** you can also add the name
|
550
|
+
of the component directly. For example, to show the version of
|
551
|
+
bash, you can invoke envi like this:
|
552
|
+
|
553
|
+
envi --bash
|
554
|
+
|
555
|
+
To also show php and python, you can do this:
|
556
|
+
|
557
|
+
envi --bash --php --python
|
558
|
+
|
559
|
+
Use whichever variant you prefer - the choices are up to the user.
|
560
|
+
|
561
|
+
## Ruby-gtk bindings
|
562
|
+
|
563
|
+
A small **gtk-widget** exists, which can be started via either of:
|
564
|
+
|
565
|
+
envi --gui
|
566
|
+
envi --gtk
|
567
|
+
|
568
|
+
Note that this requires the **ruby-gtk package**, in particular
|
569
|
+
**gtk2**, and possibly also the gem called **gtk_paradise**.
|
570
|
+
|
571
|
+
Installing these could be done through the following commandline
|
572
|
+
invocations:
|
573
|
+
|
574
|
+
gem install gtk2
|
575
|
+
gem install gtk3
|
576
|
+
gem install gtk_paradise
|
577
|
+
|
578
|
+
You may need the "devel" packages (.h files) for this to work.
|
579
|
+
|
580
|
+
The **gtk** widget is really just extremely simple, and thus not too
|
581
|
+
terribly useful, since it lacks functionality; I only wanted to be
|
582
|
+
able to **embed this information** into other ruby-gtk applications.
|
583
|
+
At some point in the future, the functionality may be extended - but
|
584
|
+
for the time being, it will remain simple. **Simple is beautiful**,
|
585
|
+
too.
|
586
|
+
|
587
|
+
Presently (September 2019) the gtk-bindings in the
|
588
|
+
**environment_information** project only support **ruby-gtk2**,
|
589
|
+
but in the future I may switch to **ruby-gtk3** - or at the
|
590
|
+
least offer means for the user to decide which variant is
|
591
|
+
to be used.
|
592
|
+
|
593
|
+
## No changelog entries any longer
|
594
|
+
|
595
|
+
In the past, changes to this project were listed specifically, together
|
596
|
+
with the date - a short changelog.
|
597
|
+
|
598
|
+
However had, most users are probably more interested in the options
|
599
|
+
and features that are supported as-is; the features that are available
|
600
|
+
right **now**. Seeing every unimportant change made in the long
|
601
|
+
forgotten past, is not that useful for most users. Additionally, for
|
602
|
+
**small projects**, a changelog is not really that worthwhile to be
|
603
|
+
had to begin with.
|
604
|
+
|
605
|
+
So, I have abandoned the concept of a changelog for this project. Do
|
606
|
+
note that if there is something noteworthy that has been changed, it
|
607
|
+
will be mentioned and documented here in this file (**README.md**)
|
608
|
+
anyway.
|
609
|
+
|
610
|
+
## How to add new components/entries to this project
|
611
|
+
|
612
|
+
The file <b>environment_information/constants/array_tracked_components.rb</b>
|
613
|
+
keeps track over all available entries.
|
614
|
+
|
615
|
+
The method called **return_default_programs_on_a_linux_computer**,
|
616
|
+
defined in the file <b>environment_information/base/misc.rb</b>,
|
617
|
+
will add all the entries that are, assumingly, useful on a linux
|
618
|
+
computer by default.
|
619
|
+
|
620
|
+
If you want to change the entries, or add new ones, look there first.
|
621
|
+
If you wish to register a new program, you have to add it onto the
|
622
|
+
main Array (in the constants.rb file) first.
|
623
|
+
|
624
|
+
You will also have to add a method that does the actual **query**
|
625
|
+
part for the program version at hand, within the
|
626
|
+
<b>environment_information/individual_components/</b> subdirectory.
|
627
|
+
|
628
|
+
It may be simplest to just copy one of those .rb files, by giving it
|
629
|
+
the same name as the program you wish to see displayed. You will
|
630
|
+
then have to **change the content** of that method too, in that
|
631
|
+
new file, but this is quite trivial and takes at maximum five
|
632
|
+
minutes (for those who have not seen it before; it takes
|
633
|
+
significantly less time for those who already know what to change
|
634
|
+
there). Entries that come with **pkg-config .pc files** are even
|
635
|
+
simpler to add - this is much easier than manually parsing
|
636
|
+
**--version** flags.
|
637
|
+
|
638
|
+
In the future I may switch to a yaml file rather than hardcode
|
639
|
+
the entries in .rb directly, but for the time being, I will stick
|
640
|
+
to the method described above.
|
641
|
+
|
642
|
+
## Short display variant
|
643
|
+
|
644
|
+
If you only wish to quickly view the most important information
|
645
|
+
about the local computer system, then you can use the following
|
646
|
+
variant:
|
647
|
+
|
648
|
+
envi --short
|
649
|
+
|
650
|
+
## Caveats
|
651
|
+
|
652
|
+
Note that the **EnvironmentInformation** project has to sometimes guess
|
653
|
+
how to obtain the necessary information, in order to determine which
|
654
|
+
program is installed. For example, for programs such as **readline**
|
655
|
+
there is no trivial way to determine which version is used, to
|
656
|
+
**EnvironmentInformation** will attempt to read the .so files, and
|
657
|
+
determine the version from the .so files. This may fail, depending
|
658
|
+
on the setup of the host computer.
|
659
|
+
|
660
|
+
In general, the two best ways to determine the version of programs
|
661
|
+
are via a **--version** flag or simply by using **pkg-config** to
|
662
|
+
query the .pc file of the package. But this is not available for
|
663
|
+
all programs, so ultimately **EnvironmentInformation** may not
|
664
|
+
display completely accurate information on all given computer
|
665
|
+
systems.
|
666
|
+
|
667
|
+
## Clearing the old dataset
|
668
|
+
|
669
|
+
Via **--clear** on the commandline you can remove all old entries.
|
670
|
+
This commandline flag thus resets **class EnvironmentInformation**
|
671
|
+
to a totally clean, fresh state. Internally the method .reset() will
|
672
|
+
be called on **class EnvironmentInformation**.
|
673
|
+
|
674
|
+
This allows you to show only one component, or a few components,
|
675
|
+
for example. The following example demonstrates this.
|
676
|
+
|
677
|
+
Say that you wish to show **only** **python** and **php**, thus
|
678
|
+
two programs only. Then you can use the following flag to achieve
|
679
|
+
this, in this order:
|
680
|
+
|
681
|
+
envi --clear --python --php
|
682
|
+
|
683
|
+
The order is important because --clear will clear at the moment
|
684
|
+
it occurs in **ARGV**, which holds the commandline-arguments
|
685
|
+
issued on the commandline by the user.
|
686
|
+
|
687
|
+
## Which packages will be checked by default?
|
688
|
+
|
689
|
+
The following provides a list of packages that are presently,
|
690
|
+
in **October of 2019**, tracked.
|
691
|
+
|
692
|
+
In the past I did manually copy/paste the following listing, but
|
693
|
+
since as of 15th of October 2019, the list is **autogenerated** via
|
694
|
+
a macro.
|
695
|
+
|
696
|
+
This listing can be seen in the **file**:
|
697
|
+
|
698
|
+
environment_information/constants/array_tracked_components.rb
|
699
|
+
|
700
|
+
These are the following programs:
|
701
|
+
|
702
|
+
ADD_ENVIRONMENT_INFORMATION_PROPERLY_FORMATTED_ARRAY
|
703
|
+
|
704
|
+
You can also display these programs dynamically, such as through the
|
705
|
+
following **API**:
|
706
|
+
|
707
|
+
require 'environment_information'
|
708
|
+
|
709
|
+
pp EnvironmentInformation.tracked_programs?
|
710
|
+
|
711
|
+
Note that since as of **March 2019**, environment_information will also attempt
|
712
|
+
to find out the installed version for **gmp**, **mpfr** and **mpc**. This
|
713
|
+
may fail, though, and will be silently ignored in these cases (at least
|
714
|
+
for the time being).
|
715
|
+
|
716
|
+
You can use the following method to display a list of all programs
|
717
|
+
that are registered, from the commandline:
|
718
|
+
|
719
|
+
envi --registered-components?
|
720
|
+
|
721
|
+
This will show every registered (and thus, available) component of this
|
722
|
+
project.
|
723
|
+
|
724
|
+
As of **February 2020**, this project tracks at the least 105 different
|
725
|
+
programs. More entries will be added in the future, but the primary
|
726
|
+
focus will be on a **Linux from Scratch** / **Beyond Linux from Scratch**
|
727
|
+
setup, so expect those programs that are installed first, to be added
|
728
|
+
next, too.
|
729
|
+
|
730
|
+
## Querying the components that will be shown
|
731
|
+
|
732
|
+
You can query the components that will be shown, by issuing one of
|
733
|
+
the following commands:
|
734
|
+
|
735
|
+
envi --show-components?
|
736
|
+
envi --show-components
|
737
|
+
|
738
|
+
Note that this works exclusively, meaning that if you use this
|
739
|
+
commandline switch, then you will ONLY get a query of the
|
740
|
+
components that are available.
|
741
|
+
|
742
|
+
## Replaying the information
|
743
|
+
|
744
|
+
Normally showing all information when issuing **envi --RALL** can take
|
745
|
+
quite some time; on my computer system 18 seconds, before the rewrite
|
746
|
+
in February 2020.
|
747
|
+
|
748
|
+
The reason as to why it takes that long is mostly because many different
|
749
|
+
files have to be queried; their --version flag has to be called or
|
750
|
+
their .pc file has to be checked, but most importantly querying data
|
751
|
+
from the **RBT project** currently takes way too long. This is not an
|
752
|
+
ideal situation, as nobody wants to wait.
|
753
|
+
|
754
|
+
Waiting 18 seconds is simply too long, though, but until that part in
|
755
|
+
RBT is improved, I have added a **--replay** functionality for **class
|
756
|
+
EnvironmentInformation** (via the commandline).
|
757
|
+
|
758
|
+
What this functionality does is to take an available (existing) .yml
|
759
|
+
file that holds the information from the last invocation run, and then
|
760
|
+
proceeds to display this information on the commandline to the user.
|
761
|
+
This will evidently be much faster, since the information has already
|
762
|
+
been stored before in a prior run.
|
763
|
+
|
764
|
+
This change required that the environment information project will
|
765
|
+
also generate a **.yml file** by default.
|
766
|
+
|
767
|
+
Note that this functionality is not yet complete; I will extend this
|
768
|
+
at a later time (written this part here as of **December 2019**).
|
769
|
+
|
770
|
+
You can disable saving into this .yml file via:
|
771
|
+
|
772
|
+
envi --no-yaml-file
|
773
|
+
|
774
|
+
To invoke the replay functionality, do:
|
775
|
+
|
776
|
+
envi --replay
|
777
|
+
|
778
|
+
## Avoid the creation of local files
|
779
|
+
|
780
|
+
By default, the main class in this project may generate a few local
|
781
|
+
files. This may not always be wanted, or possible (e. g. in a
|
782
|
+
read-only filesystem), so an option has to exist that disables
|
783
|
+
this functionality.
|
784
|
+
|
785
|
+
That option is called **--no-save** and can be used like this:
|
786
|
+
|
787
|
+
envi --lfs --no-save
|
788
|
+
|
789
|
+
## Using another prefix
|
790
|
+
|
791
|
+
By default, the environment_information project will assume that
|
792
|
+
the main prefix is / or /usr, respectively. In other words, it
|
793
|
+
will assume that, for example, the binary called "bison" will
|
794
|
+
reside at /usr/bin/bison. To be more correct, it will make use
|
795
|
+
of the PATH environment variable, but for most users this will
|
796
|
+
list /usr/bin/ first.
|
797
|
+
|
798
|
+
That way "bison --version" should work and be the same as
|
799
|
+
"/usr/bin/bison --version".
|
800
|
+
|
801
|
+
For pkg-config .pc files, the main target will usually then
|
802
|
+
be at /usr/lib/pkgconfig/.
|
803
|
+
|
804
|
+
Note that the above is not always a correct assumption. For
|
805
|
+
example, the **GoboLinux approach** uses the **/Programs/**
|
806
|
+
hierarchy instead (but it also keeps legacy symlinks, so in
|
807
|
+
fact GoboLinux works just like any other linux distribution too).
|
808
|
+
|
809
|
+
On my home setup, I tend to use /home/Programs/ since some
|
810
|
+
time - mostly because I tend to relocate /home/ in general
|
811
|
+
or may keep it on a separate partition.
|
812
|
+
|
813
|
+
For these latter use cases we require another way to quickly
|
814
|
+
list all versions of different programs. On 14.01.2020
|
815
|
+
support for this has been (partially) added.
|
816
|
+
|
817
|
+
Invoke this like so:
|
818
|
+
|
819
|
+
envi --work-on-programs-directory-only
|
820
|
+
|
821
|
+
Note that this would use /home/Programs/ right now, which
|
822
|
+
is hardcoded - and thus not flexible.
|
823
|
+
|
824
|
+
I am aware of this limitation, so expect more code changes
|
825
|
+
in the future to extend this functionality.
|
826
|
+
|
827
|
+
One key idea for this is to set up /home/Programs/Toolchain/
|
828
|
+
and have that one work reliably to cross-compile different
|
829
|
+
architectures, libc libraries and so forth. But for now,
|
830
|
+
this subsection is a stub.
|
831
|
+
|
832
|
+
## Rationale as to why some programs may work and some may not
|
833
|
+
|
834
|
+
Querying the specific version installed on a given computer
|
835
|
+
system can be tricky. If a **.pc file** is available (**pkg-config**)
|
836
|
+
then querying the version is quite trivial. If a **binary** is
|
837
|
+
available then often **--version** or **-V** will work. But
|
838
|
+
sometimes there is no binary, and no .pc file either. So what
|
839
|
+
to do in such a case?
|
840
|
+
|
841
|
+
This is not simple to answer, since it may depend on the
|
842
|
+
program at hand.
|
843
|
+
|
844
|
+
It may be possible to infer the proper version from the
|
845
|
+
library at hand e. g. **/usr/lib/foobar.so.4.8.2**. Here
|
846
|
+
we could assume that the version will be 4.8.2, but this
|
847
|
+
is not necessarily guaranteed to work, either.
|
848
|
+
|
849
|
+
In the past, before the rewrite of this project in **February 2020**,
|
850
|
+
the environment_information project had used code that would
|
851
|
+
check for such conditions - for example, for **readline**,
|
852
|
+
and look for specific .so files under **/usr/lib/** or
|
853
|
+
elsewhere.
|
854
|
+
|
855
|
+
But the resulting code that had to be written for this, was not
|
856
|
+
very elegant, and takes about 10-20 lines of code for checking
|
857
|
+
this, including fall-backs, for each program that does not
|
858
|
+
conform to --version or a .pc file. I am no longer sure whether
|
859
|
+
it is worth to add that code, since it also may have to be
|
860
|
+
maintained, and is not always perfect nor does it always work,
|
861
|
+
depending on the computer system at hand. So, past this point,
|
862
|
+
**environment_information** is not doing its best to query the
|
863
|
+
version for all programs - it will try pkg-config and
|
864
|
+
--version or -V in most cases, and if that fails then
|
865
|
+
the environment_information project will assume that the
|
866
|
+
program at hand is not installed.
|
867
|
+
|
868
|
+
This may be a **false negative**, but to me it appears
|
869
|
+
to be better in the long run, in regards to maintainability
|
870
|
+
of the whole project. After all one reason for the rewrite
|
871
|
+
in 2020 was to simplify the whole project, and this objective
|
872
|
+
has been achieved - all the commands are now stored in yaml
|
873
|
+
files, and that is so much simpler to handle than the
|
874
|
+
corresponding ruby methods that were used before that.
|
875
|
+
|
876
|
+
## Adding new entries to EnvironmentInformation
|
877
|
+
|
878
|
+
New entries can be added into the following yaml file:
|
879
|
+
|
880
|
+
**query_to_use_for_the_individual_components.yml**
|
881
|
+
|
882
|
+
The two most commonly used variants there are version,
|
883
|
+
for **bin/foo --version* invocations, and pkgconfig,
|
884
|
+
for querying pkg-config .pc files. However had, many
|
885
|
+
programs make use of different invocation variants,
|
886
|
+
don't come with a .pc file, and have no binaries.
|
887
|
+
Querying the correct version of such files is difficult
|
888
|
+
since there is no standard. This is a reason why the
|
889
|
+
code has to handle these cases.
|
890
|
+
|
891
|
+
But in principle, adding a new entry is as simple as
|
892
|
+
adding a new line into that .yml file (and registering
|
893
|
+
that component in a second .yml file).
|
894
|
+
|
895
|
+
## The toplevel main hash
|
896
|
+
|
897
|
+
EnvironmentInformation tries to store the information that
|
898
|
+
it has collected into a **hash**, which can be accessed like
|
899
|
+
this quickly:
|
900
|
+
|
901
|
+
EnvironmentInformation.hash?
|
902
|
+
|
903
|
+
By default this hash is empty, so you have to fill it up
|
904
|
+
first, if you want to do so, via the following method:
|
905
|
+
|
906
|
+
EnvironmentInformation.initialize
|
907
|
+
|
908
|
+
hash = EnvironmentInformation.hash? # ← and here you can query it
|
909
|
+
|
910
|
+
The hash can then be used as basis for reporting at a later time,
|
911
|
+
or replaying that information via the **--replay** commandline
|
912
|
+
switch to the executable.
|
913
|
+
|
914
|
+
## Dependencies of the EnvironmentInformation project
|
915
|
+
|
916
|
+
The sole dependency for the **environment_information gem**
|
917
|
+
is on the **colours** gem.
|
918
|
+
|
919
|
+
Up until the beginning of March 2020, the EnvironmentInformation
|
920
|
+
project also depended on the **opn gem**. However had, I
|
921
|
+
noticed that in a restricted environment installation of
|
922
|
+
gems can be difficult, so I made opn **optional**. If you have
|
923
|
+
it installed then EnvironmentInformation will still try to
|
924
|
+
make use of the **Opn namespace**; and if it is not installed
|
925
|
+
then EnvironmentInformation will simply **skip** Opn completely.
|
926
|
+
|
927
|
+
## Rationale behind the different queries
|
928
|
+
|
929
|
+
As was already explained, different programs require different
|
930
|
+
ways to determine which version is installed. Some projects
|
931
|
+
would allow more than one way, such as the --version flag,
|
932
|
+
but also querying .pc files. Ruby, for example, supports both
|
933
|
+
--version, and comes with a .pc file (if you compiled it from
|
934
|
+
source, at the least).
|
935
|
+
|
936
|
+
So, which way to choose?
|
937
|
+
|
938
|
+
In my opinion, .pc files are better than --version, for
|
939
|
+
at the least two reasons:
|
940
|
+
|
941
|
+
- The resulting code to handle this is much simpler. .pc
|
942
|
+
files are quite uniform, whereas the output of --version
|
943
|
+
is very dissimilar between different programs.
|
944
|
+
|
945
|
+
- Another reason is that invoking the binary, just to
|
946
|
+
do a --version, is actually more expensive (CPU-wise)
|
947
|
+
than it is to query a simple text file, which is
|
948
|
+
essentially what .pc files are. So this is another reason
|
949
|
+
in favour of .pc files.
|
950
|
+
|
951
|
+
For these reasons, and a few smaller ones, the EnvironmentInformation
|
952
|
+
project will try to prefer .pc files whenever that is possible.
|
953
|
+
We may retain code that can handle --version calls, though,
|
954
|
+
if they need a special way to query.
|
955
|
+
|
956
|
+
## Querying all registered pkg-config entries
|
957
|
+
|
958
|
+
To show all registered pkg-config entries (with .pc files)
|
959
|
+
do this:
|
960
|
+
|
961
|
+
envi --pkgconfig
|
962
|
+
|
963
|
+
If you want to obtain an Array of all outdated programs
|
964
|
+
on the target computer system, try this method:
|
965
|
+
|
966
|
+
EnvironmentInformation.return_array_of_outdated_programs
|
967
|
+
|
968
|
+
You need to have initialized the main hash once, before
|
969
|
+
being able to make use of that method.
|
970
|
+
|
971
|
+
## Quickly showing the version of individual programs
|
972
|
+
|
973
|
+
You can show the version of individual programs
|
974
|
+
like this:
|
975
|
+
|
976
|
+
envi --bash
|
977
|
+
envi --brotli
|
978
|
+
|
979
|
+
This will only work if the program has been registered,
|
980
|
+
though - so the second variant will not work.
|
981
|
+
|
982
|
+
Also take note that this will be ultra-short output,
|
983
|
+
so nothing will be saved into a local file. The idea
|
984
|
+
here is that the user only wants to see the version
|
985
|
+
of the program at hand, such as the <b>bash shell</b>.
|
986
|
+
|
987
|
+
## Aliases to program names
|
988
|
+
|
989
|
+
For several reasons it may be useful to define some aliases
|
990
|
+
or shortcuts to registered names. For example, the input
|
991
|
+
name **yacc** should point to the program called **bison**,
|
992
|
+
and the input name **diff** should really be an abbreviation
|
993
|
+
for **diffutils**. This allows the user to use the
|
994
|
+
environment_information project in a more convenient manner.
|
995
|
+
|
996
|
+
Currently these aliases are hardcoded, defined in the
|
997
|
+
method called **EnvironmentInformation.return_alias_to()**.
|
998
|
+
|
999
|
+
If no alias is found then the method will simply return
|
1000
|
+
the original input argument. This allows us to use this
|
1001
|
+
method as a 'sanitizer' or filter.
|
1002
|
+
|
1003
|
+
## GUIs - Graphical User Interfaces
|
1004
|
+
|
1005
|
+
A few bindings exist, to ruby-gtk3 and ruby-libui. These are
|
1006
|
+
mostly just demos, proof-of-concept. They are not really very
|
1007
|
+
elegant or sophisticated - I really only wanted to show how
|
1008
|
+
to embed the information gained from the commandline via
|
1009
|
+
a GUI as well.
|
1010
|
+
|
1011
|
+
## Support for KDE
|
1012
|
+
|
1013
|
+
If you have the RBT gem installed (gem install rbt) then you
|
1014
|
+
can invoke envi via:
|
1015
|
+
|
1016
|
+
envi --kde?
|
1017
|
+
|
1018
|
+
Since as of August 2022 this will try to show the versions
|
1019
|
+
of installed KDE applications.
|
1020
|
+
|
1021
|
+
This currently does not work very well; at a later point
|
1022
|
+
this will be polished and improved.
|
1023
|
+
|
1024
|
+
## Bugs and other misbehaviours
|
1025
|
+
|
1026
|
+
I noticed a few bugs here and there over the years. For instance,
|
1027
|
+
sometimes there may not be any output and the program stops
|
1028
|
+
working suddenly. This sometimes happens because there is some
|
1029
|
+
error in the underlying way how EnvironmentInformation obtains
|
1030
|
+
the version-information. In the long run I intend to improve
|
1031
|
+
the situation, by no longer falling into such issues - but
|
1032
|
+
they are not easily reproducible on my system. Either way I
|
1033
|
+
added this subsection in November 2021, to lessen the confusion
|
1034
|
+
for users at the least a little bit. And, again, as said, in
|
1035
|
+
the long run the code will change so as to not run into such
|
1036
|
+
situations anymore.
|
1037
|
+
|
1038
|
+
To provide a specific example: there may be instances of
|
1039
|
+
emacs about, such as on antiX, which simply did not
|
1040
|
+
provide any output. When I compiled emacs from source, it
|
1041
|
+
worked fine - so always check that the program works as
|
1042
|
+
assumed it **should** work.
|
1043
|
+
|
1044
|
+
ADD_CONTACT_INFORMATION
|