I want to ERASE Inxi, BUT.. Advice Needed!! TrevorH?

General support questions
desertcat
Posts: 843
Joined: 2014/08/07 02:17:29
Location: Tucson, AZ

I want to ERASE Inxi, BUT.. Advice Needed!! TrevorH?

Post by desertcat » 2018/07/15 10:57:18

A utility called inxi that has been working well has gone out into the weeds. SOLUTION: ERASE and RE-INSTALL... but...

yum erase inxi gives me the following:


yum erase inxi
Loaded plugins: fastestmirror, langpacks, nvidia, priorities
Resolving Dependencies
--> Running transaction check
---> Package inxi.noarch 0:3.0.14-1.el7 will be erased
--> Processing Dependency: inxi for package: xapps-1.0.4-12.el7.x86_64
--> Running transaction check
---> Package xapps.x86_64 0:1.0.4-12.el7 will be erased
--> Processing Dependency: libxapp.so.1()(64bit) for package: nemo-3.6.5-1.el7.x86_64
--> Processing Dependency: xapps for package: mintlocale-1.4.4-1.el7.noarch
--> Processing Dependency: xapps(x86-64) = 1.0.4-12.el7 for package: python2-xapps-overrides-1.0.4-12.el7.x86_64
--> Processing Dependency: xapps(x86-64) for package: cinnamon-screensaver-3.6.1-2.el7.x86_64
--> Processing Dependency: xapps(x86-64) for package: cinnamon-3.6.7-3.el7.x86_64
--> Processing Dependency: xapps(x86-64) = 1.0.4-12.el7 for package: python34-xapps-overrides-1.0.4-12.el7.x86_64
--> Running transaction check
---> Package cinnamon.x86_64 0:3.6.7-3.el7 will be erased
---> Package cinnamon-screensaver.x86_64 0:3.6.1-2.el7 will be erased
---> Package mintlocale.noarch 0:1.4.4-1.el7 will be erased
---> Package nemo.x86_64 0:3.6.5-1.el7 will be erased
--> Processing Dependency: nemo(x86-64) = 3.6.5-1.el7 for package: nemo-extensions-3.6.5-1.el7.x86_64
---> Package python2-xapps-overrides.x86_64 0:1.0.4-12.el7 will be erased
---> Package python34-xapps-overrides.x86_64 0:1.0.4-12.el7 will be erased
--> Running transaction check
---> Package nemo-extensions.x86_64 0:3.6.5-1.el7 will be erased
--> Finished Dependency Resolution

Dependencies Resolved

=======================================================================================================================================
Package Arch Version Repository Size
=======================================================================================================================================
Removing:
inxi noarch 3.0.14-1.el7 @epel 839 k
Removing for dependencies:
cinnamon x86_64 3.6.7-3.el7 @epel 7.6 M
cinnamon-screensaver x86_64 3.6.1-2.el7 @epel 1.0 M
mintlocale noarch 1.4.4-1.el7 @epel 95 k
nemo x86_64 3.6.5-1.el7 @epel 4.6 M
nemo-extensions x86_64 3.6.5-1.el7 @epel 253 k
python2-xapps-overrides x86_64 1.0.4-12.el7 @epel 1.2 k
python34-xapps-overrides x86_64 1.0.4-12.el7 @epel 1.2 k
xapps x86_64 1.0.4-12.el7 @epel 5.7 M


I said NO!!! and backed out until I checked with you guys. I've been burned more than once trying to erase a single package, only to have it dependency upon dependency. All those dependencies have me worried if I erase the target (inxi) it might screw up something else. I haven't a clue what "xapps" is or what it does. then there is python, and I'm not sure what "mintlocal" is.

As a side note Installed inxi on "jaguar", updated the machine, and had no problem running inxi. Just for fun I erased inxi from "jaguar" , and the ONLY package removed was inxi -- there wasn't a single dependency that was erased. I then re-installed it and it still works fine. Something tells me when I last updated this machine I got crossed dependencies be they xapps, python, mintlocal, or nemo. Any advice you can provide would be welcome.
Last edited by desertcat on 2018/07/15 11:07:21, edited 1 time in total.

User avatar
TrevorH
Site Admin
Posts: 33202
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: I want to ERASE Inxi, BUT.. Advice Needed!! TrevorH?

Post by TrevorH » 2018/07/15 11:07:04

If rpm -V inxi returns with no output then all files supplied by the package are already correct and a reinstall will make no difference. In any case, if all you want to do is to reinstall it then yum reinstall inxi will do that but it's pointless if rpm -V says that everything is as it should be. If that's the case then any problem you have with it is likely to be with local data files (i.e. stuff under /home/$USER stashed there by the app) and removing and reinstalling the package will not touch those.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

desertcat
Posts: 843
Joined: 2014/08/07 02:17:29
Location: Tucson, AZ

Re: I want to ERASE Inxi, BUT.. Advice Needed!! TrevorH?

Post by desertcat » 2018/07/15 11:21:20

TrevorH wrote:
2018/07/15 11:07:04
If rpm -V inxi returns with no output then all files supplied by the package are already correct and a reinstall will make no difference. In any case, if all you want to do is to reinstall it then yum reinstall inxi will do that but it's pointless if rpm -V says that everything is as it should be. If that's the case then any problem you have with it is likely to be with local data files (i.e. stuff under /home/$USER stashed there by the app) and removing and reinstalling the package will not touch those.
OK tried it it gave me back a prompt, and then I ran yum reinstall inxi which it did. I then ran "inxi" and here is what came back:

inxi -xxx -i -S -C -s -w
Argument "" isn't numeric in int at /usr/bin/inxi line 1056, <$fh> line 2.
Argument "" isn't numeric in int at /usr/bin/inxi line 1057, <$fh> line 3.
Argument "" isn't numeric in int at /usr/bin/inxi line 1058, <$fh> line 4.
Argument "" isn't numeric in int at /usr/bin/inxi line 1059, <$fh> line 5.
Argument "" isn't numeric in int at /usr/bin/inxi line 1047, <$fh> line 6.
Argument "" isn't numeric in int at /usr/bin/inxi line 1060, <$fh> line 7.

System: Host: leopard.rc.arizona.edu Kernel: 3.10.0-862.6.3.el7.x86_64 x86_64 bits: 64 compiler: gcc
v: 4.8.5 Desktop: KDE 4.14.8 tk: Qt 4.8.7 info: kdeinit4: wm: KWin dm: lightdm 1.25.0,sddm
Distro: CentOS Linux release 7.5.1804 (Core)
CPU: Topology: 6-Core model: AMD FX-6300 bits: 64 type: MCP arch: Bulldozer L2 cache: 2048 KiB
flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 42141
Speed: 1400 MHz min/max: 1400/3500 MHz Core speeds (MHz): 1: 1400 2: 3500 3: 1400 4: 2000 5: 1400
6: 1400
Network: Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 v: 2.3LK-NAPI
port: d000 bus ID: 02:00.0 chip ID: 10ec:8168
IF: enp2s0 state: up speed: 10 Mbps duplex: half mac: 40:16:7e:22:4d:af
IP v4: 192.168.2.8/24 type: noprefixroute scope: global broadcast: 192.168.2.255
IP v6: fe80::4216:7eff:fe22:4daf/64 type: noprefixroute scope: link
IF-ID-1: virbr0 state: down mac: 52:54:00:76:5c:81
IP v4: 192.168.122.1/24 scope: global broadcast: 192.168.122.255
IF-ID-2: virbr0-nic state: down mac: 52:54:00:76:5c:81
WAN IP: 174.18.14.27
Sensors: System Temperatures: cpu: 50.4 C mobo: 39.0 C gpu: nvidia temp: 42 C
Fan Speeds (RPM): cpu: 1527 fan-2: 1757 fan-3: 1691
Voltages: 12v: N/A 5v: N/A 3.3v: 3.24 vbat: 3.31
Weather: Temperature: 24 C (76 F) Conditions: Overcast Wind: from East at 2.2 m/s (8 km/h, 5 mph)
Humidity: 77% Pressure: 1012 mb (29.90 in) Dew Point: 20 C (68 F) Location: Tucson, AZ, USA
altitude: 738 m (2420 ft) Current Time: Sun 15 Jul 2018 04:11:38 AM MST (America/Phoenix)
Observation Time: Sun 15 Jul 2018 03:58:00 AM MST

The BOLD portion is brand new -- it just popped up -- and does NOT show up on "jaguar" aka the "Trashcan Monster". What is this "xapps" and what does it do?!?

User avatar
TrevorH
Site Admin
Posts: 33202
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: I want to ERASE Inxi, BUT.. Advice Needed!! TrevorH?

Post by TrevorH » 2018/07/15 11:41:11

Those are bugs in the inxi script. If you look at /usr/bin/inxi you will find that lines 1047-1060 are

Code: Select all

        elsif ($key eq 'WEATHER_UNIT') {
                $val = lc($val) if $val;
                if ($val && $val =~ /^(c|f|cf|fc|i|m|im|mi)$/){
                        my %units = ('c'=>'m','f'=>'i','cf'=>'mi','fc'=>'im');
                        $val = $units{$val} if defined $units{$val};
                        $weather_unit = $val;
                }
        }
        # layout
        elsif ($key eq 'CONSOLE_COLOR_SCHEME') {$colors{'console'} = int($val)}
        elsif ($key eq 'GLOBAL_COLOR_SCHEME') {$colors{'global'} = int($val)}
        elsif ($key eq 'IRC_COLOR_SCHEME') {$colors{'irc-gui'} = int($val)}
        elsif ($key eq 'IRC_CONS_COLOR_SCHEME') {$colors{'irc-console'} = int($val)}
        elsif ($key eq 'IRC_X_TERM_COLOR_SCHEME') {$colors{'irc-virt-term'} = int($val)}
All of the lines it's complaining about are testing various environment variables and setting values in an array to whatever their values are. I'd suggest looking to see what those environment variables are set to on your machine. You might also want to check that your version of the inxi script is the same as mine and that the line numbers in question are the samein your copy as in mine.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

desertcat
Posts: 843
Joined: 2014/08/07 02:17:29
Location: Tucson, AZ

[SOLVED] I want to ERASE Inxi, BUT.. Advice Needed!! TrevorH?

Post by desertcat » 2018/07/17 09:30:15

TrevorH wrote:
2018/07/15 11:41:11
Those are bugs in the inxi script. If you look at /usr/bin/inxi you will find that lines 1047-1060 are

Code: Select all

        elsif ($key eq 'WEATHER_UNIT') {
                $val = lc($val) if $val;
                if ($val && $val =~ /^(c|f|cf|fc|i|m|im|mi)$/){
                        my %units = ('c'=>'m','f'=>'i','cf'=>'mi','fc'=>'im');
                        $val = $units{$val} if defined $units{$val};
                        $weather_unit = $val;
                }
        }
        # layout
        elsif ($key eq 'CONSOLE_COLOR_SCHEME') {$colors{'console'} = int($val)}
        elsif ($key eq 'GLOBAL_COLOR_SCHEME') {$colors{'global'} = int($val)}
        elsif ($key eq 'IRC_COLOR_SCHEME') {$colors{'irc-gui'} = int($val)}
        elsif ($key eq 'IRC_CONS_COLOR_SCHEME') {$colors{'irc-console'} = int($val)}
        elsif ($key eq 'IRC_X_TERM_COLOR_SCHEME') {$colors{'irc-virt-term'} = int($val)}
All of the lines it's complaining about are testing various environment variables and setting values in an array to whatever their values are. I'd suggest looking to see what those environment variables are set to on your machine. You might also want to check that your version of the inxi script is the same as mine and that the line numbers in question are the samein your copy as in mine.
Thank you TrevorH!!! After reading your post my thinking went off in a different direction. I asked my buddy to run the inxi command to see if he came up with the exact same results I did. Yep he came up with the exact same Argument jazz:

Argument "" isn't numeric in int at /usr/bin/inxi line 1056, <$fh> line 2.
Argument "" isn't numeric in int at /usr/bin/inxi line 1057, <$fh> line 3.
Argument "" isn't numeric in int at /usr/bin/inxi line 1058, <$fh> line 4.
Argument "" isn't numeric in int at /usr/bin/inxi line 1059, <$fh> line 5.
Argument "" isn't numeric in int at /usr/bin/inxi line 1047, <$fh> line 6.
Argument "" isn't numeric in int at /usr/bin/inxi line 1060, <$fh> line 7.

This proved that it was not just my machine that went out into the weeds.

A little hacking found that there are two config files that inxi used/uses: One is in /home/[usr]/.config/inxi.conf

The second one if you are running this system wide is in /root/.config/inxi.conf. After copying those two files to a safe backup place I DELETED both of the files and PRESTO!! No more Arguments!!! The downside is it gives you a single default color scheme. This problem was also [SOLVED] by appending the color code you wish at the front of the of command string. Whereas before I used inxi -xxx -i -S -C -s -w I now issue the command inxi -c 28 -xxx -i -S -C -s -w. I tried to make the preferred color global but without success. Appending the color code to the front of the command is a cheap hack that works.

As to WHY this program suddenly went out into the weeds after running flawlessly for YEARS, no idea. My buddy noted that there was a recent update to inxi [28 June 2018].

Mark this problem [SOLVED]. If anyone figures out to how to make the color global please let us know.

Thanks

h2-1
Posts: 11
Joined: 2018/07/17 16:19:08

Re: I want to ERASE Inxi, BUT.. Advice Needed!! TrevorH?

Post by h2-1 » 2018/07/17 16:33:15

In general, when you have an issue with a piece of software, you should post that issue on the upstream software issues page, at least if you want it resolved.

It's clear you had some type of corruption in your configuration file(s), so it would be useful to see the actual contents of them. All of them. Do:

Code: Select all

locate inxi.conf
The new inxi was heavily beta tested, by hundreds of people, not one of whom experienced this issue, so it's obvious there is something odd going on with the configuration syntax used.

The warnings there are simply Perl complaining about having received a non integer value where one was expected. There is no way for that to be incorrect unless the actual config syntax itself was / is wrong to begin with. The number of warnings you see are the number of corrupted config items there are in your config file.

So the question is, what is that config file content. Post the contents of your configs, verbatim, and I can tell you roughly why that happened.

The values being read are not environmental variables, they are the config file items, which you'll see as soon as you read the config file.

The only reason I can see for this is that config values, say:

Code: Select all

GLOBAL_COLOR_SCHEME=
was created but with no value. Less likely are the use of magic quotes, single or double, or maybe \r as a line ending, neither of which should ever happen in properly configured unix type systems. The correct way to remove a variable is to comment it out with #, or delete the line.

I wish I'd seen this type of issue during beta testing, or in the 30 or so releases since then, and I'll add in a bit of protection against that unforeseen situation, but my real question is what is the syntax, what created it, and how prevalent is it?

I think that aside from your config file corruption, you'll find the new inxi significantly better in every way, and once you figure out the cause of this corruption, which hopefully did NOT come from any defaults of Redhat or CentOS (those defaults should be filed as a bug against the packaging of inxi in centos/redhat if that's the case, since these config values should be commented out if not used).

Note that old inxi was gawk+bash, which is a sloppy, forgiving mix of languages, which you could feed any sorts of junk data internally and it would never have noticed, as well as having errors suppressed. Perl requires the data to be correct, and all error warnings are enabled, specifically so I can see these types of errors and try to get them resolved when they occur. This strictness is one of many reasons Perl5 is so fast, much faster than bash/gawk, since it doesn't have to guess at whether data is right or not every time it runs.

[update]
I've added protections against this type of config syntax error in the latest commit to the inxi-perl branch development version, pinxi, now it checks that the values it expects to be integers are actually integers, along with some other smaller protections against other possible user/config errors I'd simply never considered as something that would happen. But I would like to see what the syntax errors are there to make sure I've got all the possible cases covered.

Note that even when this goes into next inxi (3.0.19), that won't help distros that don't update their inxi versions, but again, nobody had this issue during extremely intensive testing for several months, so I doubt it's a widespread thing.

The result of that patch is to ignore all defective or corrupted configuration values, so you'd see no change at all, but in your version of inxi, you'd see the errors again, until you figured out what the corruption there is and removed it from the config items.

Note that for color selections, you simply run the inxi color selector, -c 94 to 99 which shows you the colors, lets you pick which you want, and correctly writes it to the config file. That had a small issue where if you just hit enter, it failed to validate the input and would write an empty value to the config file, that bug was corrected in 3.0.11. I believe inxi 2.3.xx had this issue as well, but it had no negative impact since bash/gawk are much sloppier than Perl.

desertcat
Posts: 843
Joined: 2014/08/07 02:17:29
Location: Tucson, AZ

Re: I want to ERASE Inxi, BUT.. Advice Needed!! TrevorH?

Post by desertcat » 2018/07/18 09:50:48

Glad to help:

Here is the the inxi.conf file for root (global) dated 13 Feb 2017 [/root/.config/inxi.conf]

DEFAULT_COLOR_SCHEME=28
GLOBAL_COLOR_SCHEME=''
IRC_COLOR_SCHEME=''
IRC_CONS_COLOR_SCHEME=''
IRC_X_TERM_COLOR_SCHEME=''
CONSOLE_COLOR_SCHEME=''
VIRT_TERM_COLOR_SCHEME=''


Here is the inxi.conf file for the users account dated 3Dec 2017 [/home/cat/.config/inxi.conf]

DEFAULT_COLOR_SCHEME=30
GLOBAL_COLOR_SCHEME=''
IRC_COLOR_SCHEME=''
IRC_CONS_COLOR_SCHEME=''
IRC_X_TERM_COLOR_SCHEME=''
CONSOLE_COLOR_SCHEME=''
VIRT_TERM_COLOR_SCHEME=''


running "inxi -xxx -i -S -C -s -w" gave=>

inxi -xxx -i -S -C -s -w
Argument "" isn't numeric in int at /usr/bin/inxi line 1056, <$fh> line 2.
Argument "" isn't numeric in int at /usr/bin/inxi line 1057, <$fh> line 3.
Argument "" isn't numeric in int at /usr/bin/inxi line 1058, <$fh> line 4.
Argument "" isn't numeric in int at /usr/bin/inxi line 1059, <$fh> line 5.
Argument "" isn't numeric in int at /usr/bin/inxi line 1047, <$fh> line 6.
Argument "" isn't numeric in int at /usr/bin/inxi line 1060, <$fh> line 7.

System: Host: leopard.rc.arizona.edu Kernel: 3.10.0-862.6.3.el7.x86_64 x86_64 bits: 64 compiler: gcc
v: 4.8.5 Desktop: KDE 4.14.8 tk: Qt 4.8.7 info: kdeinit4: wm: KWin dm: lightdm 1.25.0,sddm
Distro: CentOS Linux release 7.5.1804 (Core)
CPU: Topology: 6-Core model: AMD FX-6300 bits: 64 type: MCP arch: Bulldozer L2 cache: 2048 KiB
flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 42141
Speed: 1400 MHz min/max: 1400/3500 MHz Core speeds (MHz): 1: 1400 2: 3500 3: 1400 4: 2000 5: 1400
6: 1400
Network: Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 v: 2.3LK-NAPI
port: d000 bus ID: 02:00.0 chip ID: 10ec:8168
IF: enp2s0 state: up speed: 10 Mbps duplex: half mac: 40:16:7e:22:4d:af
IP v4: 192.168.2.8/24 type: noprefixroute scope: global broadcast: 192.168.2.255
IP v6: fe80::4216:7eff:fe22:4daf/64 type: noprefixroute scope: link
IF-ID-1: virbr0 state: down mac: 52:54:00:76:5c:81
IP v4: 192.168.122.1/24 scope: global broadcast: 192.168.122.255
IF-ID-2: virbr0-nic state: down mac: 52:54:00:76:5c:81
WAN IP: 174.18.14.27
Sensors: System Temperatures: cpu: 50.4 C mobo: 39.0 C gpu: nvidia temp: 42 C
Fan Speeds (RPM): cpu: 1527 fan-2: 1757 fan-3: 1691
Voltages: 12v: N/A 5v: N/A 3.3v: 3.24 vbat: 3.31
Weather: Temperature: 24 C (76 F) Conditions: Overcast Wind: from East at 2.2 m/s (8 km/h, 5 mph)
Humidity: 77% Pressure: 1012 mb (29.90 in) Dew Point: 20 C (68 F) Location: Tucson, AZ, USA
altitude: 738 m (2420 ft) Current Time: Sun 15 Jul 2018 04:11:38 AM MST (America/Phoenix)
Observation Time: Sun 15 Jul 2018 03:58:00 AM MST

As soon as I deleted both these files (the above are the actual files that were copied to a backup directory ) and ran

inxi -xxx -i -S -C -s -w I got the normal output minus the custom color set, and resulted in the default of Blue and Gray. To get the custom color set I had to append the color in front of the command: inxi -c 28 -xxx -i -S -C -s -w.

My first conclusion was I had a corrupt file but wanted to check it against my buddy's output and he got the exact same problem, so this was NOT a corrupt file on a single computer.

To test a theory I installed inxi-3.0.14-1.el7.noarch on a machine that this right now is serving as a "testbed" I then ran

inxi -xxx -i -S -C -s -w

and got NO argument problem. It is also telling that i also do not /did not get the /home/cat/.config/inxi.conf file created as I had with previous version I had running.

Hope this helps

desertcat
Posts: 843
Joined: 2014/08/07 02:17:29
Location: Tucson, AZ

Re: I want to ERASE Inxi, BUT.. Advice Needed!! TrevorH?

Post by desertcat » 2018/07/18 10:03:11

h2-1 wrote:
2018/07/17 16:33:15
In general, when you have an issue with a piece of software, you should post that issue on the upstream software issues page, at least if you want it resolved.

It's clear you had some type of corruption in your configuration file(s), so it would be useful to see the actual contents of them. All of them. Do:

Code: Select all

locate inxi.conf
The new inxi was heavily beta tested, by hundreds of people, not one of whom experienced this issue, so it's obvious there is something odd going on with the configuration syntax used.

The warnings there are simply Perl complaining about having received a non integer value where one was expected. There is no way for that to be incorrect unless the actual config syntax itself was / is wrong to begin with. The number of warnings you see are the number of corrupted config items there are in your config file.

So the question is, what is that config file content. Post the contents of your configs, verbatim, and I can tell you roughly why that happened.

The values being read are not environmental variables, they are the config file items, which you'll see as soon as you read the config file.

The only reason I can see for this is that config values, say:

Code: Select all

GLOBAL_COLOR_SCHEME=
was created but with no value. Less likely are the use of magic quotes, single or double, or maybe \r as a line ending, neither of which should ever happen in properly configured unix type systems. The correct way to remove a variable is to comment it out with #, or delete the line.

I wish I'd seen this type of issue during beta testing, or in the 30 or so releases since then, and I'll add in a bit of protection against that unforeseen situation, but my real question is what is the syntax, what created it, and how prevalent is it?

I think that aside from your config file corruption, you'll find the new inxi significantly better in every way, and once you figure out the cause of this corruption, which hopefully did NOT come from any defaults of Redhat or CentOS (those defaults should be filed as a bug against the packaging of inxi in centos/redhat if that's the case, since these config values should be commented out if not used).

Note that old inxi was gawk+bash, which is a sloppy, forgiving mix of languages, which you could feed any sorts of junk data internally and it would never have noticed, as well as having errors suppressed. Perl requires the data to be correct, and all error warnings are enabled, specifically so I can see these types of errors and try to get them resolved when they occur. This strictness is one of many reasons Perl5 is so fast, much faster than bash/gawk, since it doesn't have to guess at whether data is right or not every time it runs.

[update]
I've added protections against this type of config syntax error in the latest commit to the inxi-perl branch development version, pinxi, now it checks that the values it expects to be integers are actually integers, along with some other smaller protections against other possible user/config errors I'd simply never considered as something that would happen. But I would like to see what the syntax errors are there to make sure I've got all the possible cases covered.

Note that even when this goes into next inxi (3.0.19), that won't help distros that don't update their inxi versions, but again, nobody had this issue during extremely intensive testing for several months, so I doubt it's a widespread thing.

The result of that patch is to ignore all defective or corrupted configuration values, so you'd see no change at all, but in your version of inxi, you'd see the errors again, until you figured out what the corruption there is and removed it from the config items.

Note that for color selections, you simply run the inxi color selector, -c 94 to 99 which shows you the colors, lets you pick which you want, and correctly writes it to the config file. That had a small issue where if you just hit enter, it failed to validate the input and would write an empty value to the config file, that bug was corrected in 3.0.11. I believe inxi 2.3.xx had this issue as well, but it had no negative impact since bash/gawk are much sloppier than Perl.
OK I just ran locate inxi.conf Here is the output:

/backup/inxi.conf
/backup/inxi.conf.old
/backup2/tar/leopard/home/cat/inxi.conf
/backup2/tar/leopard/home/cat/.config/inxi.conf
/home/cat/inxi.conf

The output for /home/cat/inxi.conf date 13 Feb 2017 ==>

DEFAULT_COLOR_SCHEME=25
GLOBAL_COLOR_SCHEME=''
IRC_COLOR_SCHEME=''
IRC_CONS_COLOR_SCHEME=''
IRC_X_TERM_COLOR_SCHEME=''
CONSOLE_COLOR_SCHEME=''
VIRT_TERM_COLOR_SCHEME=''

Hope this helps.

h2-1
Posts: 11
Joined: 2018/07/17 16:19:08

Re: I want to ERASE Inxi, BUT.. Advice Needed!! TrevorH?

Post by h2-1 » 2018/07/18 17:42:35

As I suspected, you do have a corrupted inxi.conf file.

All the values you posted where the config item value is ='' are corrupted, those should never have been there in the first place.

Each of those config item rows should be one of the two:

1. commented out with #
2. deleted

My main concern is that CentOS or Redhat created this corruption for some unknown reason, and that this is the standard content of the packaged config files, which you can easily check by deleting all the config files, then uninstalling the package, then reinstalling it, then checking the config files again.

If the problem persists, this is a bug with the packaging of inxi, and should be reported to the appropriate packager.

While I've updated the checks to look for such errors in the config, that won't help users who are running pre inxi 3.0.19 versions, which hasn't been released yet, and probably won't be released for a few weeks since I've just released a small herd of inxis over the past weeks, but I may have to do one more to make sure this issue is corrected so that downstream can update.

It's always hard as a programmer to visualize the entire set of things that can be done wrong, and this error simply was not in the set of things I'd considered as a possible mistake end users or packagers would make, nor has it ever shown up previous to now, but that's why I now and then check online inxi reports, to see if any unknown and to me unreported issues are arising.

Note that as far as I can tell, the Fedora packaged inxi version does not have this issue, and I assume that's where the EPEL or other 3.0.14 etc versions are coming from, so I have to suspect a CentOS or Redhat specific config, though why that would exist is beyond me.

desertcat
Posts: 843
Joined: 2014/08/07 02:17:29
Location: Tucson, AZ

Re: I want to ERASE Inxi, BUT.. Advice Needed!! TrevorH?

Post by desertcat » 2018/07/18 19:29:46

h2-1 wrote:
2018/07/18 17:42:35
As I suspected, you do have a corrupted inxi.conf file.

All the values you posted where the config item value is ='' are corrupted, those should never have been there in the first place.

Each of those config item rows should be one of the two:

1. commented out with #
2. deleted

My main concern is that CentOS or Redhat created this corruption for some unknown reason, and that this is the standard content of the packaged config files, which you can easily check by deleting all the config files, then uninstalling the package, then reinstalling it, then checking the config files again.

If the problem persists, this is a bug with the packaging of inxi, and should be reported to the appropriate packager.

While I've updated the checks to look for such errors in the config, that won't help users who are running pre inxi 3.0.19 versions, which hasn't been released yet, and probably won't be released for a few weeks since I've just released a small herd of inxis over the past weeks, but I may have to do one more to make sure this issue is corrected so that downstream can update.

It's always hard as a programmer to visualize the entire set of things that can be done wrong, and this error simply was not in the set of things I'd considered as a possible mistake end users or packagers would make, nor has it ever shown up previous to now, but that's why I now and then check online inxi reports, to see if any unknown and to me unreported issues are arising.

Note that as far as I can tell, the Fedora packaged inxi version does not have this issue, and I assume that's where the EPEL or other 3.0.14 etc versions are coming from, so I have to suspect a CentOS or Redhat specific config, though why that would exist is beyond me.
Hummmmm. Just for FUN I went over to jaguar my "test bed" on which I just inxi-3.0.14-1.el7.noarch the other day and ran

Code: Select all

 locate inxi.conf 
And it just came back with a prompt ie. inxi.conf does not exist on that computer. On leopard, my workstation, on which I have been running inxi for years it finds the previous version's inxi.conf files, which seem to be in conflict with the current version ie inxi-3.0.14-1.el7.noarch, thus when inxi was updated to inxi-3.0.14-1.el7.noarch the old inxi.conf which should have been deleted were not... that or inxi-3.0.14-1.el7.noarch which *should* have created an inxi.conf file does not, though bizarrely when you type inxi it pops right up even without a .conf file.

BTW just for fun I restored the old backup files and deleted out the " marked lines and left ONLY the line that said "DEFAULT_COLOR_SCHEME=28" to see if I could set the COLOR.... Nope that did not work. I went back to jaguar and tried to set the default color there too... Nope that did not work either. the ONLY apparent way -- at least that I could find so far -- is to set color at the same time you set the other options (?) such as i, S,C,s,w. Something changed between the two versions. If you know some way to set the default color scheme please let me know. I'll try to hack around and see if I can stumble across the solution, though without a .conf file that is recognizable that may be a tall order. Probably easier to set color as an option and be done with it.

Post Reply