I've been working the last few months on the new inxi 3.0.0 release, which is a massive change.

Change one is inxi is moving from Gawk->Bash to Perl 5.x. Tested on Perl 5.08 to current 5.26. Design requirements remain the same: inxi 3.0.0 must run on everything anywhere no matter how old, which for Perl means 5.08 is the oldest realistic Perl release.

For development purposes, inxi 2.9.00 is called pinxi, so that inxi and pinxi can be run next to each other easily on the same system. I refer to bash/gawk inxi as binxi to avoid confusion.

To download and run pinxi:


Once installed, you can update to latest patch release: pinxi -U

inxi-perl branch home page:
github.com/smxi/inxi/tree/inxi-perl

I have only a few things more to do, so I thought I'd get some beta testers, if any are around, now.

Unlike other projects who release the new major version in a raw alpha state condition, pinxi won't be released as inxi 3.0.0 until it is at least feature complete and bugless re inxi 2.3.56.

Note that essentially everything in pinxi has been changed, it's much faster than binxi, from around 50% to 400%, depending on the feature being run and the hardware.

it's also maintainable, and debuggable, which binxi is not. I'd received a few issue reports for various features that I literally could not do with the convoluted data structures I had to use to make gawk talk to bash, but those were fairly easy to resolve in Perl.

All the basic args are the same, plus they all have long forms now, and there are several new options, like --slots (pci slots); --usb, along with more customizable features, and better configuration options.

One of the biggest problems with binxi was the line width logic, which was just a bad hack that was super hard to do, the new pinxi has very smart width handlers, and also uses some space optimizations for narrow screens, so 80 column widths 'just work'.

To give an idea of the speed difference of the line printers, you can run



I may do some more internal speed optimizations, I did a lot earlier in the process, and I may do more once I have the stuff feature complete.

Note the following:

pinxi will support json/xml output options, the internal data logic is there, but the output feature isn't built yet.

pinxi will support language packs, for much of its output strings, that's been designed in, but is not yet implemented, mainly because I want to stabilize the key/value sets so I know what the translator would need. Basically people interested in providing such language support would use a template language.pl file, which would have all the values possible to translate. Pinxi was designed from the start with this potential in mind, something that was totally impossible to do with binxi.

Main signs of bugs:
A spray of 'undefined $val1' errors. I have left this in on purpose because it shows me where I've failed to properly test data being sent to the printer. That error will occur right before the line, and you'll probably see a blank item in one of the values for the keys of that line, which would tell me where the error happened.

The debugger is likewise enhanced.

Visually the main difference you'll see is most places where data was appended like key: something (extra) the (extra) has been moved to a dedicated key value pair, so it would be like so: key1: something key2: extra

This is required for reasonable json / xml output, plus it's more clear.

All actual bugs will be show stoppers for the 3.0.0 inxi release, since I will follow the debian stable strategy of fixing all bugs before, NOT after, release, which is the way all software should be released in my opinion.

I've tested this on FreeBSD so most issues are resolved, but I don't have full access to bsds, can't for example read dmesg.boot data so there's a real restriction on what I can test for and debug.

BSD support is significantly enhanced, and all features have at least stubs for possible future bsd support. I've also discovered that at least OpenBSD and DragonFlyBSD support non root battery, sensors, and hardware data. Those stubs will be completed at some point, but since none of that works now in binxi, I don't consider those show stoppers, though I may end up fixing them if I can get access to bsds that have those values in sysctl -a or from some other source.

As always, feedback, issues, bugs, all are appreciated. My goal is to have a seamless pinxi -> inxi release.

User config files do not require any changes, and use the same syntax as binxi, so nothing has to be changed there, though there are many new config options available, those are still not documented on smxi.org/docs/ but soon will be.

Current pinxi 2.9 man page:
smxi.org/docs/inxi-man.htm

Current pinxi 2.9 options:
smxi.org/docs/inxi-options.htm

I'm looking to get this completed quickly because I've been working on it way too long, and have to get back to other things, but I will certainly fix all issues before 3.0.0 is released.

On an advanced level, I've been using Perl execution optimizers, which allow nano second analysis of the program execution, and basically what it comes down to is that about 90% of pinxi execution time is caused by running subshells for commands (and the initial import of a few core Perl modules), reading files is 10 x 30x faster, and reading ram data is of course fastest. Perl itself is insanely fast, so there's a limit on how much I can really gain in pinxi re speed by optimizing the perl itself, the real win is getting rid of any unneeded subshell execution and replacing it with a file read or something like that. The worst culprits so far are lsusb, which is almost comically slow, though I have to recheck the stuff to find what new optimizations might be called for.

Note you can run --sleep 0.1 or --sleep 0 to get rid of the CPU pause prior to getting cpu speeds, the current delay is I think 0.35 seconds, which usually lets most systems spin down enough to reflect non pinxi cpu speed state.

pinxi --recommends will show what needs what. That's also completely redone, and much improved, since now it does not show GNU/Linux users BSD options, and it doesn't show BSD users Linux only options. Basically except for perl 5.08 or newer, pinxi has no dependencies, just recommends. though for best WAN IP speeds, I do strongly recommend installing dig. Package install advice is also enhanced, and now only shows for the package manager present.

pinxi uses only core Perl modules for its main features, though it will use a json and xml module probably for export, but that will only matter for users who want to export the data.
Back to top

Hi H2

When I installed pinxi on my new Tumbleweed install, it didn't execute until I "chown goineasy9 pinxi". Just like in the smxi days. You might want to add that to the instructions. :-)

BTW- It works as good as inxi. Less Recommends, in fact none, except for xdpyinfo. Well, that's for openSUSE. When I installed it on siduction, I don't remember getting a message that it needed that.
Back to top

I've never seen inxi need chown username, I've never needed it, not on any system I've ever installed it on.

legacy inxi never explicitly checked and returned error messages for xdpyinfo, perl new inxi does, in some cases.

smxi also never required chown changes to run, so I'm not sure what is going on there. The only reason I can think of for that is that it's not in path, and it's not in a user owned location other than something in path.

You'll have to figure out which it is and let me know, since what you are observing I have literally never seen in my life.
Back to top

OK, that's interesting, I've been using chown, for some reason, since the sidux days. Now it's going to drive me crazy figuring out why. :-)
Back to top

Oh, if you want to update a root owned thing as user, you'd want to use chown, maybe that's where the idea came from?

For example, I might chown inxi in /usr/local/bin so that it can be updated by user, not root. But that has nothing to do with running it normally, and you certainly don't need to have user own it to run it, it's the same as any other executable.
Back to top

as root:
cd /usr/local/bin
wget -Nc smxi.org/inxi (or smxi or sgfxi)
chmod +x inxi
chown GoinEasy9 inxi

Well, those are my 4 steps. You might be right about updating a root owned thing. I do sort of remember that. It never caused harm, so, oh well. One less line I have to type. Interesting 10 year brain fart. :-)
Back to top

It doesn't do any harm, and probably the reason was to allow for non root self updaters to run. I know I have my inxi set to allow non root updates, though the man page requires root. But that's only on this system, normally it's root owned.
Back to top