GoinEasy9, update inxi and try: inxi -dr

It may work now for yum, though that logic is far more difficult than for apt. But in theory it should or may work.

<update>

Tested with your data in fake files:

Note that I'm not going to deal with the unset variables there, that's too complicated.

<note>
Googling I found cases where the enabled= item is not listed, but my logic in inxi requires that to be found to print the line out, I'm not sure if it's required or not in the new syntaxes, but I think I'll wait for bug reports to come in before trying to work that issue.

As with all things linux and inxi, the sea of variability is vast and the lack of any consistent naming or methods is always astounding.

There's no way I can really make it work for enabled only lines without having the enabled= item, since inxi for yum collects the name, the url, and the enabled status, then once all are set, it first checks to see if enabled=0 is there, if not, it prints the line out and resets all the variables.

not super nice but it works for now, I can't think of any other way to do it, and unless I get many bug reports with suggestions on how to work around that issue, I'll leave this as now for all yum users, which makes this now work for yum/apt.

If anyone wants other package manager systems supported, please make sure to research the stuff fully and post the relevant samples of files and file locations etc.

I also found that in older redhat the yum stuff is in /etc/yum.conf but I'm not going to worry about that for now. I assume redhat has changed to what fedora now uses.
Back to top

Added in support for older yum methods that might not have the enabled flag, that was tricky, and also added in support for /etc/yum.conf which redhat used to use.
Back to top

Great stuff techAdmin:


Back to top

new feature in inxi 1.3.0: -o option shows unmounted local partitions. Does not show with -F output by default.

Shows: /dev/... size label uuid or N/A if not available.

Getting the unmounted partition filesystem is too complicated for now unless someone can show how to do that as regular user not as root, and not needing fdisk or such tools.
Back to top

I saw it late last night on IRC, waited till today to see how it worked with dual boot laptop

Partition: ID:/ size: 40G used: 5.1G (14%) fs: ext4 ID:/boot size: 1008M used: 56M (6%) fs: ext3
ID:/home size: 199G used: 12G (7%) fs: ext3 ID:swap-1 size: 8.59GB used: 0.00GB (0%) fs: swap
Unmounted: ID: /dev/sda1 size: 0.04G label: DellUtility uuid: 3030-3030
ID: /dev/sda2 size: 15.73G label: RECOVERY uuid: 50F6C235F6C21ADC
ID: /dev/sda3 size: 214.75G label: OS uuid: 4E76C42676C4111F
Sensors: System Temperatures: cpu: 40.0C mobo: N/A gpu: 0.0:51C
Fan Speeds (in rpm): cpu: N/A
Info: Processes 174 Uptime 2:50 Memory 312.2/3759.6MB Client Shell inxi 1.3.0

Works great!!
Back to top

Added unmounted file system information.

Requires either running inxi as root or adding file to /etc/sudoers.

See inxi -h in version 1.3.1 for more information on how to set that up.

This should finish more or less the -o option, unless someone can figure out where the filesystem information is actually stored in linux, maybe there's a file somewhere for unmounted partition file systems, don't know.

But the method I use now: file -s /dev/<partition> works fine
Back to top

1. Would it be possible for inxi to show memory speed or even show per module info like:

Module 1: DDR2 800MHz Module 2: DDR2 667MHz

2. Also instead of showing the used space for all disks combined, could it show the percentage used for each disk?[/b]
Back to top

no idea on the memory speed, if the data exists and can be read, usually in /proc or /sys, and if it's consistent cross distros, it can be added, if not, it can't, unless you show a way to get that data.

Such a feature request requires that you show a reliable method to query something to get that data.

Hard disk usage is harder, and will be an estimate because of the unmounted partition problem.



Again, if you can show a way to do it, it might get added, if not, it probably won't, that's very complex logic already, and because the data will never be better than an estimate, it's not worth spending a huge amount of time on it.

It can be done in terms of the same rough estimate that the total uses, but it would be hard.

In general, most things are possible, the real question is if someone wants to spend the huge time/energy required to make it happen. Some things are sadly also not possible, at least not using standard methods. Every feature of inxi has taken massive time/testing/energy to implement, basically it's all hard, except a few trivial things like reading /etc/hostname.

The likelihoods of feature requests being implemented are like this:
1. Perfect code for feature supplied, integrates perfectly with existing code in inxi: will definitely happen unless some weird reason exists.

2. Working hack, but the logic is ok. Will get implemented at some point unless someone raises an objection.

3. Showing methods that work, ie, which file to query, the output of some application to query / read then parse. Probably will get done one day if someone feels like it.

4. General ideas, no methods, no data. Unless trivial, or unless it's a super great and useful idea, unlikely any time soon.

The likelihood goes in that order. I've found over time that adding features to inxi that are major changes always is far more difficult and time consuming than I would have believed, that's because the overall linux ecosystem has no particular standards or consistency, exceptions exist all over the place, so every new feature tends to involve about 1 month of debugging and user data reporting to fix / patch the method to work for everything.
Back to top

anonymous_user, by the way, I briefly looked into what output is available from various hardware reporting tools, and I see nothing that shows ram data in the way you request. So until explicit commands / tools are shown, here, on how to do that, I'll consider this request closed as of now.

For an unrelated bug, I was working on the disk space tool, and that would require a full rewrite of all the logic to make a per disk feature work, so that's not happening any time in the near future, but it will probably happen when I rewrite that logic anyway for another reason, or it may happen only for new systems that support /sys data fully. If I add that support I'll add in the per disk output as default, so that should be fine once that happens.
Back to top

New feature as of 1.4.x: -t (think of it as top) - shows top memory/cpu processes in system. Based on ps aux output.

Requires extra options: c OR m OR cm + optional extra information 1-20

samples:

the the numbers have to have no space between cm and number.

Using the -x (extra features) option as well will add the other value to the line, ie, memory will also get cpu used at end, and cpu will get memory used at the end.

this shows process information, c = cpu, m = rss memory, resident memory (this is basically what top shows too for memory use, and what free uses to construct total memory ram used)


A few notes: any numeric value greater than 5 will be throttled to 5 for irc client output to avoid spamming irc, there is no override. this is to avoid inevitable abuse of this feature. Terminal/console supports 20 lines max per cpu/mem output block.

inxi itself is filtered out because it can actually spike the cpu right when it runs this command. When available, it will show both the main process, and the running process, for example, if you start smxi in a slower system then immediately run: inxi -tc you'd see probably:

Back to top