Just a quick note on rokytnji's post above, albeit unrelated to the issue you're both trying to resolve.

I was interested to see that the battery is listed as BAT-0 (mine is BAT-1) as all the other "multiple items" components I've seen so far have started from 1 e.g. "Card-1". I appreciate that BAT-0 may be the name that the system gives the battery in question, but elsewhere in the output, the element names have been generic with the values specific, but in this case the element name itself is specific and based on a value.

Perhaps there should be an initial element called e.g. "Name" which holds the value e.g. "BAT0" or "BAT1" (or whatever), depending on what the system in question refers to the battery as (my directory in /sys/class/power_supply is indeed BAT1).

If you can have multiple batteries (I have no idea whether this is possible), "Name" could become "Battery-1", "Battery-2" etc.

1 members found this post helpful.

Old conky screenshot of my Amrel RT 786 EX laptop that ran 2 batteries.

The extra battery fit into the cdrom drive bay. It was a self teaching lesson for me installing and running LXDE on a AntiX core install.

1 members found this post helpful.

I learn something new each day. Cheers!

So how did that work - did they take constant turns about, did one wait for the other to drain, did the system drain a percentage from each at the same time, or something else?

My Daily Driver is a Thinkpad T420s - which can also swap out its DVD/CD reader/writer for a 2nd battery. The way Lenovo does this is to drain the removable battery first.

1 members found this post helpful.

By the way, you've confirmed a sneaking feeling I had that there were real mismatches between --help/man and reality. But as you know, the person who writes something can no longer see errors after they have stared at it for a bit too long, in my case, way too long. So I actually knew that I couldn't proof for these types of errors.

-A: like I said, I've never seen a better proof reader, help/man say the right thing, I put in the wrong extra level.

-p: ok, one at a time. I was truly astounded when I discovered the really easy 1 liner Perl sort methods for sorting an array of hashes based on the value of a key in the hash. However, this sorting invention can't possibly be alphanumeric and numeric at the same time, it's one or the other. <=> is numeric, cmp is alphanumeric. The fact some whiz from the old days figured this out, and how to do it on only one line, still astounds me, for such things could not even be dreamt of in binxi (which is its own branch fyi, inxi-legacy, which you can run alongside pinxi and inxi). Also, if you see all the variants, you'd realize why it's simply not possible: In particular, the increasingly popular: nvme0n1 which is the entire device name, not a partition on it, which adds p1 etc. So sorts have to be either numeric or alpha, anything else would involve creating a convoluted sorter which is hard to do, and not something I'd spend time on. Simpler cases like dm- sdx etc could be, but that would be hack, I prefer global rules. So I think I'd exclude further sorting. Plus honestly, the more lines of code that goes into pinxi, the slower it starts and runs.

-p/-P shows mounted partitions because those are the partitions relevant to most users. -o / --unmounted shows unmounted. Showing mounted and unmounted in the same block would be exceedingly confusing and unhelpful. Also, on a more simple level, when you run df, which is the primary bsd/linux partition generator, that correctly shows only mounted partitions, since those are the ones of concern. Fuller reports would want to see unmounted, which is why the --unmounted option was added some time after -p/-P was created. It's always worth remembering that presenting users with too much data that has to be further parsed to be understood is not a good thing in general (I do web development for a living, and am very familiar with usability questions). So say, if you were to show both types in item, rather than saying, ok, these are my active partitions, you'd have to scan in and read the mounted/unmounted key value, which is really a bad idea. That's why -o exists. Also, the data sources for mounted and unmounted are completely different, lsblk does not exist on BSDs as far as I know, at least not the ones I tested on, so that's not a valid source for global partition info. Once you bring BSD support into the picture, things stop being simple. But in partition case, they are simple because except for bsd df not supporting -P as in posix, and openbsd not supporting -T, I can roughly use the same output for both. Again, overall length of pinxi is a real thing.

-C: min/max blame /sys, not pinxi, that's what actually is reported. As with ram, the min max are NOT based on data, they are based on strings, that vendors type in. As you can see, the actual speed can be a few MHz more, which is kind of like getting free speed bosts, heh. Bonus free MHz. That's not something I would want to mess with, if the cpu runs a few MHz faster than the vendor states, that's probably just them rounding their numbers to look cleaner.

-V: that one mystifies me so much that rather than spend any time figuring out why that happens, I just trimmed off the ./ if it exists. Since -V runs very rarely adding an extra little hack with a comment explaining why it's there is ok. I did the same thing for the ps/gnome-terminal- bug, I just trim off any trailing - it exists after processing is done, takes less time than filing bug reports with ps or gnome.

-t cm10: debugger, hahha, right when I started today, I was like, oh, darn, did I forget to turn off the debugger, and before I had time to check, yep, I had. this comes from working late nights, those types of errors always happen as focus drifts.

-xx -R: typo, corrected

--alt 44: as - corrected

-h indicates that -x shows microarchitecture revision :: was it a mistake? was it an idea I had? whatever it was, I can't remember, so that's corrected. -x shows rev: now.

-Dx: might be worth indicating that temp may be available as root :: that's more avoiding clutter, since it's an extra option, putting too much data in those strings makes it cluttered. There are many cases in pinxi where if there is no data, it doesn't show the key/value pair, others where it shows N/A. Then some where it shows root permissions. Showing error messages in individual keys creates real clutter issues, I only do when I feel there is really no way else to get the info across, for example, bsds where I do not permissions to read certain system files will not allow me to get full memory size, just used, so in that case, since I'm showing used already, I have to tell them in a word or two why they aren't seeing the full total. hddtemp isn't like that, it's just an extra optional feature.

-G: interestingly, -G lists unloaded as "vesa,modesetting,fbdev", -Gx as "fbdev,modesetting,vesa", -Gxx as "vesa,fbdev,modesetting" and -Gxxx as "modesetting,vesa,fbdev". :: Perl sorts hashes randomly, I forgot how I did that, but yes, it's hashes, which are always totally random every time you output them, forgot about that. sort keys on output fixes it. You can only sort hashes and have them 'keep' the sort at the last output stage, Perl assigns the keys in whatever order it feels like every time you touch the hash.

h indicates that -x shows direct rendering status :: I wish I could remember my decision process, some of these were deliberate choices to change stuff, but others not. The problem with rewriting about 16k lines of dense code in 3 months is that it all becomes a huge dense blur, so I'm going to assume help is right and output is wrong.

-I: This is really petty of me, :: no, observant. However, I would never capitilize inxi/pinxi because that would imply the program name is Pinxi or Inxi, which is a very bad idea due to the confusion it creates. It's like putting your name in lower case, basically.

IF is a technical term for: InterFace. Since each already has the actual value, I didn't want to clutter it up with IF-1 ... etc, also for other reasons. As a side note, inxi/pinxi have some debugger outputs that let me know that something went wrong in the internals, for example, failure to ID a usb device because there's no identifiable network strings in the name values, will result in the IF-ID-1: which tells me, hey, we missed a card here, maybe check into with user dataset to see if we can find if there is a way to get more cards discovered. Another one is ERR-1xx, which if you see it, means, inxi is telling you, hey, we have a total internal failure here for this field, this is a bug, see if you can resolve it. When I see that I always ask for more data. If I didn't see it, just the N/A which means always, no or null data was found, I wuoldn't know if the output existed.

I thought a fair amount about the IF/IP stuff, and decided that because by definition, the unique identifiers always come in the value of that field, it would be cleaner to not show the -1: type counter. Also, it's visually confusing to show it because what you're actually seeing there is this:

Card-1: data.... more data ...
more data... etc
IF: the if device or devices attached to the card
IP: the ips attached to that IF device
Card-2: data data data data
IF: ....
IP: ...

If you then see at the end, above WAN:

IF-ID-1: that means there was an IF device that was not connected to a Card, or a device that was not identified as a Card but which has IF data from ip addr anyway.

-n was a real major reworking of -n/-i, and it targets real sys admins more than regular uses, I always felt some fairly deep shame about the totally pathetic -n/-i output when it came to inxi and real server use, because it was just sad really, but very very difficult to fix in binxi. That was one of the first features I redid, and I developed it on web servers to correctly show huge amount of IP addresses and endless IF per device if required. So that one because it was made to be a very specific way, is not likely to be changed except for bugs etc. You should see the output on real web servers, it's very cool.

G: OpenGL has "version" :: as I said, you have a very trained eye. By the way, actual line length is always at a premium, one thing I really like in new pinxi is that it's got much much smarter and more fluid sizers, and will will, if display columns are < 90 (or user config value option), it wraps the line starters, drops the margin to 2 columns, which suddenly gives 9 more columns of space for output, which is a lot. I always now test pinxi output fairly often two ways: size terminal to 80 cols, or force with -y 80 (--width 80). 80 cols is the ancient legacy default standard that for some bizarre reason has not gone away even though it's based on literally 1908s computer monochrome monitor resolutions, and is somewhat absurd in the modern world (yes, it's a pet peeve I have, code looks horrible when restricted to 80 columns, I prefer about 100 or so since that is about what the human eye sees well, like book lines. So any trims like that that do not sacrifice clarity are welcome. I did that for repos last night, got rid of some extra verbage and made the various repos more consistent.

-p: As an outlier, my Veracrypt mount is showing up as fs: fuseblock. :: pinxi can't know what isn't there, check your lsblk -a and you'll see why. First selection is user lsblkc, second file if no results from first. If you see the root error, it means there was a failure to match the drive in lsblk.

By the way, here's an example of a 100x or more time savings, because here's your data:

notice the missing fs? Nothing to report because nothing found. Resorts to df fs, which is fuseblock. Nothing more pinxi can do in this case.

dm-0 is something new if matched to another partition, I won't have time to deal with those type of more complicated issues.

Re upper/lower, pinxi is just using what it has been given, I can lowercase the fs on output.

Is there any particular reason why the memory figures in the no-option output are in MiB while in -m etc. they are in GiB? :: Yes there is, I debated this when switching the to get_size tool, which is what makes KiB internal units to their proper size and units. The basic idea is this: Because ram can have 100 MiB used, but 1TiB total, I thought it would be very confusing to show the used and total sizes in different units, so I kept them MiB. This isn't obvious when you have the same units for used and total, but when used and total are totally different units, it's hard to do the mental math in my opinion. We tend I think to think of storage units as just what they are, but I think memory, at least to me, isn't that way. For -m, because these are static. For -m, because it's a ram report, which is sized usually in GiB, I decided to just translate them into those sizes. I may not keep this thinking re -I though, it's something I will just watch and see how I feel about it.

Incorrect parameters generate e.g. "Error 22: Unsupported option: -Q" :: error number tells me exactly what it was right away, integer, non ambiguous. Error cases are designed to attract the user attention with an exclamation and a very brief explanation. I want it to draw attention and slight perplexity, making it as harsh as possible is a feature, lol.

-Sx, yes, because most desktops are mysteries to me. There are not other known safe guesses, that's the toolkit that the desktop was made from, this is difficult data to get, qt for kde is safe, because kde itself reports which qt it is based on, xfce I can do because that's what I use, and it also reports this internally if you know where to look, gnome is a safe bet always, but nothing else is. I can't just query the system because you can and usually do have qt and gtk installed. Difficult one, you can have different versions of a toolkit installed, but the actual desktops were made with only one version, say, xfce is made with gtk2, and my system has gtk 2 and 3 on it, so I can't just test gtk version and say, right, this is the version. Only 3 desktops I know of offer me this data internally so I can say, yes, I know what toolkit runs this desktop. And even that is not reliable, kde is fond for example of breaking such simple reporting tools every major release, so is gnome. So that's a far more difficult thing to achieve than you may realize. As a todo, I will add it to the issues list, but it's not nearly as easy as you may believe. In fact, one of my old collaborators thought I was insane for even trying to add support for software into pinxi, but I think it was worth it, and actually has not been too bad re updating stuff, and it's of course way better now in pinxi. But certain things simply cannot be assumed, and desktop toolkit is absolutely one of those things. If the data is not explicitly there, pinxi can't get it. Gnome is an exception because in general you can assume that gnome ships with the latest gkt version, and that gnome and gtk match. All toolkit upgrades have to happen on a per desktop/wm basis, and cannot be assumed, and there is no general rule one can use, it's strictly and totally empirical, so pinxi only shows the data when it knows it's right, otherwise it does not try.

-s: "Fan Speeds (in RPM)" :: anything that can trim characters off width without sacrificing clarity is welcome always.

-w/-W, corrected help/man, the pinxi options were correct I think.

1 members found this post helpful.

These are in pinxi 2.9.03-06

2.9.03-07 will probably have a revised man installer, which will allow gzip install from the repo pinxi.1 man file, that is, it will download the file, then use gzip to push it to the man location.

This means, and I truly shudder (LOL) at the thought, of having the man page itself proof read, and that has NEVER happened. So....

Just fyi, the man page for binxi is binxi.1, pinxi pinxi.1, and inxi inxi.1. this lets me run all of them together, and to test the man for inxi with pinxi.1 before I actually do the real version commit for inxi.

Again, best eye I've seen. Note that because it's actually quite difficult to edit and update man and help, a lot of errors creep in, and remain, which is why you are finding so many issues. The actual text/code is not easy to read in the format it's in, and it's not super easy to edit.

That doesn't surprise me in the slightest! I may take a few days to get to the manual. Thanks for your explanations regarding my various comments. You'll be glad to know that I'm not going to take you up on any of them. I can see that you put some good thought into each issue, even for those where you decide not to do anything. Helping you become aware of possible issues, as I noticed them from a mostly non-technical standpoint, was my only aim. I'm glad to be one of the crew helping you out with this.

Actually, I will take you up on one of them, but probably because I don't properly understand your explanation.

Regarding my Veracrypt mount and -p, here is the output from lsblk -f:

The filesystem of the mounted encrypted partition is indicated as ntfs, so -p should be able to get at that info. The only complication is that the program needs to parse the extra step, no?

Edit: as an aside, pinxi can determine from the above output that there are two unmounted partitions on that particular device, sda1 and sda2 (it can safely ignore sda3 which is blank and has no connected mount), thus removing the 2 erroneous non-mounted partitions in the previous -o output I posted.

I understand that an argument could be made that VeraCrypt is not widely-used, but I would imagine that other encrypted partition mounting programs might produce similar output. Handling this well could result in more accurate results for those using such encrypted partitions without much of a penalty for those who aren't (although the latter would of course be up to you as the coder to determine).

hydrurga, if you notice, I'm basically taking your suggestions on a professional level, that is, where I cannot remember my reasoning, or I totally have no idea, or any doubt exists, I'm going with your suggestions. If, on the other hand, I've consciously thought about, and, lol, more important, remember doing so, about the things, that's where I view it as open to discussion, unless as in the case of IF, I've actually already gone through a lot of visual options at the alpha test stage, and have as noted tested in environments most users are unlikely to ever see, then I'd say, ok, no on that idea. Or the stuff I am still not positive about, like -I memory size units, which were done to avoid confusion.

Your help here is astounding to me, really top notch, I've never had such good copy/proof feedback, commercially or not, though I have begged at least one employer to get some, heh, with no success.

pinxi 2.9..03-09 has a fully dynamic man installer now.

Features: if gzip is installed on user system, it will download from github the inxi.1 or pinxi.1 man file, then gzip compress it, and send it the right man location.

If gzip is not installed, it will use an alternate .gz version stored on smxi.org. these will not always be up to date because I have to do that manually, though I'm going to script a nightly updater tool to keep those synced from github.

binxi will always use the smxi.org gz location.

So you can run inxi, binxi, and dev new pinxi.1 man pages on the same system now with just one command.

You can also force download from smxi.org with -U 3 which bypasses github totally.

that will be more useful when I automate nightly updates to the inxi/pinxi/binxi and manpages stored there, at the moment I'm doing that manually.

This updater upgrade was made necessary by a recent github inxi change, removing the gz files, but it's also something I've wanted for a while because proofreading man pages is really difficult in code form, so now you can install the live pinxi and inxi man pages with no conflict between the two. Tested, working well, will be in inxi 2.9.04 when I release that as well, but pinxi is doing a good job as the dev version, and I'm keeping it from now on because it's making dev and testing so much better.

hydrurga, great stuff, I'm adding lsblk -p to the debugger data collector.

However, re parsing, it's MUCH harder getting the line after a match than it is getting the line that matches, that's a ball of logic that is not fun.

I'm using the very clean and structured --output but since yesterday was the first day I'd ever seen lsblk output let's consider this a beta test of this concept.

however, -p is the exact type of output I'm trying to avoid, but I'm glad you found it as well.

Most of the options have --output equivalents, except stuff like -b, -r, -P. I'll see what -p actually is.

Certainly take me up when the data shows it can be done, that's totally different.

If you can show:

lsblk -pr

lsblk -Pp

the latter is the one I will probably end up using because while more complicated to parse, it's more accurate since there are no white space issues.

the -r makes the data much more parse-able, but also less so, since white spaces are lost.

Ok, enough flattery before I get consumed by my own self-worth (it's my left eye that's the good one by the way). Is there any need, in your opinion, to compare the inxi and the pinxi man pages, or would a proof-read of the pinxi man page against the operation of pinxi do? Bear in mind that I'm not actually that technical, so it might also be a good idea to get someone more technical to review the man page.

Just so I can understand, why are you maintaining a separate binxi man page? Are you planning to continue to support the bash version after inxi becomes Perl-driven?

Sorry, I think you may have misunderstood me. When I was talking about -p, I was talking about pinxi -p, not lsblk -p.

Edit: I see what you are saying though. I'll see if I can get what I want with --output.

Unlike the IBM laptops. They worked as a Pair. When it would go dead. Both would be drained. Conky shows the hours left while at 70% or so in the screenshot.

I misread, sorry, but actually -p is interesting too, as is -P

But the reason I picked the method I am using is that a: it is 2x faster than default, about. 2. it's trivial to parse, and can't be wrong.

Except in this single case, so there may be one further item I can look for in the explicit args.

I'm keeping binxi as a historical oddity, and in those cases where users can't use perl for some reason. However, I'm not supporting it or working on it beyond the small patches I've done to the final version which was moved to inxi-legacy branch.

Re the man pages, I copied inxi.1 to pinxi.1 and then started redoing it, so not much would be gained by directly comparing binxi man and inxi/pinxi man. The comparison would be: real output vs help vs man. And I'm leaving out the smxi.org html versions, which I'm going to wait a bit to update since it's a pain exporting man html, never works right. help is easy.

So roughly, since I'm really essentially working literally on borrowed time a the moment, re binxi, what it comes down to is pretty basic:

1. If I like the person who requests a bug fix (BUG FIX, not feature, nothing real that involves time), I _may_ do it, but that's if and only if I like them. Or if I like their distro due to good past connections and relationships.

2. no features will be added, nothing significant beyond the type of adjuster patches I've done to binxi so it can alone as binxi with binxi man will be done.

3. one exception, of course. Whoever requests the work pays me standard professional wages to do it. This means that this will never happen, since if people had any idea of what actual free software dev time is worth they'd go into a deep state of shock.

So we can fairly safely say that once the current set of patches to enable binxi to be basically 'mothballed' are done, that's all that's going to happen, unless I really really like the person, since it's my time being wasted, not theirs.

rokytnji, sorry to take so long, glad to hear we're just misunderstanding each other, lol. As you say, interweb talk fails without the face to face part, where such things can't happen. And here's to working with real things, man I miss that, believe me, I used to work a bit on cars, and still work on my bicycles because I don't like bike store mechanics, but coding, those are problems that are never solved, and never get your hands dirty.

Could you do me a favor re the chromebook, which should hopefully go a long way towards explaining this. Make sure each set starts as user shell in terminal.

then paste in the output?

I think this will explain it, but I would like to at least know about this issue since it's real.


If I didn't make it clear, I've been aware of your ongoing support over the years, your name always crops up when I check inxi stuff in google, and I appreciate it.