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

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

Post by desertcat » 2018/07/18 19:30:55

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 installed 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.

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 20:18:20

Just for FUN I decided to go to /usr/bin/inxi just to see what I could see and looked under COLORS and found the following:

sub set_status {
$status{'console'} = (defined $colors{'console'}) ? "Set: $colors{'console'}" : 'Not Set'
$status{'virt-term'} = (defined $colors{'virt-term'}) ? "Set: $colors{'virt-term'}" : 'Not Set';
$status{'irc-console'} = (defined $colors{'irc-console'}) ? "Set: $colors{'irc-console'}" : 'Not Set';
$status{'irc-gui'} = (defined $colors{'irc-gui'}) ? "Set: $colors{'irc-gui'}" : 'Not Set';
$status{'irc-virt-term'} = (defined $colors{'irc-virt-term'}) ? "Set: $colors{'irc-virt-term'}" : 'Not Set';
$status{'global'} = (defined $colors{'global'}) ? "Set: $colors{'global'}" : 'Not Set';
}

This corresponds well with the former Arguments:

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=''


Which corresponds with the problem that started it all:

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.

I wonder if you could set the DEFAULT_COLOR_SCHEME here by adding a line:

sub set_status {
$status{'default'} = (defined $colors{'default'}) ? "Set: $colors{'default'}" : '28';
}

I wonder if you could do that?? That is the ONLY file I can find that deals with inxi.

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 21:10:38

Thanks for following up on this.

When you set the colors, whether you do it manually by editing the inxi.conf file, or if you use the inxi -c 94-99 color editor, if that color is set for the user you are running inxi as, it will use those colors.

After checking, I found that the feature that was supposed to remove the global color setting when a non global was selected had simply been left out, I forgot, that is, to make the function that the text said would be there, removing the global when non global is selected.

Global is a very powerful item for colors, since it's an absolute override of all other color options.

Note that if /etc/inxi.conf has the global color set, that will override all other colors set in user config files. Obviously that should never be put in /etc/inxi.conf for that reason.

I am curious how your files came to have this syntax, and I hope that was never a default in centos or redhat.
Last edited by h2-1 on 2018/07/18 21:48:54, edited 2 times in total.

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 21:24:35

$status{...} is just setting the print values for output.

I'd forgotten about that, but in fact, it was already telling you/me that global was set, as it should have. But the meaning of that is not sufficiently clear, that is, if global color is set, then you must unset the colors completely, and, if /etc/inxi.conf is set with that, which it never should have been (that's the kind of thing I can see someone doing then forgetting all about until later, like, now).

However, it looks like there might be a bug in the individual scheme removing global color settings, as noted, that was supposed to have been added and I simply forgot to add the remove global even though the text said it would happen.

note that this fix does not change the corrupted file issue, but does correct global / non global clearing of previous values as expected.
Last edited by h2-1 on 2018/07/18 21:47:12, edited 1 time in total.

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 21:36:18

Your case did expose an actual bug, as I noted, what was supposed to happen when you selected a color scheme that is not global, it was supposed to unset and remove the global color scheme, for the user config file in question.

This was not happening, only global was removing all other color schemes, but I'd forgotten to add in the remove global feature when non global is selected.

Note that if /etc/inxi.conf had a global color scheme in it, this would not help because that global would still override everything else, I think.

The color selector does show the color selections for each type, so that was all correct, but the text that said the non global color selection would remove the global was never actually turned into code, so thanks for finding this glitch.

Given this is a real bug, I'll probably be doing inxi 3.0.19 sooner than later since I tend to release new versions if I'm aware of a real bug that has been corrected.

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/19 03:35:55

Just to clarify, because I think there is some confusion, aside from the global/specific color scheme reset bug:

1. a global color scheme in /etc/inxi.conf will override all subsequent user configuration values, unless one of them is also global.
2. a specific color scheme in /etc/inxi.conf will override all colors for a user until they set their own specific color scheme.
3. corrupted color scheme values as in your example will always show errors, and if in /etc/inxi.conf will continue to show errors until you remove or comment out with a leading # those lines from the config file.
4. selecting remove all color schemes option in the config tool will remove all the color schemes for the user you are running inxi as config file, but all remaining color schemes from /etc/inxi.conf will continue to operate.
5. inxi will create its own config file as you'd expect for the user running it, but it will never touch /etc/inxi.conf. What distro packagers do or do not do in terms of creating or not creating an /etc/inxi.conf file has nothing to do with how inxi runs unless they made a mistake. The config file is not needed to run inxi, it just contains optional things to set inxi to do, sizes, colors, various values, etc, that can override internal defaults. Most distro packagers I am aware of either do not make one, or put only one single, non color/size oriented config item in the main /etc/inxi.conf file.

The short story is that you should basically never put color schemes in /etc/inxi.conf unless you are aware of what that means, and remember you did it. As a system default (in the /etc/inxi.conf created by the packager, that is) it should probably in general never be done, particularly never for global color schemes, unless, again, you are fully aware you have done this, and remember that fact. For instance, if you want all your colors to be the same in console, terminal, gui applications, irc, for root and all users, setting a global color scheme value in /etc/inxi.conf would work well, as long as you remembered that fact. Since users can and do change the background colors in terminals and irc clients, you obviously would never want to set a color scheme for all users in /etc/inxi.conf unless it is one safe for dark, medium, and light backgrounds, and even then, it's annoying since it's hard to explain to people how to fix that.

Note that inxi color selector does tell you the current active state of the colors for each type, but it does not tell you which file it comes from, for the simple reason that it does not and cannot know that, those tests simply cascade up from /etc/inxi.conf to your local user config file values, the latter overriding the former. You could, that is, if you have /etc/inxi.conf set with global color scheme, override that with another global color scheme in your user config file, but you cannot override global color scheme itself being active until you remove that physically from /etc/inxi.conf.

I believe this basically explains the issue, and the bug fix in pinxi (wget smxi.org/pinxi as a short cut to github pinxi) can be viewed but keep in mind that pinxi uses pinxi.conf files, not inxi.conf, so any tests you would do using pinxi would require the relevant pinxi.conf files.

I think this basically resolves the parts of this issue that I can do something about, the corrupted values that might be in /etc/inxi.conf are not issues I can solve since those are simply an error which inxi can't solve.

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/19 05:43:11

h2-1 wrote:
2018/07/19 03:35:55
Just to clarify, because I think there is some confusion, aside from the global/specific color scheme reset bug:

1. a global color scheme in /etc/inxi.conf will override all subsequent user configuration values, unless one of them is also global.
2. a specific color scheme in /etc/inxi.conf will override all colors for a user until they set their own specific color scheme.
3. corrupted color scheme values as in your example will always show errors, and if in /etc/inxi.conf will continue to show errors until you remove or comment out with a leading # those lines from the config file.
4. selecting remove all color schemes option in the config tool will remove all the color schemes for the user you are running inxi as config file, but all remaining color schemes from /etc/inxi.conf will continue to operate.
5. inxi will create its own config file as you'd expect for the user running it, but it will never touch /etc/inxi.conf. What distro packagers do or do not do in terms of creating or not creating an /etc/inxi.conf file has nothing to do with how inxi runs unless they made a mistake. The config file is not needed to run inxi, it just contains optional things to set inxi to do, sizes, colors, various values, etc, that can override internal defaults. Most distro packagers I am aware of either do not make one, or put only one single, non color/size oriented config item in the main /etc/inxi.conf file.

The short story is that you should basically never put color schemes in /etc/inxi.conf unless you are aware of what that means, and remember you did it. As a system default (in the /etc/inxi.conf created by the packager, that is) it should probably in general never be done, particularly never for global color schemes, unless, again, you are fully aware you have done this, and remember that fact. For instance, if you want all your colors to be the same in console, terminal, gui applications, irc, for root and all users, setting a global color scheme value in /etc/inxi.conf would work well, as long as you remembered that fact. Since users can and do change the background colors in terminals and irc clients, you obviously would never want to set a color scheme for all users in /etc/inxi.conf unless it is one safe for dark, medium, and light backgrounds, and even then, it's annoying since it's hard to explain to people how to fix that.

Note that inxi color selector does tell you the current active state of the colors for each type, but it does not tell you which file it comes from, for the simple reason that it does not and cannot know that, those tests simply cascade up from /etc/inxi.conf to your local user config file values, the latter overriding the former. You could, that is, if you have /etc/inxi.conf set with global color scheme, override that with another global color scheme in your user config file, but you cannot override global color scheme itself being active until you remove that physically from /etc/inxi.conf.

I believe this basically explains the issue, and the bug fix in pinxi (wget smxi.org/pinxi as a short cut to github pinxi) can be viewed but keep in mind that pinxi uses pinxi.conf files, not inxi.conf, so any tests you would do using pinxi would require the relevant pinxi.conf files.

I think this basically resolves the parts of this issue that I can do something about, the corrupted values that might be in /etc/inxi.conf are not issues I can solve since those are simply an error which inxi can't solve.
One teeny tiny fly [a bug Heheheheh] in the ointment: there is also NO /etc/inxi.conf. The ONLY file that seems to do anything is the one in /usr/bin/inxi. The only files that have some bearing are in

/root/.local/share/inxi
/root/.local/share/inxi/location-main.txt
/root/.local/share/inxi/weather-32.2448-110.9232.txt
/root/.local/share/inxi/weather-32.4304-111.0377.txt

...and....

/home/cat/.local/share/inxi
/home/cat/.local/share/inxi/location-main.txt
/home/cat/.local/share/inxi/weather-32.4304-111.0377.txt

In short there is not a SINGLE inxi.conf file to be found anywhere in inxi-3.0.14-1.el7.noarch. Not in /etc, not in /root, not in /home/[usr] -- NONE! ZERO! ZILCH!! It *seems* as though /usr/bin/inxi is acting as the master file, but does not create the would be expected inxi.conf files that would allow for configurations, thus the best that one can do is to set the color option at the time you evoke inxi and set options at the CLI. I *think* this *might* be a fly (see "bug" Hehehe) that might be restricted to inxi-3.0.14-1.el7.noarch, and may not be found in versions 3.0.15, .. 16, ..17, ..18, or ..19. Hopefully when R.H. / CentOS updates inxi to the NEXT version of inxi this bug will disappear. For the time being until R.H. / CentOS rolls out that update the best thing to do for those who actually use inxi to use the following command structure:

inxi -c [0-32] (or leave blank to accept the default color option) - option - option -option ...

Thank you for all your help. It at least helps to clarify what has gone on. Maybe someone can hack a work around but it seems far easier to simply set the color option at the CLI.

Desert Cat

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/19 07:04:04

I just tested, removed /home/user2/.conf/pinxi.conf tested, it's gone, colors return to default.

Run pinxi -c 95 as user2, select a color, it switches, writes it to a new config file, run pinxi again, and it's all fine, new colors.

Code: Select all

cat /home/user2/.config/pinxi.conf
VIRT_TERM_COLOR_SCHEME=31
this program does not have the power to selectively decide to not create or not create configuration files when asked to do so, so there's clearly something else going on.

Since the configuration files posted clearly showed corruptions in the data, it's only guesswork on my part what created that corruption.

This sounds like a local problem on your system to me, you have the right to create and write to files owned by you, and you are running inxi as a user, who has permissions to write and create files to their own home directory, so your conclusion doesn't make any sense.

Either there's a bug or there isn't a bug.

I've already said that there was a bug currently fixed in latest commits of pinxi (NOT inxi, note, and certainly not in your distro package version) that kept it from removing the global color option when another one was selected.

But the notion that you can't create and write to files owned by you makes zero sense, and it certainly would not be something that manifested randomly, as in, one system decides to let users create and write to their own files in their own home directory, and one doesn't.

There's a possible alternate option, which is the XDG locations, which make this type of question even worse and harder to support than it should be, which is sadly pretty much normal for new 'standards' that are supposed to replace old standards but just serve to make things even more complicated and harder to debug for end users, since they have to then learn more stuff to check, for no gain.

But the notion that you can't get sticky colors after using clean slate of no config files is simply not correct, and if that is what you are experiencing, that means there is a problem with your system file permissions or ownership, far outside of my ability to diagnose or solve, but certainly unrelated to anything inxi is doing or not doing. Unless there's something specific with CentOS that I don't know about in terms of how it assigns permissions to users in their own configuration files and directories.

This is the type of thing that almost certainly when or if you figure it out you'll slap your head and go, oh, man, dugh, how obvious, or something along those lines.

Note I just empirically verified by deleting the user config file, running pinxi ( I don't normally mess around with my default inxi stuff since I like that to be the same always), seeing the colors revert to default, then setting the colors with in my case -c95. Are you sure you are acctually picking the right color option? For all I know you are picking the wrong one then not seeing the change, make sure to actually check your config file after you set it, the odds are high you are setting the wrong color value for the terminal you are testing in.

Or just set the global, that will change all the display defaults.

The bright side here is that I did find and fix one oversight with the global colors not getting removed when specific ones were picked.

For more on colors, see the man page, that's got a reasonably complete explanation.

It's absolutely and totally irrelevant if you have or do not have the core file /etc/inxi.conf, I'm just guessing here since I have very little concrete to go on based on your statements, that was just a guess I made re the global stuff being stuck, but inxi is going to tell you everything you need to know, and it will tell you which file it updated as well, all the data you need to resolve this issue for yourself is right there on the screen output, which is why I put it there, you just have to read it.

Note: it will tell you which color options are set, or unset, it will tell you where the config file is, and it will show the change when you type in the number, and then you will see it not work or work when you run inxi again, this is all strictly empirical, and you can then open the config file and read it, and see what happened. But I can't do any of that for you, on my end, this is all now correct (except for the bug still in your inxi version about not removing global colors if a specific color is selected).

This is about as far as I can go to help your issue since it's either a mistake you keep making without realizing you are making it, or it's a permissions issue in your system, but given you can just check A: what settings you have made in your config file that inxi reads, and it tells you, and B: what the config file itself says, there's no point in doing circular type reasoning when you have ALL the data right there on your desktop.

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/19 07:14:23

Just as an aside, I personally like the inxi colors, and they are the first things I usually set on a new system I'm testing on, so I use this color selector a lot, though I don't generally use the global option, which is how I missed that particular bug. By definition these are usually new systems I haven't run inxi on before, and I'm never using packaged inxi since those always lag way too far behind for my uses of testing and debugging, so there is never a pinxi.conf file anywhere on the system when I start, and they always get created without problems.

Which makes me suspect you are simply doing something slightly off or wrong, but you can verify that by simply opening the file after its made, and if it wasn't made, checking your permissions to figure out why it wasn't made. Note that inxi would have exited with error had it been unable to open that file for writing, telling you this clearly, so it's really unlikely that's the case, which points to some type of odd user error to me, though you can never be sure, there are always fringe cases of odd systems, but this would have to be really fringe since it gets checked at every point.

If I were you, I'd spend less mental effort on trying to figure out why something that should always work isn't, and more on looking at the specifics of every part of your particular system that could lead this type of issue, including user error, making the same mistake over and over, without realizing it, which is currently my best guess since that's something we all do, only we fail to see we are doing it, that's really common.

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/19 07:25:52

the reason that that the only file that seems to do anything is /usr/bin/inxi is that is the program. It creates, under normal circumstances, and I stress normal as in always in correctly configured systems (with one exception, chromebooks, which have a messed up permissions situation, a user reported that issue to me a while ago but I can't change that), a configuration file if one is not there when you run the -c95 color selector for your gui terminal window colors, and it tells you the path, you have to open that file, read it, and if it did not get created after you set the colors, you have to check the permisssions on that directory, which is usually .config/ and figure out why you failed to be able to write to it, as in, creating and updating a new file.

Again, don't worry about what you believe inxi is doing, worry about the configuration file, and if it's getting created and updated, or not. If not, then worry about your system permissions, and why they are broken. Also, after you create the configuration color selection, run: updatedb as root then locate inxi.conf to find where it is, in case something weird is going on.

Note that when inxi starts, it determines the preferred path the config file shouild go to based on tests, and that path is what the color selector tool tells you is the path, so that's the file inxi is going to write to and read from.

Post Reply