Inxi error: Use of uninitialized value $split[10] in pattern match (m//) at /usr/bin/inxi line 25175

The error corresponds to the output, there is a bug in the ps that manjaro is shipping. Despite using '‘ww’, which means “unlimited width”, this version of ps is still wrapping very long lines, and that is causing the error. Both samples above contained this linewrap, and this means ps has the bug. This is the second core tool in a month or so that I’ve discovered significant bugs with, that is somewhat discouraging.

If you can pastebin the file, I can use that to file a bug report with ps. Also if you can run: ps --version
so I can see what version it is that would be helpful.

The cause of this is easy to bypass, but this should NOT have happened, ever, it’s not about the data having changed, it’s about ps failing to respect the ww no linewrap command and wrapping anyway, which then made inxi try to use a part of the line that should have existed but doesn’t.

But I would like to confirm with ps --version the version number, and the pastebin file to make absolutely sure no other software inserts linewraps.

wget -O pinxi smxi.org/pinxi && chmod +x pinxi

will show the workaround, which is just confirming that the ps line actually contains the item it should be containing, that’s a total hack, but this is a total ps bug, which worries me.

1 Like

Both of these issues are handled in just released inxi 3.3.08. Thanks to manjaro for helping find the issues. Note that the ps failure to wrap is very very similar to the lspci issue of truncating line content in a very bad way, and makes me somewhat wonder if both issues were created by the same person or same changeset to those core tools.

4 Likes

Thank you! inxi works normally again with both -Fxx and -Fazy.

1 Like

Thanks for supplying the required data, in both cases it was necessary to confirm what was happening and why.

1 Like

Here is the Data @pastebin

Unfortunately, the true data came too late. In the future, I will remember to never get anything from pastes in a forums software that can and in this case, did, introduce random line breaks.

The plus side is that ps is NOT introducing random line breaks and failing to respect ww no linewrap, so there is no ps bug. I will have to add that caveat to changelog.

The error you initially posted should in theory be handled by the fix, but the cause of your error remains totally unknown.

If the future, I will always ask for pastebin of > to file output, since the syntax and layout is critical to find these errors. I already knew that you can’t ever rely on forum software to not break or alter output, but I got lazy in this case. This is a good reminder that no post in a forum software with code or output can ever be considered trustworthy, but for linewraps to be introduced in code blocks… that’s very bad. But I can’t fix it, so that’s life.

The cause of your actual break remains in this case unknown, and the fix will probably correct it, but for totally unknown reasons. I’m going to guess your subshell created hard linewraps, but that data can only be found with the full raw data from the inxi debugger, but that’s too late in this case since I believe the issue already resolved on an update before this fix.

But in the future, I’ll remember to never get user pasted in data from output, it has to always be redirected to file, then that file uploaded to pastebin. Note that you can’t even use github to upload text files, it will reformat them too.

4 Likes

Therefore, I’ve marked this solution as the answer:

:+1:

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.