Testers for next inxi (pinxi) - USB, Bluetooth, USB upgrades
- Thread starter h2-1
- Start date
That's almost completely inexplicable unfortunately, since in both cases, if you strip away all the logic between, it's perl running the command, the only difference is pinxi a large set of perl commands, and the perl -ws -e thing is just the one set.
The XDG_VTNR being defined but empty was a total longshot, very unlikely, but if you are getting that undefined, that means it's not set, I think that's only set on llnux on the desktop, it's not set on my console either.
But if you are getting the tty using the direct perl command, the pool of things it can be shrinks a lot. If it weren't repeating on different hardware I'd suspect a very unlikely hardware issue, but since it always repeats, it has to be something else.
I could I guess upload a special pinxi debugger thing so you can run it and we can see what's actually happening when pinxi runs that comand, what it gets, but unfortunately, it appears it's getting nothing, which means, perl is getting nothing, but as you see, perl is getting something, and there should not be a difference.
I've seen issues like this before in unrelated contexts, and it almost always came down to a tiny difference somewhere, that nobody was aware of, sometimes a bug in my code, not in this context, but when I could not find any cause.
the trick here is that this command doesn't really seem to fail for users, so there is almost no documentation on it at all, I could read the ttyname C source code, but I don't think that would enlighten or help much.
I may have to give up on this one however, I just can't see any way to get further now, we have installed basically the same systems from the same installation media, and this is a standard C call, that in my experience simply always works, which is I think why there is no real documentation on it to speak of, so there is something going on that is neither obvious or maybe not resolvable. The only test I can do is install one of these bsds as root, but your nomad install is kind of a base system, it does what it does, it has the nomad user, so that is basically identical, yet it fails. If I could resolve it on even one system I could figure it out very quickly, but I can't.
Just to confirm, you're not using anything like 'screen' or something like that, you are typing these commands at the machine's keyboard? Looking at its monitor? There is something being done differently that creates this situation, I'm leaning towards concluding it's just hyper specific and may not impact users, unless you can also duplicate the failure of running-in, but I'm reluctant to take that assumption and go with it because usually something like this has a real cause, the trick is to figure it out.
I just ran my nomad, same results, everything shows as expected, nothing different, and the nomad install has to be one of the most consistent system to system since it's from a disk img file, not an iso, and most of the system is already built, yet we're seeing this difference.
I might have to install to a usb stick on real hardware, but I've never seen this feature fail in production bsds so I'm not tending to believe I can reproduce it.
Basically the perl one liner and pinxi are doing the same exact thing so to have the result be different suggests that there has to be an external difference somewhere.
The XDG_VTNR being defined but empty was a total longshot, very unlikely, but if you are getting that undefined, that means it's not set, I think that's only set on llnux on the desktop, it's not set on my console either.
But if you are getting the tty using the direct perl command, the pool of things it can be shrinks a lot. If it weren't repeating on different hardware I'd suspect a very unlikely hardware issue, but since it always repeats, it has to be something else.
I could I guess upload a special pinxi debugger thing so you can run it and we can see what's actually happening when pinxi runs that comand, what it gets, but unfortunately, it appears it's getting nothing, which means, perl is getting nothing, but as you see, perl is getting something, and there should not be a difference.
I've seen issues like this before in unrelated contexts, and it almost always came down to a tiny difference somewhere, that nobody was aware of, sometimes a bug in my code, not in this context, but when I could not find any cause.
the trick here is that this command doesn't really seem to fail for users, so there is almost no documentation on it at all, I could read the ttyname C source code, but I don't think that would enlighten or help much.
I may have to give up on this one however, I just can't see any way to get further now, we have installed basically the same systems from the same installation media, and this is a standard C call, that in my experience simply always works, which is I think why there is no real documentation on it to speak of, so there is something going on that is neither obvious or maybe not resolvable. The only test I can do is install one of these bsds as root, but your nomad install is kind of a base system, it does what it does, it has the nomad user, so that is basically identical, yet it fails. If I could resolve it on even one system I could figure it out very quickly, but I can't.
Just to confirm, you're not using anything like 'screen' or something like that, you are typing these commands at the machine's keyboard? Looking at its monitor? There is something being done differently that creates this situation, I'm leaning towards concluding it's just hyper specific and may not impact users, unless you can also duplicate the failure of running-in, but I'm reluctant to take that assumption and go with it because usually something like this has a real cause, the trick is to figure it out.
I just ran my nomad, same results, everything shows as expected, nothing different, and the nomad install has to be one of the most consistent system to system since it's from a disk img file, not an iso, and most of the system is already built, yet we're seeing this difference.
I might have to install to a usb stick on real hardware, but I've never seen this feature fail in production bsds so I'm not tending to believe I can reproduce it.
Basically the perl one liner and pinxi are doing the same exact thing so to have the result be different suggests that there has to be an external difference somewhere.
Last edited:
I don't think I'm getting the tty, not like you show... I'm getting /dev/pts/0 instead. But this is all over my head, so I'm glad you know what's going on (or not going on, in this case).
It is strange, for sure. Its about bedtime for me, so you can ponder some more and we'll give it another go tomorrow unless you have something simple to pursue right now. (Debugger sounds more involved this late.)
It is strange, for sure. Its about bedtime for me, so you can ponder some more and we'll give it another go tomorrow unless you have something simple to pursue right now. (Debugger sounds more involved this late.)
You're getting what you should be getting, in fact, all users will see the pts/0 if that's what it is in next inxi, because that's more useful information than just the number itself.
Here's a quick test, use the dev update option, I've tossed in some debuggers that will print out stuff for the tty output and result:
pinxi -U 3
then: pinxi -Ia
that's as root, or in console.
I forgot to see if you ever get running-in for anything.
This will print out that it arrived at the logic in question, and the resultant tty value.
If you do not see any output printed that means pinxi never got to that item, which means something totally unrelated is happening.
Sample of what you should see if the function is called:
note that if you are in console and after updating -U 3, which gets pinxi from my dev server, not from github, and do NOT see that: At get_tty_number! that totally explains at least part, it means some other conditions are happening that literally makes this never fire at all, which is of course, why it would not appear.
Here's a quick test, use the dev update option, I've tossed in some debuggers that will print out stuff for the tty output and result:
pinxi -U 3
then: pinxi -Ia
that's as root, or in console.
I forgot to see if you ever get running-in for anything.
This will print out that it arrived at the logic in question, and the resultant tty value.
If you do not see any output printed that means pinxi never got to that item, which means something totally unrelated is happening.
Sample of what you should see if the function is called:
Code:
pinxi -Iay
At get_tty_number!
tty is: pts/11
tty direct: /dev/pts/11
Info:
Processes: 453 Uptime: 2d 8h 17m wakeups: 3 Memory: 31.37 GiB
used: 14.39 GiB (45.9%) Init: systemd v: 247 runlevel: 5 tool: systemctl
Compilers: gcc: 10.2.1 alt: 10/5/6/8/9 Packages: apt: 3797 lib: 2179 rpm: 0
Shell: Bash (su) v: 5.1.0 running-in: tty pts/11 pinxi: 3.3.01-109note that if you are in console and after updating -U 3, which gets pinxi from my dev server, not from github, and do NOT see that: At get_tty_number! that totally explains at least part, it means some other conditions are happening that literally makes this never fire at all, which is of course, why it would not appear.
Sorry, I missed that you edited above my last post. That's kind of hard to catch. So, anyway, no... not running 'screen' (don't know what it is). I've been typing everything (sometimes incorrectly, LOL) but also copy/paste from Firefox for this latest stuff. All outputs I have been getting are on the monitor or saved to a file, like 'pinxi -zyv8 > asus.txt' and then copy/pasted into the Spoiler reports.
The OpenBSD was just installed yesterday, after switching from FreeBSD 12.2 to have it installed to additonal hardware besides the Asus laptop. These are all pretty straight up basic installations, and then Nomad running live. FreeBSD 13 was just installed yesterday too, shortly after its release. I don't have Xorg on it yet, so I can run Firefox to copy/paste... but we didn't get that far tonight.
The Asus is the easy one to work with... its here on the desk in front of my Linux monitor, so I can use these two together. So all of this complex copy/pasting has been on the Asus. It has had FreeBSD 12 installed for some number of days, maybe a week or so, but not long.
Okay, hold on a sec...
lol, I KNEW It was something subtle, the cause is that when you output to > file then the running in goes away. Not sure exactly why. Just tested, and now I can finally confirm, this has actually been working all along, ok, good, why that tty data goes away when > redirect used is the actual question, and I can reproduce that one easily.
This 'may' be a bug with perl, not sure, because my test shows this:
This 'may' be a bug with perl, not sure, because my test shows this:
Code:
# pinxi -Iay > test.txt
# cat test.txt
At get_tty_number!
tty is undefined
tty direct: /dev/pts/11
Info:
Processes: 453 Uptime: 2d 8h 25m wakeups: 3 Memory: 31.37 GiB
used: 14.43 GiB (46.0%) Init: systemd v: 247 runlevel: 5 tool: systemctl
Compilers: gcc: 10.2.1 alt: 10/5/6/8/9 Packages: apt: 3797 lib: 2179 rpm: 0
Shell: Bash (su) v: 5.1.0 pinxi: 3.3.01-109Sorry for delay
pinxi -la shows (manually typing this)
Partition:
ID-1: / size: 284.77 GiB used: 6.49 GiB (2.3%) fs: ufs block-size: 512 B
dev: /dev/ada0s1a label: N/A
ID-2: swap-1
OK, skipping swap info. I think you've got it!
pinxi -la shows (manually typing this)
Partition:
ID-1: / size: 284.77 GiB used: 6.49 GiB (2.3%) fs: ufs block-size: 512 B
dev: /dev/ada0s1a label: N/A
ID-2: swap-1
OK, skipping swap info. I think you've got it!
Wow, that's a nice find... good work! I had not thought about it, but of course I could not manually type out the response to pinxi -zyv8 ... we would still be here next year! Working with a touchpad on a laptop isn't very friendly to copying the scrollback from a terminal.... redirection just seemed like the way to do this.
Working with a touchpad on a laptop isn't very friendly to copying the scrollback from a terminal.... redirection just seemed like the way to do this.This is corrected, I believe this to be a perl bug, related to how it's handling the > redirect, it returns always undefined in that case, as noted, once I could reproduce it, it was easy to debug.
I've added to keep it simple a fallback test, run tty directly if its there if tty is not defined, that seems to fix it, this is, again, a perl issue, I do not know if it's a bug or intentional, but if it's intentional, it sure does a great job of imitating a bug!!
Thanks for your patience, this issue was not related to bsd, to your hardware, it was just that you did something I almost never do ever, redirect to > file.txt output, which then trips the perl issue/bug.
This will always happen to all users who redirect to file or other places, or would have, since it's now fixed. I might at least report this to perl since it's not really correct behavior imo. But with the simple one liner I can duplicate it for perl guys, which is critical, but I don't know if it even exists as an issue in newer perls, so maybe it's not relevant.
I've added to keep it simple a fallback test, run tty directly if its there if tty is not defined, that seems to fix it, this is, again, a perl issue, I do not know if it's a bug or intentional, but if it's intentional, it sure does a great job of imitating a bug!!
Thanks for your patience, this issue was not related to bsd, to your hardware, it was just that you did something I almost never do ever, redirect to > file.txt output, which then trips the perl issue/bug.
This will always happen to all users who redirect to file or other places, or would have, since it's now fixed. I might at least report this to perl since it's not really correct behavior imo. But with the simple one liner I can duplicate it for perl guys, which is critical, but I don't know if it even exists as an issue in newer perls, so maybe it's not relevant.
I'm glad you identified it... I'm not a programmer, but I understand the frustration finding things like this. And it seemed like the "normal thing" for me to do so that I could show you the output easily, rather than just for me to read on the monitor. Cool.... what's next? (for tomorrow)
Thanks so much for your patience with this, stuff like this can be maddening, but in weird sense, oddly satisfying once it's resolved, and in this case, resolving this issue meant fixing some of the oldest logic in inxi, and questioning stuff internally that had just been running, a few things I found on the way:
* the big core tool to find the shell was being called repeatedly, instead of storing its results as expected, well, it was storing them, but it was also getting called repeatedly
* there was redundant and very confusing code between the shell module and the running in module, that made it very confusing to figure out what was happening, that redundant code is now gone, and several redundant commands run to find the parent of the shell are also gone.
* this possible perl bug with ttyname and redirects was found and fixed, that would have impacted all users, always, forever, which means, any redirected to file output would never have had the running-in if in console or root user. Well,, not fixed, worked around, the fix is if that command returns undefined, then try just running tty directly and call it good. The fact tty works and perl native ttyname failed strongly suggests an old bug nobody has realized exists.
* the (login) item now always works, pretty much, that was broken and probably had not worked for years, sigh, and, as a bonus, a sudo from login in some, but not all, cases, will result in (sudo,login) in the Shell part, it never did that before. Not all systems show their data in that way, it varies, some do, some don't, but it's a nice tiny bonus. That was also somewhat incoherent logic and not situated in the right place, which made it confusing as well.
Thanks a lot for redirecting your output, I KNEW you had to be doing something, and that we'd laugh when we figured it out, but this was a true bug in perl, or at least, lunacy, for if they intended this behavior, they are nuts, lol.
* the big core tool to find the shell was being called repeatedly, instead of storing its results as expected, well, it was storing them, but it was also getting called repeatedly
* there was redundant and very confusing code between the shell module and the running in module, that made it very confusing to figure out what was happening, that redundant code is now gone, and several redundant commands run to find the parent of the shell are also gone.
* this possible perl bug with ttyname and redirects was found and fixed, that would have impacted all users, always, forever, which means, any redirected to file output would never have had the running-in if in console or root user. Well,, not fixed, worked around, the fix is if that command returns undefined, then try just running tty directly and call it good. The fact tty works and perl native ttyname failed strongly suggests an old bug nobody has realized exists.
* the (login) item now always works, pretty much, that was broken and probably had not worked for years, sigh, and, as a bonus, a sudo from login in some, but not all, cases, will result in (sudo,login) in the Shell part, it never did that before. Not all systems show their data in that way, it varies, some do, some don't, but it's a nice tiny bonus. That was also somewhat incoherent logic and not situated in the right place, which made it confusing as well.
Thanks a lot for redirecting your output, I KNEW you had to be doing something, and that we'd laugh when we figured it out, but this was a true bug in perl, or at least, lunacy, for if they intended this behavior, they are nuts, lol.
Last edited:
Oh, and it also exposed a false assumption I have always had, that $XDG_VTNR is the same value as tty, so I'm going to rethink using that, will have to research that false assumption too I think.
Yes, that's it, we're done, lol, thanks for helping making the BSD stuff so much better, it's kind of amazing to see so much of it working, and I have figured out sort of how to make the logic less fragile, but I don't feel like recoding it since it takes so much testing, but if they break it again, I will redo it I think, I started figuring out how to do it, just use more code, less clean logic, until it gets much harder for their random changes to break stuff.
Yes, that's it, we're done, lol, thanks for helping making the BSD stuff so much better, it's kind of amazing to see so much of it working, and I have figured out sort of how to make the logic less fragile, but I don't feel like recoding it since it takes so much testing, but if they break it again, I will redo it I think, I started figuring out how to do it, just use more code, less clean logic, until it gets much harder for their random changes to break stuff.
OK, again, I am glad to have helped you. I'm a fan of inxi (as are many here) and now pinxi too.
If you find you need to check or re-check something related to this thread, just tack on another post and I will probably see it. Or give a shout by calling me with @stan here, or in a new thread if you post another. I'm still on a journey to learn BSD better. It may be my daily OS at some point.
Cheers!
If you find you need to check or re-check something related to this thread, just tack on another post and I will probably see it. Or give a shout by calling me with @stan here, or in a new thread if you post another. I'm still on a journey to learn BSD better. It may be my daily OS at some point.
Cheers!
And with that, 3.3.03 flew out the door, to catch some bugs I found in the following days when checking some totally unrelated stuff. Note that helping with inxi is always appreciated, there are many ways to do it, one is to really learn all the ways it can run, all the scenarios, and try to make it fail, that's how I found 2 of the bugs just fixed, I had forgotten to run several of the scenarios when I redid the shell / running in logic, one was irc client name, which broke, another was a much older break, where several fields were wrong due to a mistake in the logic, and that I had not tested for a long time, but doing the bsd tests exposed some of those mistakes, and made me test stuff again that I had not run in a long time.
The old IRC logic, which is largely where inxi was born, had gotten rusty over the years because irc isn't what it used to be, nor is using inxi on irc, so there were some weaknesses there that I fixed after noticing them when testing other things.
Your case, of doing something I almost never do, but totally correct and valid, inxi > file.txt, is a good example of triggering something just by doing things the way you normally do them. Note that issue I had probably noticed many times over the years, since the inxi debugger report, which includes an inxi output report that is basically redirected to file like you did, but I had never registered it consciously, so I never realized the perl tool was not returning that data when redirecting.
The old IRC logic, which is largely where inxi was born, had gotten rusty over the years because irc isn't what it used to be, nor is using inxi on irc, so there were some weaknesses there that I fixed after noticing them when testing other things.
Your case, of doing something I almost never do, but totally correct and valid, inxi > file.txt, is a good example of triggering something just by doing things the way you normally do them. Note that issue I had probably noticed many times over the years, since the inxi debugger report, which includes an inxi output report that is basically redirected to file like you did, but I had never registered it consciously, so I never realized the perl tool was not returning that data when redirecting.
Last edited:
I definitely have a renewed interest to use inxi more in both Linux and BSD, but there sure are a whole lot of options to learn! Having so many possibilities is good to focus with users here to just look for info related to their problems... if we know what options to call for. That is the hardest probably... and we may be guilty of using a few favorite options rather that learning the full capabilities.
I was just looking at some old threads (many years old) on forums.freebsd.org, and a user was going to attempt to do something similar. They discussed some of the tools, like usbconfig, that could provide the hardware outputs they wanted. The last post in that thread was someone suggesting inxi.
I'm not a member of that forum yet, but I've been lurking lately to pick up bits and pieces. It might be good for you to participate there and remind them of your work.
I only do bsd stuff in those brief moments where either someone shows up actively to help, as you d id, or or when I simply have too much time on my hands, as now. Normally I don't really look at it, I will fire up an openbsd and maybe a freebsd vm and see if latest changes work, but as you could see this time, I'd been using old vms and in the meantime lots of stuff had been changed in newer bsds.
My attitude towards the bsds is a bit different than it used to be, in the past, I got pretty good access, I had some people actively involved giving me ssh access (ssh access speeds my development time by at least 100x, literally), and actually, on the readme on github, I actually stated flat out that I would not touch a bsd problem or issue without direct ssh access because it takes too long, and helps far too few people for those man hours.
I made an exception this time, which you basically saved by doing a lot of real hardware installs, because I was in the middle of a big refactor anyway, and thought I'd update the bsd stuff. But I've found trying to get useful or usable debugging data from bsd guys is... very time consuming, to put it mildly. Way too time consuming for me to volunteer to do it routinely. Basically, my general rule of thumb for hard, non trivial issues, is: no debugger data when requested, no support, period, since otherwise it's my time being eaten, and, for systems I don't run, no ssh access, no support, since it's my time being chomped away for something I don't even use.
Luckily the inxi debugger is so rich that usually I can figure out even super obscure issues like failed raspberry pi device detections without direct access to the system, but the actual reason I got ARM stuff working was a guy gave me ssh access for a few months to a few devices, which was smart, that's how you get your stuff supported, real metal installs, no vms, the only way to go, ssh, massive time saver. But that's with linux, which has easily at minimum, an order of magnitude more data available, and readily and predictably available, in consistent logical structures, than the BSDs have. They are, imo, really shooting themselves in the foot by making their reporting tools break, be inconsistent distro to distro, or as they like to put it, os to os, it makes supporting them far too hard.
But with this said, I prefer one of two things happen for inxi: 1. it has decent bsd support, until they break it by breaking their data syntaxes, 2. no bsd support at all, and I just fly the white flag, and surrender. I was this close to giving up this time, and removing all the bsd logic, but decided to give it one more go around since perl inxi and refactored perl inxi are MUCH easier to work on than ever before, and getting easier all the time. but when, not if, they break various data formats again, I'm not really obligated to fix it rapidly, I mean, sure, yes, I can fix broken data format parsing in iinxi for bsds every time they do a new release, or I can spend the time doing other stuff, and they can stop breaking their data output, or, even better, design better tools that don't rely on such fragile data in the first place. They have a start in sysctl but it's kind of sparse, gpart is actually good, so they have some decent reliable tools, but not very many.
I used to really like the bsds, but I think a few too many years chasing their random changes and breaks cured me of that, now the only one I'd personally find useful is openbsd.
I think basically all the bsd logic was done mainly in 2 big bunches, the original one, and this last one, now. I've run freebsd servers for years, but I never had wheel group access to them, so the data I could get was limited, but that's why freebsd stuff tended to work, more or less, I could ssh into a box and test it. That's why zfs raid stuff works too. But each time I touch bsd stuff after being non active in it for a few years, I'm truly dismayed by just how much stuff has broken, I mean, it's kind of terrifying. This time around, I could see many of the changes were for the better, but some were just plain silly, like openbsd wrapping pcidump -v output so the entire output would only be like 40 columns wide, I mean, why? that's just silly, and makes it a lot harder to parse the data.
My attitude towards the bsds is a bit different than it used to be, in the past, I got pretty good access, I had some people actively involved giving me ssh access (ssh access speeds my development time by at least 100x, literally), and actually, on the readme on github, I actually stated flat out that I would not touch a bsd problem or issue without direct ssh access because it takes too long, and helps far too few people for those man hours.
I made an exception this time, which you basically saved by doing a lot of real hardware installs, because I was in the middle of a big refactor anyway, and thought I'd update the bsd stuff. But I've found trying to get useful or usable debugging data from bsd guys is... very time consuming, to put it mildly. Way too time consuming for me to volunteer to do it routinely. Basically, my general rule of thumb for hard, non trivial issues, is: no debugger data when requested, no support, period, since otherwise it's my time being eaten, and, for systems I don't run, no ssh access, no support, since it's my time being chomped away for something I don't even use.
Luckily the inxi debugger is so rich that usually I can figure out even super obscure issues like failed raspberry pi device detections without direct access to the system, but the actual reason I got ARM stuff working was a guy gave me ssh access for a few months to a few devices, which was smart, that's how you get your stuff supported, real metal installs, no vms, the only way to go, ssh, massive time saver. But that's with linux, which has easily at minimum, an order of magnitude more data available, and readily and predictably available, in consistent logical structures, than the BSDs have. They are, imo, really shooting themselves in the foot by making their reporting tools break, be inconsistent distro to distro, or as they like to put it, os to os, it makes supporting them far too hard.
But with this said, I prefer one of two things happen for inxi: 1. it has decent bsd support, until they break it by breaking their data syntaxes, 2. no bsd support at all, and I just fly the white flag, and surrender. I was this close to giving up this time, and removing all the bsd logic, but decided to give it one more go around since perl inxi and refactored perl inxi are MUCH easier to work on than ever before, and getting easier all the time. but when, not if, they break various data formats again, I'm not really obligated to fix it rapidly, I mean, sure, yes, I can fix broken data format parsing in iinxi for bsds every time they do a new release, or I can spend the time doing other stuff, and they can stop breaking their data output, or, even better, design better tools that don't rely on such fragile data in the first place. They have a start in sysctl but it's kind of sparse, gpart is actually good, so they have some decent reliable tools, but not very many.
I used to really like the bsds, but I think a few too many years chasing their random changes and breaks cured me of that, now the only one I'd personally find useful is openbsd.
I think basically all the bsd logic was done mainly in 2 big bunches, the original one, and this last one, now. I've run freebsd servers for years, but I never had wheel group access to them, so the data I could get was limited, but that's why freebsd stuff tended to work, more or less, I could ssh into a box and test it. That's why zfs raid stuff works too. But each time I touch bsd stuff after being non active in it for a few years, I'm truly dismayed by just how much stuff has broken, I mean, it's kind of terrifying. This time around, I could see many of the changes were for the better, but some were just plain silly, like openbsd wrapping pcidump -v output so the entire output would only be like 40 columns wide, I mean, why? that's just silly, and makes it a lot harder to parse the data.
Last edited:
