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

[desertcat]

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.

[Smack head!!!] Yep that inxi -c 95 color selector followed by a number (26) fixed the problem... and created a NEW inxi.conf file under /home/cat/.config/inxi.conf. . A review of the contents of the file show:

Code: Select all

 VIRT_TERM_COLOR_SCHEME=26 

...and nothing else which is different than the previous /.config/inxi.conf which had DEFAULT_COLOR_SCHEME=28.

Probably a bad case of "Set it and forget it": One forgets how one did something a few years ago... until something goes wrong. Will pass this along to my buddy.

Thank you for all your help.

Sincerely,

Desert Cat

[h2-1]

Thank you for following up/through.

We've all done the set it and forget it, lol, so I had to start suspecting that was the case.

However, with this said, there was a bug in the inxi color setting logic, and that bug was a real bug, which was selecting non global value would fail to delete global, even though the words on the output said it would do just that, so I'm glad you posted this issue or I would not have found that bug for a long time.

When I run across issues like this I have to try to figure out if there is a new variant of something unknown that inxi has to work around, or if it's just a sort of fluke, so I like to pursue them until they are totally resolved, and, ideally, the end user is happy, again.

I dabbled by the way with the idea of having inxi also remove all items in a config file that do not have values after the =, or have ='' only, but I think this mistake doesn't happen that much, though inxi itself did have a bug where it could create the ='' value if the user did something specific, that was fixed in 3.0.11. And the new protections I added in the config tool would just ignore those, and that was also a weakness in inxi (it's very easy for me to see the difference between the later code I wrote for new inxi and the early code - like the color selector and option handler), because I got much better at just always expecting null or bad data in the later code, plus of course getting better at writing Perl and understanding it's way of thinking about things.

So 1 real bug was found here, and 1 real weakness (accepting null values without checking them to make sure they were valid), so this was a fairly productive bit of research/bug finding /squashing, thank you, things like this is what keeps inxi relevant and in decent working order, since there's no way I can personally test everything and do every possible action.

appreciate your time and effort, and check out the newest inxi stuff, features are coming at every sub version release, though of course, not all impact all users, but some do.