SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Right, it's obviously not the most productive activity to spend more time on this, but the only food for thought that I can generate is that using PKNAME in lsblk will produce e.g. the following (the two relevant awkward lines and the two surrounding them for context; the last two columns are KNAME and PKNAME):
So, the logic would be: if PKNAME is not the parent device name (sda in this case), then KNAME=PKNAME. For -p, the previous line would be discarded anyway as it has no mountpoint. For -o, you could maintain a variable which stored the partition numbers of any partitions that were affected by the rule above and then filter these out of the results.
That's all I could find having a look through the lsblk options available, but perhaps you will find a neat trick at some point in the future.
for simplicity, what I did was take the fields in the order where they are always with data, so I could space separate them.
Note that I suspect I will probably end up using the -P option, then getting the resulting Pairs of key value because that's far more precise and error free than the method I used yesterday.
If you paste in both of those I can see what's available.
The trick is to find the way to get the report to list your thing on one line, not as a second line under one line. Now, I can code in a very custom fix, but those get really bloated when they only apply to one literal situation.
The trick is to find the way to get the report to list your thing on one line, not as a second line under one line. Now, I can code in a very custom fix, but those get really bloated when they only apply to one literal situation.
For efficiency, I always have the loop tools exit on success, and since you can't 'look ahead', the only way to find the match would actually be to not exit the loop.
Let's put this one on the todo list, it's not easy.
pinxi 2.9.03-12 finishes up the man installers, to avoid forcing man installs on people who just want to test pinxi alone, I've added the --man switch, which is required for a non master branch man install. master as usual always installs man with -U.
So now it's become truly trivial to update and check man pages, that's been a real problem for me for years re testing, I'd have to do a real inxi release, then check the man pages on various systems, then edit them, then do another update, now I can just get the new one a second or two after I commit it with a single command.
so since pinxi is a branch release: pinxi -U --man
results in pinxi update and man install/update, from github.
pinxi -U 3 --man
results in grabbing both the pinxi and man versions from the dev server, smxi.org, which can be useful on old systems with expired ssl stuff, github doens't allow non ssl access due to attacks they have suffered.
For efficiency, I always have the loop tools exit on success, and since you can't 'look ahead', the only way to find the match would actually be to not exit the loop.
Let's put this one on the todo list, it's not easy.
pinxi 2.9.03-12 finishes up the man installers, to avoid forcing man installs on people who just want to test pinxi alone, I've added the --man switch, which is required for a non master branch man install. master as usual always installs man with -U.
So now it's become truly trivial to update and check man pages, that's been a real problem for me for years re testing, I'd have to do a real inxi release, then check the man pages on various systems, then edit them, then do another update, now I can just get the new one a second or two after I commit it with a single command.
so since pinxi is a branch release: pinxi -U --man
results in pinxi update and man install/update, from github.
pinxi -U 3 --man
results in grabbing both the pinxi and man versions from the dev server, smxi.org, which can be useful on old systems with expired ssl stuff, github doens't allow non ssl access due to attacks they have suffered.
Absolutely. You have a lot left on your plate anyhow.
Just a quick note that I installed the man with --man and the resultant man pinxi produces a man page containing lots of escape sequences (showing as e.g. ^L characters). Is there something obvious I'm missing?
Code:
NAME
inxi - Command line system information script for console and IRC
SYNOPSIS
^LBinxi^LR - Single line, short form. Very basic output.
^LBinxi ^LR[^LB-AbBCdDfFGhHiIlmMnNopPrRsSuw^LR] ^LR[^LB-c NUMBER^LR] ^LR[^LB-v NUMBER^LR]
^LBinxi ^LR[^LB-t ^LR(^LBc^LR or^LB m^LR or^LB cm^LR or^LB mc NUMBER^LR)] ^LR[^LB-x -OPTION^LR(^LBs^LR)] ^LR[^LB-xx -OPTION^LR(^LBs^LR)] ^LR[^LB-xxx -OPTION^LR(
^LBs^LR)]
Note also that I had to use sudo ./pinxi -U --man - it worked fine but then again I started from scratch (after a git clone of the latest version) and I am not sure whether in the future that will in fact set some of my pinxi files to root ownership if it actually has to update. My pinxi installation is currently in a user-owned folder on my desktop. Perhaps I should install it in a root-owned directory in order to allow proper updating *and* man installation with the same command.
no, nothing obvious. I fear this may depend on your $SHELL since my tests with Bash shell as $SHELL worked perfectly.
of course, this is what pinxi is for. I'm glad I made it --man and not default.
Actually, there's a subtle thing, I forgot, on pinxi -U --man it will show 'gz' if it's coming from the gzip source, which is smxi.org, and it will not say 'gz' if it's coming from the file based github source.
yes, you have to use sudo to install man page, it goes to /usr/local/share/man/man1 for pinxi, or any manually installed inxi.
pinxi.1.gz has to be root owned since all the man pages are in root owned files.
paths to man are set in the system, pinxi/inxi uses that to verify if the /usr/local path is in the man path collection.
let me check my permission checks there, I may not have gotten them totally right, but yes, actually, they are.
It checks to see that the directory exists, that it is writable by current pinxi user, etc, and will show error if not.
So it's not going to install the man file to root owned unless it can, otherwise it exits with error and lets you know.
I'll test this on some remote installs, but unfortunately, my installs are all similar so they won't reflect any possible real differences.
But I'll verify the pinxi -U --man updater, which is a feature that's now some minutes old, heh.
GREAT news, ok, not great, but it reproduced, which is step one.
echo is evaling the escapes, I see what it is, I wasn't sure this would work.
I'll do another try, you did nothing wrong, and I'm not sure why my main system doesn't show the problem.
It's actually very risky rolling out new features as quickly as i'm doing, in normal inxi dev cycles, I spend days researching, and weeks implementing what I am currently doing almost daily.
thanks for noticing it, that would have been embarrassing. Glad I didn't move pinxi to inxi next.
I'm by the way now finding an immediate benefit, I commit a man edit, then just update, with --man, and there it is.
Now, obviously I could also just gzip -c -9 pinxi.1 > man/file/path/pinxi.1.gz but that means I have to be in the right directory, remember the path, all in all far too much, which is why I almost never did it.
Now I just pinxi -U --man and presto, latest man is there! I like it.
@h2-1, I'm planning on providing you with those suggested man page edits as a .odt file with Track Changes. Is that ok with you? If so, I'll need a way of getting it to you. I can't seem to find your email address anywhere...
I honestly don't know what track changes are, I know odt. Are there so many errors? sigh.
Note: I just updated the man page because I decided to get rid of most of the --alt values and replace them with easier to remember variants, like --no-ssl, --no-host, --host, --dmidecode. I found that even though I made those, I couldn't remember them as just integer arguments, so it's pretty unlikely anyone else would.
This change is also in the help menu. pinxi 2.9.04-03
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
