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:
wget -O /usr/local/bin/pinxi https://github.com/smxi/inxi/raw/inxi-perl/pinxi
chmod +x /usr/local/bin/pinxi
Update to latest patch release: pinxi -U
inxi-perl branch home page:
https://github.com/smxi/inxi/tree/inxi-perlI 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
time inxi --help
real 0m1.537s
user 0m0.828s
sys 0m0.529s
vs
time pinxi --help
real 0m0.382s
user 0m0.337s
sys 0m0.071s
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:
https://smxi.org/docs/inxi-man.htmCurrent pinxi 2.9 options:
https://smxi.org/docs/inxi-options.htmI'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.