2017-12-07 19:22:59 +00:00
|
|
|
.TH INXI 1 "2017\-12\-07" inxi "inxi manual"
|
2012-09-15 09:18:08 +00:00
|
|
|
.SH NAME
|
2017-06-09 17:14:28 +00:00
|
|
|
inxi \- Command line system information script for console and IRC
|
2012-09-15 09:18:08 +00:00
|
|
|
.SH SYNOPSIS
|
2017-06-09 17:14:28 +00:00
|
|
|
\fBinxi\fR \- Single line, short form. Very basic output.
|
2016-10-29 22:25:55 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\fBinxi \fR[\fB\-AbBCdDfFGhHiIlmMnNopPrRsSuw\fR] \fR[\fB\-c
|
|
|
|
|
NUMBER\fR] \fR[\fB\-v NUMBER\fR]
|
2016-10-29 22:25:55 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\fBinxi \fR[\fB\-t \fR(\fBc\fR or\fB m\fR or\fB cm\fR or\fB mc
|
|
|
|
|
NUMBER\fR)] \fR[\fB\-x \-OPTION\fR(\fBs\fR)] \fR[\fB\-xx
|
|
|
|
|
\-OPTION\fR(\fBs\fR)] \fR[\fB\-xxx \-OPTION\fR(\fBs\fR)]
|
2016-10-29 22:25:55 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\fBinxi \fR[\fB\-\-help\fR] \fR[\fB\-\-recommends\fR]
|
|
|
|
|
\fR[\fB\-\-version\fR] \fR[\fB\-@ NUMBER\fR]
|
2012-09-15 09:18:08 +00:00
|
|
|
.SH DESCRIPTION
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\fBinxi\fR is a command line system information script built for for console
|
|
|
|
|
and IRC. It is also used for forum technical support, as a debugging tool,
|
|
|
|
|
to quickly ascertain user system configuration and hardware. inxi shows
|
|
|
|
|
system hardware, CPU, drivers, Xorg, Desktop, Kernel, GCC version(s), Processes,
|
|
|
|
|
RAM usage, and a wide variety of other useful information.
|
|
|
|
|
|
|
|
|
|
\fBinxi\fR output varies between CLI and IRC, with some default filters and
|
|
|
|
|
color options applied to IRC use. Script colors can be turned off if desired
|
|
|
|
|
with \fB\-c 0\fR, or changed using the \fB\-c\fR color options listed in the
|
|
|
|
|
OPTIONS section below.
|
2012-09-15 09:18:08 +00:00
|
|
|
.SH PRIVACY AND SECURITY
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
In order to maintain basic privacy and security, inxi filters out automatically
|
|
|
|
|
on IRC things like your network card mac address, WAN and LAN IP, your \fB/home\fR
|
|
|
|
|
username directory in partitions, and a few other things.
|
|
|
|
|
|
|
|
|
|
Because inxi is often used on forums for support, you can also trigger this
|
|
|
|
|
filtering with the \fB\-z\fR option (\fB\-Fz\fR, for example). To override
|
|
|
|
|
the IRC filter, you can use the \fB\-Z\fR option. This can be useful to debug
|
|
|
|
|
network connection issues online in a private chat, for example.
|
2012-09-15 09:18:08 +00:00
|
|
|
.SH USING OPTIONS
|
|
|
|
|
Options can be combined if they do not conflict. Either group the letters
|
|
|
|
|
together or separate them.
|
|
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Letters with numbers can have no gap or a gap at your discretion unless using
|
|
|
|
|
\fB \-t\fR.
|
2012-09-15 09:18:08 +00:00
|
|
|
|
|
|
|
|
For example:
|
2016-10-29 22:15:43 +00:00
|
|
|
.B inxi
|
2017-06-09 17:14:28 +00:00
|
|
|
\fB\-AG\fR or \fBinxi \-A \-G\fR or \fBinxi \-c10\fR
|
2012-09-15 09:18:08 +00:00
|
|
|
|
|
|
|
|
.SH STANDARD OPTIONS
|
|
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-A
|
2012-09-15 09:18:08 +00:00
|
|
|
Show Audio/sound card information.
|
|
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-b
|
|
|
|
|
Shows basic output, short form (previously \fB\-d\fR). Same as: \fBinxi \-v 2\fR
|
New Feature, new version, new man page, new tarball. Laptop users should be happy,
-B option now shows, if available, battery data. Quite good data for systems
with /sys battery data, only rudimentary for systems using dmidecode (BSDs).
dmidecode has no current voltage/charge/current supported capacity.
Main row shows charge and condition. Condition shows you have much capacity the
battery currently has vs its design capacity. Charge shows the Wh/percent of
current capacity of battery (NOT the rated design capacity).
-x adds battery vendor/model info, and battery status (like, charging, discharging,
full).
-xx adds battery serial number and voltage information. Note that voltage information
is presented as Current Voltage / Designed minimum voltage.
-xxx adds battery chemistry (like Li-ion), cycles (note: there's a bug somewhere in
that makes the cycle count always be 0, I don't know if that's in the batteries,
the linux kernel, but it's not inxi, just FYI, the data is simply 0 always in all
my datasets so far.
For dmidecode output, the location of the batter is also shown in -xxx
2016-04-19 00:03:14 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-B
|
New Feature, new version, new man page, new tarball. Laptop users should be happy,
-B option now shows, if available, battery data. Quite good data for systems
with /sys battery data, only rudimentary for systems using dmidecode (BSDs).
dmidecode has no current voltage/charge/current supported capacity.
Main row shows charge and condition. Condition shows you have much capacity the
battery currently has vs its design capacity. Charge shows the Wh/percent of
current capacity of battery (NOT the rated design capacity).
-x adds battery vendor/model info, and battery status (like, charging, discharging,
full).
-xx adds battery serial number and voltage information. Note that voltage information
is presented as Current Voltage / Designed minimum voltage.
-xxx adds battery chemistry (like Li-ion), cycles (note: there's a bug somewhere in
that makes the cycle count always be 0, I don't know if that's in the batteries,
the linux kernel, but it's not inxi, just FYI, the data is simply 0 always in all
my datasets so far.
For dmidecode output, the location of the batter is also shown in -xxx
2016-04-19 00:03:14 +00:00
|
|
|
Shows Battery data, charge, condition, plus extra information (if battery present).
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Uses \fB/sys\fR or for BSDs, \fBdmidecode\fR. \fBdmidecode\fR does not have very
|
|
|
|
|
much information, and none about current battery state/charge/voltage. Supports
|
|
|
|
|
multiple batteries when using \fB/sys\fR data.
|
New Feature, new version, new man page, new tarball. Laptop users should be happy,
-B option now shows, if available, battery data. Quite good data for systems
with /sys battery data, only rudimentary for systems using dmidecode (BSDs).
dmidecode has no current voltage/charge/current supported capacity.
Main row shows charge and condition. Condition shows you have much capacity the
battery currently has vs its design capacity. Charge shows the Wh/percent of
current capacity of battery (NOT the rated design capacity).
-x adds battery vendor/model info, and battery status (like, charging, discharging,
full).
-xx adds battery serial number and voltage information. Note that voltage information
is presented as Current Voltage / Designed minimum voltage.
-xxx adds battery chemistry (like Li-ion), cycles (note: there's a bug somewhere in
that makes the cycle count always be 0, I don't know if that's in the batteries,
the linux kernel, but it's not inxi, just FYI, the data is simply 0 always in all
my datasets so far.
For dmidecode output, the location of the batter is also shown in -xxx
2016-04-19 00:03:14 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Note on the \fBcharge\fR item, the output shows the current charge, and the
|
|
|
|
|
percent of the available capacity, which can be less than the original design
|
|
|
|
|
capacity. In the following example, the actual current capacity of the battery
|
|
|
|
|
is \fB22.2 Wh\fR, so the charge shows what percent of the current capacity
|
|
|
|
|
is charged.
|
New Feature, new version, new man page, new tarball. Laptop users should be happy,
-B option now shows, if available, battery data. Quite good data for systems
with /sys battery data, only rudimentary for systems using dmidecode (BSDs).
dmidecode has no current voltage/charge/current supported capacity.
Main row shows charge and condition. Condition shows you have much capacity the
battery currently has vs its design capacity. Charge shows the Wh/percent of
current capacity of battery (NOT the rated design capacity).
-x adds battery vendor/model info, and battery status (like, charging, discharging,
full).
-xx adds battery serial number and voltage information. Note that voltage information
is presented as Current Voltage / Designed minimum voltage.
-xxx adds battery chemistry (like Li-ion), cycles (note: there's a bug somewhere in
that makes the cycle count always be 0, I don't know if that's in the batteries,
the linux kernel, but it's not inxi, just FYI, the data is simply 0 always in all
my datasets so far.
For dmidecode output, the location of the batter is also shown in -xxx
2016-04-19 00:03:14 +00:00
|
|
|
|
|
|
|
|
For example: \fB20.1 Wh 95.4%\fR
|
|
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
The \fBcondition\fR item shows the current available capacity / original design
|
|
|
|
|
capacity, then the percentage of original capacity available in the battery.
|
|
|
|
|
In the following example, the battery capacity is only 61% of it's original amount.
|
New Feature, new version, new man page, new tarball. Laptop users should be happy,
-B option now shows, if available, battery data. Quite good data for systems
with /sys battery data, only rudimentary for systems using dmidecode (BSDs).
dmidecode has no current voltage/charge/current supported capacity.
Main row shows charge and condition. Condition shows you have much capacity the
battery currently has vs its design capacity. Charge shows the Wh/percent of
current capacity of battery (NOT the rated design capacity).
-x adds battery vendor/model info, and battery status (like, charging, discharging,
full).
-xx adds battery serial number and voltage information. Note that voltage information
is presented as Current Voltage / Designed minimum voltage.
-xxx adds battery chemistry (like Li-ion), cycles (note: there's a bug somewhere in
that makes the cycle count always be 0, I don't know if that's in the batteries,
the linux kernel, but it's not inxi, just FYI, the data is simply 0 always in all
my datasets so far.
For dmidecode output, the location of the batter is also shown in -xxx
2016-04-19 00:03:14 +00:00
|
|
|
|
|
|
|
|
For example: \fB22.2/36.4 Wh 61%\fR
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-c
|
|
|
|
|
\fR[\fB0\fR\-\fB32\fR]
|
2012-09-15 09:18:08 +00:00
|
|
|
Available color schemes. Scheme number is required.
|
|
|
|
|
|
2017-06-09 17:14:28 +00:00
|
|
|
Supported color schemes: \fB0\-42\fR
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-c
|
|
|
|
|
\fR[\fB94\fR\-\fB99\fR]
|
2016-10-29 22:15:43 +00:00
|
|
|
|
2012-09-15 09:18:08 +00:00
|
|
|
Color selectors run a color selector option prior to inxi starting which lets
|
|
|
|
|
you set the config file value for the selection.
|
|
|
|
|
|
2014-04-03 18:35:14 +00:00
|
|
|
Color selectors for each type display (NOTE: irc and global only show safe color set):
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-c 94\fR
|
|
|
|
|
\- Console, out of X.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-c 95\fR
|
|
|
|
|
\- Terminal, running in X \- like xTerm.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-c 96\fR
|
|
|
|
|
\- Gui IRC, running in X \- like Xchat, Quassel,
|
2012-09-15 09:18:08 +00:00
|
|
|
Konversation etc.
|
|
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-c 97\fR
|
|
|
|
|
\- Console IRC running in X \- like irssi in xTerm.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-c 98\fR
|
|
|
|
|
\- Console IRC not in X.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-c 99\fR
|
|
|
|
|
\- Global \- Overrides/removes all settings.
|
2012-09-15 09:18:08 +00:00
|
|
|
|
|
|
|
|
Setting specific color type removes the global color selection.
|
|
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-C
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Show full CPU output, including per CPU clockspeed and CPU max speed (if available).
|
|
|
|
|
If max speed data present, shows \fB(max)\fR in short output formats (\fB\inxi\fR,
|
|
|
|
|
\fB\inxi \-b\fR) if CPU actual speed matches CPU max speed. If CPU max speed does
|
|
|
|
|
not match CPU actual speed, shows both actual and max speed information.
|
|
|
|
|
See \fB\-x\fR and \fB\-xx\fR for more options.
|
2017-12-07 19:22:59 +00:00
|
|
|
|
|
|
|
|
CPU description includes technical CPU(s) description: \fB(\-MT\-MCP)\fR
|
|
|
|
|
|
|
|
|
|
* \fBMT\fR \- Multi/Hyper Threaded CPUs, more than 1 thread per core. (Previously \fBHT\fR)
|
|
|
|
|
|
|
|
|
|
* \fBMCP\fR \- Multi Core Processor (More than 1 core per CPU)
|
|
|
|
|
|
|
|
|
|
* \fBSMP\fR \- Symmetric Multi Processing (More than 1 physical CPUs)
|
|
|
|
|
|
|
|
|
|
* \fBUP\fR \- Uni (single core) Processor
|
|
|
|
|
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-d
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Shows optical drive data. Same as \fB\-Dd\fR. With \fB\-x\fR, adds features line to
|
|
|
|
|
output. Also shows floppy disks if present. Note that there is no current way to get
|
|
|
|
|
any information about the floppy device that I am aware of, so it will simply show the
|
|
|
|
|
floppy id, without any extra data. \fB\-xx\fR adds a few more features.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-D
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Show full hard Disk info, not only model, ie: \fB/dev/sda ST380817AS 80.0GB\fR.
|
|
|
|
|
Shows disk space total + used percentage. The disk used percentage includes space
|
|
|
|
|
used by swap partition(s), since those are not usable for data storage. Note that
|
|
|
|
|
with RAID disks, the percentage will be wrong since the total is computed from the
|
|
|
|
|
disk sizes, but the used is computed from mounted partition used percentages. This
|
|
|
|
|
small defect may get corrected in the future. Also, unmounted partitions are not
|
2014-04-27 22:57:24 +00:00
|
|
|
counted in disk use percentages since inxi has no access to that data.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-f
|
|
|
|
|
Show all cpu flags used, not just the short list. Not shown with \fB\-F\fR to avoid
|
2013-06-20 02:18:56 +00:00
|
|
|
spamming. ARM cpus: show \fBfeatures\fR items.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-F
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Show Full output for inxi. Includes all Upper Case line letters, plus \fB\-s\fR
|
|
|
|
|
and \fB\-n\fR. Does not show extra verbose options like
|
|
|
|
|
\fB\-d \-f \-l \-m \-o \-p \-r \-t \-u \-x\fR unless you use those arguments in
|
|
|
|
|
the command, like: \fBinxi \-Frmxx\fR
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-G
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Show Graphic card information. Card(s), Display Server (vendor and version number),
|
|
|
|
|
for example:
|
|
|
|
|
|
2014-03-03 23:31:47 +00:00
|
|
|
\fBDisplay Server: Xorg 1.15.1 \fR
|
2017-06-25 01:28:24 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
as well as screen resolution(s), OpenGL renderer, OpenGL core profile version/OpenGL
|
|
|
|
|
version.
|
|
|
|
|
|
|
|
|
|
If detected (currently only available if on a desktop: will attempt to show the
|
|
|
|
|
server type, ie, x11, wayland, mir. When xorg is present, its version information
|
|
|
|
|
will show after the server type in parentheses. Future versions will show compositor
|
|
|
|
|
information as well.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-h
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
The help menu. Features dynamic sizing to fit into terminal window. Set script
|
|
|
|
|
global \fBCOLS_MAX_CONSOLE\fR if you want a different default value, or
|
|
|
|
|
use \fB\-y <width>\fR to temporarily override the defaults or actual window width.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-\-help
|
|
|
|
|
Same as \fB\-h\fR
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-H
|
2014-03-14 02:28:40 +00:00
|
|
|
The help menu, plus developer options. Do not use dev options in normal
|
2012-09-15 09:18:08 +00:00
|
|
|
operation!
|
|
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-i
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Show Wan IP address, and shows local interfaces (requires \fBifconfig\fR or
|
|
|
|
|
\fBip\fR network tool). Same as \-Nni. Not shown with \fB\-F\fR for user security
|
|
|
|
|
reasons, you shouldn't paste your local/wan IP. Shows both IPv4 and IPv6 link IP
|
|
|
|
|
address.
|
New version, new tarball, new man page. This corrects several oversights of the 2.3.10 IPv6 update.
Now there is an -x option for -i that will show the additioanl IPv6 address data for scope global,
temporary, and site. Also a fallback for unhandled scope: unknown. If the tool 'ip' is used, it will
filter out the deprecated temp site/global addresses, ifconfig tool does not appear to offer this
option.
Also changed is that now ipv6 address always shows, it's not an -x option. Probably about time to
start rolling out ip v6 data to users now that ip v6 is starting, slowly, to be used more.
Another small change, the link address for ipv6 is changed from ip-v6: to ip-v6-link so that it's
more clear which IP v6 address it is.
The last commit had a significant logic error in it that did not distinguish between the link address,
which is what should have only shown, and the remaining possible addresses.
I've tried to get a basic bsd support, but it's difficult to know the variants of ifconfig output syntax
2017-05-31 22:33:16 +00:00
|
|
|
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-I
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Show Information: processes, uptime, memory, irc client (or shell type if run in
|
|
|
|
|
shell, not irc), inxi version. See \fB\-x\fR and \fB\-xx\fR for extra information
|
|
|
|
|
(init type/version, runlevel).
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-l
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Show partition labels. Default: short partition \fB\-P\fR. For full \fB\-p\fR output,
|
|
|
|
|
use: \fB\-pl\fR (or \fB\-plu\fR).
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-m
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Memory (RAM) data. Does not show with \fB\-b\fR or \fB\-F\fR unless you use \fB\-m\fR
|
|
|
|
|
explicitly. Ordered by system board physical system memory array(s) (\fBArray\-[number]
|
|
|
|
|
capacity:\fR), and individual memory devices (\fBDevice\-[number]\fR). Physical memory
|
|
|
|
|
array(s) data shows array capacity, and number of devices supported, and Error Correction
|
|
|
|
|
information. Devices shows locator data (highly variable in syntax), size, speed,
|
|
|
|
|
type (eg: \fBtype: DDR3\fR).
|
|
|
|
|
|
|
|
|
|
Note that \fB\-m\fR uses \fBdmidecode\fR, which must be run as root (or start
|
|
|
|
|
\fBinxi\fR with \fBsudo\fR), unless you figure out how to set up sudo to permit
|
|
|
|
|
dmidecode to read \fB/dev/mem\fR as user. Note that speed will not show if \fBNo Module
|
|
|
|
|
Installed\fR is found in size. This will also turn off Bus Width data output if it is null.
|
|
|
|
|
|
|
|
|
|
If memory information was found, and if the \fB\-I\fR line or the \fB\-tm\fR item have
|
|
|
|
|
not been triggered, will also print the ram used/total.
|
|
|
|
|
|
|
|
|
|
Because dmidecode data is extremely unreliable, inxi will try to make best guesses.
|
|
|
|
|
If you see \fB(check)\fR after capacity number, you should check it for sure with
|
|
|
|
|
specifications. \fB(est)\fR is slightly more reliable, but you should still check
|
|
|
|
|
the real specifications before buying ram. Unfortunately there is nothing \fBinxi\fR
|
|
|
|
|
can do to get truly reliable data about the system ram, maybe one day the kernel devs
|
|
|
|
|
will put this data into \fB/sys\fR, and make it real data, taken from the actual system,
|
|
|
|
|
not dmi data. For most people, the data will be right, but a significant percentage of
|
|
|
|
|
users will have either wrong max module size, if present, or max capacity.
|
New version, new tarball, new man page. Finally, after all these years, initial memory/ram
support. This feature requires dmidecode, and usually that needs to be run as root.
Significantly improved dmidecode error handling and output, and have as 2.1.90 testing/initial
release basic ram data.
In subsequent releases, extra info for -x and -xx and -xxx will be added as well to the output.
For those who want to jump on board early for ram data, update your repos, for those who want to
wait for the full featured version, with -x type data, wait for 2.2.0
And that's that.
2014-08-12 05:26:35 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-M
|
New feature, new tarball, new version number.
Now -M shows device type, like desktop, laptop, notebook, server, blade, vm (and tries to get vm type).
vm detection will take more work, for now I'm just going for the main ones used, but it will certainly
miss some because it's hard to detect them in some cases unless you use root features. Also note, in
most cases a container I believe will display as a vm, which is fine for now.
For BSDs, and older linux, there is a dmidecode fallback detection as well.
2016-10-21 01:36:24 +00:00
|
|
|
Show machine data. Device, Motherboard, Bios, and if present, System Builder (Like Lenovo).
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Older systems/kernels without the required \fB/sys\fR data can use dmidecode instead, run
|
|
|
|
|
as root. If using dmidecode, may also show bios revision as well as version. \fB\-! 33\fR
|
|
|
|
|
can force use of \fBdmidecode\fR data instead of \fB/sys\fR. Will also attempt to show
|
|
|
|
|
if the system was booted by BIOS, UEFI, or UEFI [Legacy]. The last one is legacy BIOS
|
|
|
|
|
boot mode in a systemboard using UEFI but booted as BIOS/Legacy.
|
|
|
|
|
|
|
|
|
|
Device requires either /sys or dmidecode. Note that 'other\-vm?' is a type that means
|
|
|
|
|
it's usually a vm, but inxi failed to detect which type, or to positively confirm which
|
|
|
|
|
vm it is. Primary vm identification is via systemd\-detect\-virt but fallback tests that
|
|
|
|
|
should support some BSDs as well are used. Less commonly used or harder to detect VMs
|
|
|
|
|
may not be correctly detected, if you get a wrong output, post an issue and we'll get it
|
|
|
|
|
fixed if possible.
|
|
|
|
|
|
|
|
|
|
Due to unreliable vendor data, device will show: desktop; laptop; notebook; server;
|
|
|
|
|
blade plus some obscure stuff that inxi is unlikely to ever run on.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-n
|
|
|
|
|
Show Advanced Network card information. Same as \fB\-Nn\fR. Shows interface, speed,
|
2012-09-15 09:18:08 +00:00
|
|
|
mac id, state, etc.
|
|
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-N
|
|
|
|
|
Show Network card information. With \fB\-x\fR, shows PCI BusID, Port number.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-o
|
2012-09-15 09:18:08 +00:00
|
|
|
Show unmounted partition information (includes UUID and LABEL if available).
|
2014-04-04 02:47:08 +00:00
|
|
|
Shows file system type if you have \fBfile\fR installed, if you are root OR if you have
|
2014-04-03 19:52:32 +00:00
|
|
|
added to \fB/etc/sudoers\fR (sudo v. 1.7 or newer):
|
2014-04-03 18:35:14 +00:00
|
|
|
|
2012-09-15 09:18:08 +00:00
|
|
|
.B <username> ALL = NOPASSWD: /usr/bin/file (sample)
|
2014-04-03 18:35:14 +00:00
|
|
|
|
2017-06-09 17:14:28 +00:00
|
|
|
Does not show components (partitions that create the md raid array) of md\-raid arrays.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-p
|
|
|
|
|
Show full partition information (\fB\-P\fR plus all other detected partitions).
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-P
|
|
|
|
|
Show Partition information (shows what \fB\-v 4\fR would show, but without extra data).
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Shows, if detected: \fB/ /boot /home /opt /tmp /usr /var /var/tmp /var/log\fR.
|
|
|
|
|
Use \fB\-p\fR to see all mounted partitions.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-r
|
2012-09-15 09:18:08 +00:00
|
|
|
Show distro repository data. Currently supported repo types:
|
|
|
|
|
|
2017-06-29 19:56:23 +00:00
|
|
|
\fBAPK\fR (Alpine Linux + derived versions)
|
|
|
|
|
|
2014-04-04 02:47:08 +00:00
|
|
|
\fBAPT\fR (Debian, Ubuntu + derived versions)
|
2012-09-15 09:18:08 +00:00
|
|
|
|
2014-04-04 02:47:08 +00:00
|
|
|
\fBPACMAN\fR (Arch Linux + derived versions)
|
2012-09-15 09:18:08 +00:00
|
|
|
|
2014-04-04 02:47:08 +00:00
|
|
|
\fBPISI\fR (Pardus + derived versions)
|
2013-10-05 01:40:00 +00:00
|
|
|
|
2015-02-16 02:22:32 +00:00
|
|
|
\fBPORTAGE\fR (Gentoo, Sabayon + derived versions)
|
2015-02-16 02:17:58 +00:00
|
|
|
|
|
|
|
|
\fBPORTS\fR (OpenBSD, FreeBSD, NetBSD + derived OS types)
|
|
|
|
|
|
2015-02-16 02:33:41 +00:00
|
|
|
\fBSLACKPKG\fR (Slackware + derived versions)
|
2015-02-16 02:17:58 +00:00
|
|
|
|
2014-04-04 02:47:08 +00:00
|
|
|
\fBURPMQ\fR (Mandriva, Mageia + derived versions)
|
|
|
|
|
|
2017-06-09 17:17:48 +00:00
|
|
|
\fBYUM/ZYPP\fR (Fedora, Redhat, Suse + derived versions)
|
2012-09-15 09:18:08 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
(as distro data is collected more will be added. If your's is missing please
|
|
|
|
|
show us how to get this information and we'll try to add it.)
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-R
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Show RAID data. Shows RAID devices, states, levels, and components, and
|
|
|
|
|
extra data with \fB\-x\fR / \fB\-xx\fR.
|
|
|
|
|
|
2017-06-09 17:14:28 +00:00
|
|
|
md\-raid: If device is resyncing, shows resync progress line as well.
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
|
|
|
|
|
Note: Only md\-raid and ZFS are supported. Other software raid types could
|
|
|
|
|
be added, but only if users supply all data required, and if the software
|
|
|
|
|
raid actually can be made to give the required output.
|
|
|
|
|
|
|
|
|
|
Note: due to the complexity, only one raid type per system is supported.
|
|
|
|
|
Md\-raid overrides ZFS if no ZFS was found.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-\-recommends
|
2012-09-15 09:18:08 +00:00
|
|
|
Checks inxi application dependencies + recommends, and directories, then shows
|
|
|
|
|
what package(s) you need to install to add support for that feature.
|
|
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-s
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Show sensors output (if sensors installed/configured): mobo/cpu/gpu temp;
|
|
|
|
|
detected fan speeds. Gpu temp only for Fglrx/Nvidia drivers. Nvidia shows
|
|
|
|
|
screen number for > 1 screens.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-S
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Show System information: host name, kernel, desktop environment (if in X),
|
|
|
|
|
distro. With \fB\-xx\fR show dm \- or startx \- (only shows if present and
|
|
|
|
|
running if out of X), and if in X, with \fB\-xxx\fR show more desktop info,
|
|
|
|
|
like shell/panel etc.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-t
|
2016-10-29 22:15:43 +00:00
|
|
|
\fR[\fBc\fR or\fB m\fR or\fB cm\fR or\fB mc NUMBER\fR]\fR
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Show processes. If followed by numbers \fB1\-20\fR, shows that number of
|
|
|
|
|
processes for each type (default: \fB5\fR; if in irc, max: \fB5\fR)
|
2012-09-15 09:18:08 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Make sure to have no space between letters and numbers (\fB\-t cm10\fR
|
|
|
|
|
\- right, \fB\-t cm 10\fR \- wrong).
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-t c\fR
|
|
|
|
|
\- cpu only. With \fB\-x\fR, shows also memory for that process on same line.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-t m\fR
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- memory only. With \fB\-x\fR, shows also cpu for that process on same line.
|
|
|
|
|
If the \-I line is not triggered, will also show the system used/total ram
|
|
|
|
|
information in the first \fBMemory\fR line of output.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-t cm\fR
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- cpu+memory. With \fB\-x\fR, shows also cpu or memory for that process on
|
|
|
|
|
same line.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-u
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Show partition UUIDs. Default: short partition \fB\-P\fR. For full \fB\-p\fR
|
|
|
|
|
output, use: \fB\-pu\fR (or \fB\-plu\fR).
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-U
|
|
|
|
|
Note \- Maintainer may have disabled this function.
|
2014-04-03 18:28:18 +00:00
|
|
|
|
2017-06-09 17:14:28 +00:00
|
|
|
If inxi \fB\-h\fR has no listing for \fB\-U\fR then it's disabled.
|
2014-04-03 18:28:18 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Auto\-update script. Note: if you installed as root, you must be root to
|
|
|
|
|
update, otherwise user is fine. Also installs / updates this Man Page to:
|
|
|
|
|
\fB/usr/local/share/man/man1\fR (if \fB/usr/local/share/man/\fR exists
|
|
|
|
|
AND there is no inxi man page in \fB/usr/share/man/man1\fR, otherwise it
|
|
|
|
|
goes to \fB/usr/share/man/man1\fR). This requires that you be root to write
|
|
|
|
|
to that directory.
|
2017-01-05 00:23:16 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Previous versions of inxi manually installed man page were installed to
|
|
|
|
|
\fB/usr/share/man/man1\fR. If you want the man page to go into
|
|
|
|
|
\fB/usr/local/share/man/man1\fR move it there and inxi will update to
|
2017-01-05 00:23:16 +00:00
|
|
|
that path from then on.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-V
|
2012-09-15 09:18:08 +00:00
|
|
|
inxi version information. Prints information then exits.
|
|
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-\-version
|
|
|
|
|
same as \fB\-V\fR
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-v
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Script verbosity levels. Verbosity level number is required. Should not be
|
|
|
|
|
used with \fB\-b\fR or \fB\-F\fR.
|
2012-09-15 09:18:08 +00:00
|
|
|
|
2017-06-09 17:14:28 +00:00
|
|
|
Supported levels: \fB0\-7\fR Examples :\fB inxi \-v 4 \fR or \fB inxi \-v4\fR
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-v 0
|
|
|
|
|
\- Short output, same as: \fBinxi\fR
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-v 1
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- Basic verbose, \fB\-S\fR + basic CPU (cores, model, clock speed, and max
|
|
|
|
|
speed, if available) + \fB\-G\fR + basic Disk + \fB\-I\fR.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-v 2
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- Adds networking card (\fB\-N\fR), Machine (\fB\-M\fR) data, Battery (\fB\-B\fR)
|
|
|
|
|
(if available), and shows basic hard disk data (names only). Same as: \fBinxi \-b\fR
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-v 3
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- Adds advanced CPU (\fB\-C\fR); network (\fB\-n\fR) data; triggers \fB\-x\fR
|
|
|
|
|
advanced data option.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-v 4
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- Adds partition size/filled data (\fB\-P\fR) for (if present):
|
|
|
|
|
\fB/ /home /var/ /boot\fR Shows full disk data (\fB\-D\fR)
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-v 5
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- Adds audio card (\fB\-A\fR); memory/ram (\fB\-m\fR);sensors (\fB\-s\fR),
|
|
|
|
|
partition label (\fB\-l\fR) and UUID (\fB\-u\fR), short form of
|
2012-09-15 09:18:08 +00:00
|
|
|
optical drives.
|
|
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-v 6
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- Adds full partition data (\fB\-p\fR), unmounted partition data (\fB\-o\fR),
|
|
|
|
|
optical drive data (\fB\-d\fR); triggers \fB\-xx\fR extra data option.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-v 7
|
|
|
|
|
\- Adds network IP data (\fB\-i\fR); triggers \fB\-xxx\fR
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-w
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Adds weather line. Note, this depends on an unreliable api so it may not always
|
|
|
|
|
be working in the future. To get weather for an alternate location, use
|
|
|
|
|
\fB\-W <location_string>\fR. See also \fB\-x\fR, \fB\-xx\fR, \fB\-xxx\fR option.
|
|
|
|
|
Please note, your distribution's maintainer may chose to disable this feature,
|
|
|
|
|
so if \fB\-w\fR or \fB\-W\fR don't work, that's why.
|
2013-05-26 03:19:38 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-W <location_string>
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Get weather/time for an alternate location. Accepts postal/zip code,
|
|
|
|
|
city,state pair, or latitude,longitude. Note: city/country/state names must not
|
|
|
|
|
contain spaces. Replace spaces with '\fB+\fR' sign. No spaces around \fB,\fR (comma).
|
2013-05-26 03:19:38 +00:00
|
|
|
Use only ascii letters in city/state/country names, sorry.
|
2014-04-03 18:35:14 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Examples: \fB\-W 95623\fR OR \fB\-W Boston,MA\fR OR \fB\-W45.5234,\-122.6762\fR
|
|
|
|
|
OR \fB\-W new+york,ny\fR OR \fB\-W bodo,norway\fR.
|
2014-04-03 17:46:31 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-y <integer >= 80>
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
This is an absolute width override which sets the output line width max.
|
|
|
|
|
Overrides \fBCOLS_MAX_IRC\fR / \fBCOLS_MAX_CONSOLE\fR globals, or the
|
|
|
|
|
actual widths of the terminal. If used with \fB\-h\fR or \fB\-c 94\-99\fR,
|
|
|
|
|
put \fB\-y\fR option first or the override will be ignored. Cannot be
|
|
|
|
|
used with \fB\-\-help\fR/\fB\-\-version\fR/\fB\-\-recommends\fR type
|
|
|
|
|
long options. Example: \fBinxi \-y 130 \-Fxx\fR
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-z
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Adds security filters for IP addresses, Mac, location (\fB\-w\fR), and user
|
|
|
|
|
home directory name. Default on for irc clients.
|
New version, new tarball, new man page. Unless disabled by distribution maintainers, offers
weather -w option. With -x, -xx-, -xxx, shows more information. Basic line is just weather
and system time there. -x adds time zone, which is useful for servers, particurly web servers.
-x also adds wind speed. -xx adds humidity and barometric pressure. -xxx adds a possible new line,
if data is available, heat index, wind chill, and dew point.
-xxx also adds a line for location (blocked by irc/-z) / weather observation time.
-z filter applies as usual to location data, removes it in irc by default. -Z overrides override.
The api this uses is probably going to be dropped at some point, so this is just going to work
while it works, then it will need to be updated at some point, so don't get very attached to it.
Also adds option to, with -w: -! location=<location string>
This lets users send an alternate location using either <city,state> or <postal code>
or <latitude,longitude> (commas for city,state and latitude,longitude are not optional, and the order
must be as listed.
If There is a developer flag if distro maintainers do not want this enabled, simply set:
B_ALLOW_WEATHER='false'
before packaging and the weather feature will be disabled.
2013-05-18 02:04:29 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-Z
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Absolute override for output filters. Useful for debugging networking
|
|
|
|
|
issues in irc for example.
|
2012-09-15 09:18:08 +00:00
|
|
|
.SH EXTRA DATA OPTIONS
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
These options are for long form only, and can be triggered by one or
|
|
|
|
|
more \fB\-x\fR, like \fB\-xx\fR. Alternately, the \fB\-v\fR options
|
|
|
|
|
trigger them in the following way: \fB\-v 3\fR adds \fB\-x\fR;
|
|
|
|
|
\fB\-v 6\fR adds \fB\-xx\fR; \fB\-v 7\fR adds \fB\-xxx\fR
|
2012-09-15 09:18:08 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
These extra data triggers can be useful for getting more in\-depth
|
|
|
|
|
data on various options. Can be added to any long form option list,
|
|
|
|
|
like: \fB\-bxx\fR or \fB\-Sxxx\fR
|
2012-09-15 09:18:08 +00:00
|
|
|
|
2017-06-09 17:14:28 +00:00
|
|
|
There are 3 extra data levels: \fB\-x\fR; \fB\-xx\fR; and \fB\-xxx\fR
|
2012-09-15 09:18:08 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
The following shows which lines / items get extra information with each
|
|
|
|
|
extra data level.
|
2012-10-19 19:43:26 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-x \-A
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- Adds version/port(s)/driver version (if available) for each Audio
|
|
|
|
|
device.
|
2012-10-19 19:43:26 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-x \-A
|
|
|
|
|
\- Shows PCI Bus ID/Usb ID number of each Audio device.
|
New Feature, new version, new man page, new tarball. Laptop users should be happy,
-B option now shows, if available, battery data. Quite good data for systems
with /sys battery data, only rudimentary for systems using dmidecode (BSDs).
dmidecode has no current voltage/charge/current supported capacity.
Main row shows charge and condition. Condition shows you have much capacity the
battery currently has vs its design capacity. Charge shows the Wh/percent of
current capacity of battery (NOT the rated design capacity).
-x adds battery vendor/model info, and battery status (like, charging, discharging,
full).
-xx adds battery serial number and voltage information. Note that voltage information
is presented as Current Voltage / Designed minimum voltage.
-xxx adds battery chemistry (like Li-ion), cycles (note: there's a bug somewhere in
that makes the cycle count always be 0, I don't know if that's in the batteries,
the linux kernel, but it's not inxi, just FYI, the data is simply 0 always in all
my datasets so far.
For dmidecode output, the location of the batter is also shown in -xxx
2016-04-19 00:03:14 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-x \-B
|
|
|
|
|
\- Shows Vendor/Model, battery status (if battery present).
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-x \-C
|
|
|
|
|
\- bogomips on CPU (if available); CPU Flags (short list).
|
2017-07-28 07:18:42 +00:00
|
|
|
.TP
|
|
|
|
|
.B \-x \-C
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- CPU microarchitecture + revision (like Sandy Bridge, K8, ARMv8, P6,
|
|
|
|
|
and so on). Only shows if detected. Newer microarchitectures will have
|
|
|
|
|
to be added as they appear, and require the CPU family id and model id.
|
2017-07-29 01:42:17 +00:00
|
|
|
|
New version, tarball, man page. This corrects many 80 column width line wraps, including on:
-o, -p, -l, -u, -P, -S, -G, -N, -A
Now most output should tend to not wrap, though some strings are unpredictable and
will have to be trimmed by adding them to the min size trimmers one by one.
But it's much better than it was.
Note the following changes required to make the wraps more consistent:
-S - the gcc/bits have been made separate, like: bits: 32 gcc: 5.3
-C - the new microarchitecture -x option now is: arch: K7 [for example]
cache wraps to next line with arch. with -f, bmips now shows on same line as
arch/cache
2017-07-30 21:22:14 +00:00
|
|
|
Example: \fBarch: Sandy Bridge rev.2\fR, \fBarch: K8 rev.F+\fR
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-x \-d
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- Adds items to features line of optical drive; adds rev version to
|
|
|
|
|
optical drive.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-x \-D
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- Hdd temp with disk data if you have hddtemp installed, if you are root
|
|
|
|
|
OR if you have added to \fB/etc/sudoers\fR (sudo v. 1.7 or newer):
|
2014-04-03 18:35:14 +00:00
|
|
|
|
2012-09-15 09:18:08 +00:00
|
|
|
.B <username> ALL = NOPASSWD: /usr/sbin/hddtemp (sample)
|
2017-06-29 19:56:23 +00:00
|
|
|
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-x \-G
|
2017-06-25 01:28:24 +00:00
|
|
|
\- Direct rendering status for Graphics.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-x \-G
|
|
|
|
|
\- (for single gpu, nvidia driver) screen number gpu is running on.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-x \-G
|
|
|
|
|
\- Shows PCI Bus ID/Usb ID number of each Graphics card.
|
2012-10-19 19:43:26 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-x \-i
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- Show IP v6 additional scope data, like Global, Site, Temporary for
|
|
|
|
|
each interface.
|
2017-05-31 22:41:17 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Note that there is no way I am aware of to filter out the deprecated
|
|
|
|
|
IP v6 scope site/global temporary addresses from the output of
|
|
|
|
|
\fBifconfig\fR. \fBip\fR tool shows that clearly.
|
2017-05-31 22:41:17 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\fBip\-v6\-temporary\fR \- (\fBip\fR tool only), scope global temporary.
|
|
|
|
|
Scope global temporary deprecated is not shown
|
2017-05-31 22:41:17 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\fBip\-v6\-global\fR \- scope global (\fBifconfig\fR will show this for
|
|
|
|
|
all types, global, global temporary, and global temporary deprecated,
|
|
|
|
|
\fBip\fR shows it only for global)
|
2017-05-31 22:41:17 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\fBip\-v6\-link\fR \- scope link (\fBip\fR/\fBifconfig\fR) \- default
|
|
|
|
|
for \fB\-i\fR.
|
2017-05-31 22:41:17 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\fBip\-v6\-site\fR \- scope site (\fBip\fR/\fBifconfig\fR). This has been
|
|
|
|
|
deprecated in IPv6, but still exists. \fBifconfig\fR may show multiple site
|
|
|
|
|
values, as with global temporary, and global temporary deprecated.
|
2017-05-31 22:41:17 +00:00
|
|
|
|
2017-06-09 17:14:28 +00:00
|
|
|
\fBip\-v6\-unknown\fR \- unknown scope
|
2017-05-31 22:41:17 +00:00
|
|
|
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-x \-I
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- Show current init system (and init rc in some cases, like OpenRC).
|
|
|
|
|
With \-xx, shows init/rc version number, if available.
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-x \-I
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- Show system GCC, default. With \-xx, also show other installed GCC
|
|
|
|
|
versions.
|
2012-12-05 21:38:07 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-x \-I
|
|
|
|
|
\- Show current runlevel (not available with all init systems).
|
2014-01-13 23:01:03 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-x \-I
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- If in shell (not in IRC client, that is), show shell version number
|
|
|
|
|
(if available).
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-x \-m
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- Shows memory device Part Number (\fBpart:\fR). Useful to order new or
|
|
|
|
|
replacement memory sticks etc. Usually part numbers are unique, particularly
|
|
|
|
|
if you use the word \fBmemory\fR in the search as well. With \fB\-xx\fR,
|
|
|
|
|
shows Serial Number and Manufactorer as well.
|
2014-08-13 03:19:55 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-x \-m
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- If present, shows maximum memory module/device size in the Array line.
|
|
|
|
|
Only some systems will have this data available.
|
2014-08-13 21:05:21 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-x \-N
|
|
|
|
|
\- Adds version/port(s)/driver version (if available) for each Network card;
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-x \-N
|
|
|
|
|
\- Shows PCI Bus ID/Usb ID number of each Network card.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-x \-R
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- md\-raid: Shows component raid id. Adds second RAID Info line: raid level;
|
|
|
|
|
report on drives (like 5/5); blocks; chunk size; bitmap (if present). Resync
|
|
|
|
|
line, shows blocks synced/total blocks.
|
2014-04-04 02:50:31 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- zfs\-raid: Shows raid array full size; available size; portion allocated
|
|
|
|
|
to RAID (ie, not available as storage)."
|
New version, new tarball, new man page. Unless disabled by distribution maintainers, offers
weather -w option. With -x, -xx-, -xxx, shows more information. Basic line is just weather
and system time there. -x adds time zone, which is useful for servers, particurly web servers.
-x also adds wind speed. -xx adds humidity and barometric pressure. -xxx adds a possible new line,
if data is available, heat index, wind chill, and dew point.
-xxx also adds a line for location (blocked by irc/-z) / weather observation time.
-z filter applies as usual to location data, removes it in irc by default. -Z overrides override.
The api this uses is probably going to be dropped at some point, so this is just going to work
while it works, then it will need to be updated at some point, so don't get very attached to it.
Also adds option to, with -w: -! location=<location string>
This lets users send an alternate location using either <city,state> or <postal code>
or <latitude,longitude> (commas for city,state and latitude,longitude are not optional, and the order
must be as listed.
If There is a developer flag if distro maintainers do not want this enabled, simply set:
B_ALLOW_WEATHER='false'
before packaging and the weather feature will be disabled.
2013-05-18 02:04:29 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-x \-S
|
|
|
|
|
\- Desktop toolkit if available (GNOME/XFCE/KDE only); Kernel gcc version.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-x \-t
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- Adds memory use output to cpu (\fB\-xt c\fR), and cpu use to memory
|
|
|
|
|
(\fB\-xt m\fR). For \fB\-xt c\fR will also show system Used/Total ram data
|
|
|
|
|
if \fB\-t m\fR (memory) is not used AND \fB\-I\fR is not triggered.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-x \-w / \-W
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- Adds wind speed and time zone (\fB\-w\fR only), and makes output go to
|
|
|
|
|
two lines.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-xx \-A
|
|
|
|
|
\- Adds vendor:product ID of each Audio device.
|
2012-10-19 19:28:31 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-xx \-B
|
|
|
|
|
\- Adds serial number, voltage (if available).
|
New Feature, new version, new man page, new tarball. Laptop users should be happy,
-B option now shows, if available, battery data. Quite good data for systems
with /sys battery data, only rudimentary for systems using dmidecode (BSDs).
dmidecode has no current voltage/charge/current supported capacity.
Main row shows charge and condition. Condition shows you have much capacity the
battery currently has vs its design capacity. Charge shows the Wh/percent of
current capacity of battery (NOT the rated design capacity).
-x adds battery vendor/model info, and battery status (like, charging, discharging,
full).
-xx adds battery serial number and voltage information. Note that voltage information
is presented as Current Voltage / Designed minimum voltage.
-xxx adds battery chemistry (like Li-ion), cycles (note: there's a bug somewhere in
that makes the cycle count always be 0, I don't know if that's in the batteries,
the linux kernel, but it's not inxi, just FYI, the data is simply 0 always in all
my datasets so far.
For dmidecode output, the location of the batter is also shown in -xxx
2016-04-19 00:03:14 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Note that \fBvolts\fR shows the data (if available) as: Voltage Now / Minimum
|
|
|
|
|
Design Voltage
|
New Feature, new version, new man page, new tarball. Laptop users should be happy,
-B option now shows, if available, battery data. Quite good data for systems
with /sys battery data, only rudimentary for systems using dmidecode (BSDs).
dmidecode has no current voltage/charge/current supported capacity.
Main row shows charge and condition. Condition shows you have much capacity the
battery currently has vs its design capacity. Charge shows the Wh/percent of
current capacity of battery (NOT the rated design capacity).
-x adds battery vendor/model info, and battery status (like, charging, discharging,
full).
-xx adds battery serial number and voltage information. Note that voltage information
is presented as Current Voltage / Designed minimum voltage.
-xxx adds battery chemistry (like Li-ion), cycles (note: there's a bug somewhere in
that makes the cycle count always be 0, I don't know if that's in the batteries,
the linux kernel, but it's not inxi, just FYI, the data is simply 0 always in all
my datasets so far.
For dmidecode output, the location of the batter is also shown in -xxx
2016-04-19 00:03:14 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-xx \-C
|
|
|
|
|
\- Shows Minimum CPU speed (if available).
|
New version, new tarball. This fixes a long standing weakness with min/max cpu speed
handling. Or rather, non handling, since that data only showed in rare cases on short form
(inxi no args) output. Now it uses /sys query to determine min/max speed of cpu, and uses
that data to override any other min/max data discovered.
Still uses /proc/cpuinfo for actual speeds per core. The assumption in this is that all
cares will have the same min/max speeds, which is generally going to be a safe assumption.
Now in short form, inxi, output, it will show actual speed then (max speed) or just (max)
if actual speed matches max speed. Same for -b short CPU output.
For long, -C output, shows max speed before the actual cpu core speeds per core.
With -xx, and in multi cpu/core systems only, shows if available min/max speeds.
Note that not all /sys have this data, so it doesn't show any N/A if it's missing.
2014-09-17 03:41:21 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-xx \-D
|
|
|
|
|
\- Adds disk serial number.
|
2012-10-19 19:28:31 +00:00
|
|
|
.TP
|
2017-09-07 17:05:45 +00:00
|
|
|
.B \-xx \-D
|
|
|
|
|
\- Adds disk firmware revision number, if available (nvme and possibly other types).
|
|
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-xx \-G
|
2017-06-09 19:39:43 +00:00
|
|
|
\- Adds vendor:product ID of each Graphics card.
|
|
|
|
|
.TP
|
|
|
|
|
.B \-xx \-G
|
|
|
|
|
\- Wayland/Mir only: if found, attempts to show compositor (experimental).
|
|
|
|
|
.TP
|
|
|
|
|
.B \-xx \-G
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- For free drivers, adds OpenGL compatibility version number if it's available.
|
|
|
|
|
For nonfree drivers, the core version and compatibility versions are the same.
|
|
|
|
|
Example:
|
2017-06-09 19:39:43 +00:00
|
|
|
|
2017-06-09 17:14:28 +00:00
|
|
|
\fB3.3 Mesa 11.2.0 (compat\-v: 3.0)\fR
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-xx \-I
|
|
|
|
|
\- Show init type version number (and rc if present).
|
2014-03-13 00:18:26 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-xx \-I
|
|
|
|
|
\- Adds other detected installed gcc versions to primary gcc output (if present).
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-xx \-I
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- Show, if detected, system default runlevel. Supports Systemd/Upstart/Sysvinit
|
|
|
|
|
type defaults. Note that not all systemd systems have the default value set, in
|
|
|
|
|
that case, if present, it will use the data from \fB/etc/inittab\fR.
|
2014-01-13 23:01:03 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-xx \-I
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- Adds parent program (or tty) that started shell, if not IRC client, to shell
|
|
|
|
|
information.
|
2013-01-29 00:03:06 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-xx \-m
|
|
|
|
|
\- Shows memory device Manufacturer and Serial Number.
|
2014-08-13 03:19:55 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-xx \-m
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- Single/double bank memory, if data is found. Note, this may not be 100% right
|
|
|
|
|
all of the time since it depends on the order that data is found in \fBdmidecode\fR
|
|
|
|
|
output for \fBtype 6\fR and \fBtype 17\fR.
|
2014-08-16 23:24:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-xx \-M
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- Adds chassis information, if any data for that is available. Also shows BIOS
|
|
|
|
|
rom size if using dmidecode.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-xx \-N
|
|
|
|
|
\- Adds vendor:product ID of each Network card.
|
2012-10-19 19:28:31 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-xx \-R
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- md\-raid: Adds superblock (if present); algorythm, U data. Adds system info
|
|
|
|
|
sline (kernel support, read ahead, raid events). Adds if present, unused device
|
|
|
|
|
line. If device is resyncing, shows resync progress line as well.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-xx \-S
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- Adds, if run in X, display manager type to Desktop information, if present.
|
|
|
|
|
If none, shows N/A. Supports most known display managers, like xdm, gdm, kdm,
|
|
|
|
|
slim, lightdm, or mdm.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-xx \-w / \-W
|
|
|
|
|
\- Adds humidity and barometric pressure.
|
New version, new tarball, new man page. Unless disabled by distribution maintainers, offers
weather -w option. With -x, -xx-, -xxx, shows more information. Basic line is just weather
and system time there. -x adds time zone, which is useful for servers, particurly web servers.
-x also adds wind speed. -xx adds humidity and barometric pressure. -xxx adds a possible new line,
if data is available, heat index, wind chill, and dew point.
-xxx also adds a line for location (blocked by irc/-z) / weather observation time.
-z filter applies as usual to location data, removes it in irc by default. -Z overrides override.
The api this uses is probably going to be dropped at some point, so this is just going to work
while it works, then it will need to be updated at some point, so don't get very attached to it.
Also adds option to, with -w: -! location=<location string>
This lets users send an alternate location using either <city,state> or <postal code>
or <latitude,longitude> (commas for city,state and latitude,longitude are not optional, and the order
must be as listed.
If There is a developer flag if distro maintainers do not want this enabled, simply set:
B_ALLOW_WEATHER='false'
before packaging and the weather feature will be disabled.
2013-05-18 02:04:29 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-xx \-@ <11\-14>
|
|
|
|
|
\- Automatically uploads debugger data tar.gz file to \fIftp.techpatterns.com\fR.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-xxx \-B
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- Adds battery chemistry (like: \fBLi\-ion\fR), cycles (NOTE: there appears to
|
|
|
|
|
be a problem with the Linux kernel obtaining the cycle count, so this almost
|
|
|
|
|
always shows \fB0\fR. There's nothing that can be done about this glitch, the
|
|
|
|
|
data is simply not available as of 2016\-04\-18), location (only available from
|
|
|
|
|
dmidecode derived output).
|
New Feature, new version, new man page, new tarball. Laptop users should be happy,
-B option now shows, if available, battery data. Quite good data for systems
with /sys battery data, only rudimentary for systems using dmidecode (BSDs).
dmidecode has no current voltage/charge/current supported capacity.
Main row shows charge and condition. Condition shows you have much capacity the
battery currently has vs its design capacity. Charge shows the Wh/percent of
current capacity of battery (NOT the rated design capacity).
-x adds battery vendor/model info, and battery status (like, charging, discharging,
full).
-xx adds battery serial number and voltage information. Note that voltage information
is presented as Current Voltage / Designed minimum voltage.
-xxx adds battery chemistry (like Li-ion), cycles (note: there's a bug somewhere in
that makes the cycle count always be 0, I don't know if that's in the batteries,
the linux kernel, but it's not inxi, just FYI, the data is simply 0 always in all
my datasets so far.
For dmidecode output, the location of the batter is also shown in -xxx
2016-04-19 00:03:14 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-xxx \-m
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- Memory bus width: primary bus width, and if present, total width. eg:
|
|
|
|
|
bus width: 64 bit (total: 72 bits). Note that total / data widths are mixed up
|
|
|
|
|
sometimes in dmidecode output, so inxi will take the larger value as total if
|
|
|
|
|
present. If no total width data is found, then inxi will not show that item.
|
2014-08-13 03:19:55 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-xxx \-m
|
|
|
|
|
\- Adds device Type Detail, eg: DDR3 (Synchronous).
|
2014-08-13 03:19:55 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-xxx \-m
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- If present, will add memory module voltage. Only some systems will have this
|
|
|
|
|
data available.
|
2014-08-13 21:05:21 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-xxx \-S
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- Adds, if run in X, shell/panel type info to Desktop information, if present.
|
|
|
|
|
If none, shows nothing. Supports some current desktop extras like gnome\-panel,
|
|
|
|
|
lxde\-panel, and others. Added mainly for Mint support.
|
New version, new tarball, new man page. Unless disabled by distribution maintainers, offers
weather -w option. With -x, -xx-, -xxx, shows more information. Basic line is just weather
and system time there. -x adds time zone, which is useful for servers, particurly web servers.
-x also adds wind speed. -xx adds humidity and barometric pressure. -xxx adds a possible new line,
if data is available, heat index, wind chill, and dew point.
-xxx also adds a line for location (blocked by irc/-z) / weather observation time.
-z filter applies as usual to location data, removes it in irc by default. -Z overrides override.
The api this uses is probably going to be dropped at some point, so this is just going to work
while it works, then it will need to be updated at some point, so don't get very attached to it.
Also adds option to, with -w: -! location=<location string>
This lets users send an alternate location using either <city,state> or <postal code>
or <latitude,longitude> (commas for city,state and latitude,longitude are not optional, and the order
must be as listed.
If There is a developer flag if distro maintainers do not want this enabled, simply set:
B_ALLOW_WEATHER='false'
before packaging and the weather feature will be disabled.
2013-05-18 02:04:29 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-xxx \-w / \-W
|
|
|
|
|
\- Adds location (city state country), weather observation time, altitude of system.
|
2013-05-26 03:19:38 +00:00
|
|
|
If wind chill, heat index, or dew point are available, shows that data as well.
|
New version, updated man page, new tarball.
Fixed partition bug that could falsely identify a remote filesystem like nfs as /dev fs
Added two options:
-! 31 - Turns off Host section of System line. This is useful if you want to post output
from server without posting its name.
-! 32 - Turns on Host section if it has been disabled by user configuration file
B_SHOW_HOST='false'
Added missing CPU data message, fixed missing cpu cache/bogomips output, turned off
bogomips if null for bsd systems because bogomips is a linux kernel feature.
Added N/A for no memory report, this would mainly hit bsd systems where user has no
permissions to use sysctl or has no read rights for /var/run/dmesg.boot.
Many fixes for partitions, now for bsd, if available, uses gpart list to get uuid/label
Added support for raid file system syntax in bsd, now excludes main raid device name,
and adds a flag to raiddevice/partitionname type so output can identify it as a raid
slice/partition.
In man page, added -! 31 / -! 32 sections, and some other small edits.
Added bsd raid line error message, added bsd sensors line error message.
Many other small bug fixes that should make linux more robust in terms of missing
data, and better/cleaner output for bsd.
2013-02-18 20:33:05 +00:00
|
|
|
.SH ADVANCED OPTIONS
|
|
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-! 31
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Turns off hostname in System line. Useful, with \fB\-z\fR, for anonymizing your
|
|
|
|
|
inxi output for posting on forums or IRC.
|
New version, updated man page, new tarball.
Fixed partition bug that could falsely identify a remote filesystem like nfs as /dev fs
Added two options:
-! 31 - Turns off Host section of System line. This is useful if you want to post output
from server without posting its name.
-! 32 - Turns on Host section if it has been disabled by user configuration file
B_SHOW_HOST='false'
Added missing CPU data message, fixed missing cpu cache/bogomips output, turned off
bogomips if null for bsd systems because bogomips is a linux kernel feature.
Added N/A for no memory report, this would mainly hit bsd systems where user has no
permissions to use sysctl or has no read rights for /var/run/dmesg.boot.
Many fixes for partitions, now for bsd, if available, uses gpart list to get uuid/label
Added support for raid file system syntax in bsd, now excludes main raid device name,
and adds a flag to raiddevice/partitionname type so output can identify it as a raid
slice/partition.
In man page, added -! 31 / -! 32 sections, and some other small edits.
Added bsd raid line error message, added bsd sensors line error message.
Many other small bug fixes that should make linux more robust in terms of missing
data, and better/cleaner output for bsd.
2013-02-18 20:33:05 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-! 32
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Turns on hostname in System line. Overrides inxi config file value (if set):
|
|
|
|
|
B_SHOW_HOST='false'.
|
While this release has some new features, they are all intended for development use
for the next major feature, -m / memory, so there is no particular reason to package
this release. There is a new development option, -! 33, which lets me override /sys
data use for -M, which is useful to debug dmidecode output for -m and other features.
No new version, new man. There may be a few more of these releases, but functionally
there is no particular reason to make a new package if you are a maintainer, so there
is no new version number. This release is a preparation for some branches/one/inxi
tests that will be run in the future.
The man/help document -! 33 just to have it there, but it should make no difference
to anyone but me at this stage.
2014-04-14 20:35:38 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-! 33
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Force use of \fBdmidecode\fR. This will override \fB/sys\fR data in some lines,
|
|
|
|
|
like \fB\-M\fR.
|
2017-06-09 18:55:19 +00:00
|
|
|
.TP
|
|
|
|
|
.B \-! 34
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Skip SSL certificate checks for all downloader actions (\fB\-U\fR, \fB\-w\fR,
|
|
|
|
|
\fB\-W\fR, \fB\-i\fR). Use if your system does not have current SSL certificate
|
|
|
|
|
lists, or if you have problems making a connection for any reason. Only works
|
|
|
|
|
with \fBwget\fR, \fBcurl\fR, and \fBfetch\fR. This must go before the other
|
|
|
|
|
options you use.
|
2017-06-09 02:29:55 +00:00
|
|
|
|
|
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-! 40
|
2017-06-10 21:42:49 +00:00
|
|
|
Will try to get display data out of X (does not usually work as root user).
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Default gets display info from display \fB:0\fR. If you use this format:
|
|
|
|
|
\fB\-! 40:1\fR it would get it from display \fB1\fR instead, or any display
|
|
|
|
|
you specify as long as there is no space between \fB\-! 40\fR and the
|
|
|
|
|
\fB:[display id]\fR.
|
2017-06-10 21:42:49 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Note that in some cases, \fB\-! 40\fR will cause inxi to hang endlessly when
|
|
|
|
|
running the option in console with Intel graphics (confirmed). Other free
|
|
|
|
|
drivers like nouveau/ati unknown yet. It may be that this is a bug with the
|
|
|
|
|
intel graphics driver, more information required.
|
2017-06-10 21:42:49 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
You can test this easily by running this command out of X/display server:
|
|
|
|
|
\fBglxinfo -display :0\fR
|
2017-06-10 21:42:49 +00:00
|
|
|
|
|
|
|
|
If it hangs, \fB\-! 40\fR will not work.
|
2017-06-09 02:29:55 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
.TP
|
|
|
|
|
.B \-! 41
|
|
|
|
|
Bypass \fBCurl\fR as a downloader option. Priority is: Curl, Wget, Fetch,
|
|
|
|
|
HTTP::Tiny, OpenBSD only: ftp
|
|
|
|
|
|
2017-11-29 01:28:28 +00:00
|
|
|
.TP
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
.B \-! 42
|
|
|
|
|
Bypass \fBFetch\fR as a downloader option.Priority is: Curl, Wget, Fetch,
|
|
|
|
|
HTTP::Tiny, OpenBSD only: ftp
|
|
|
|
|
|
2017-11-29 01:28:28 +00:00
|
|
|
.TP
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
.B \-! 43
|
|
|
|
|
Bypass \fBWget\fR as a downloader option. Priority is: Curl, Wget, Fetch,
|
|
|
|
|
HTTP::Tiny, OpenBSD only: ftp
|
|
|
|
|
|
2017-11-29 01:28:28 +00:00
|
|
|
.TP
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
.B \-! 44
|
|
|
|
|
Bypass \fBCurl\fR, \fBFetch\fR, and \fBWget\fR as downloader options. This
|
|
|
|
|
basically forces the downloader selection to use \fBPerl 5.x\fR \fBHTTP::Tiny\fR,
|
|
|
|
|
which is in general slower than \fBCurl\fR or \fBWget\fR but it may help bypass
|
|
|
|
|
issues with downloading.
|
|
|
|
|
|
2012-09-15 09:18:08 +00:00
|
|
|
.SH DEBUGGING OPTIONS
|
|
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-%
|
2012-09-15 09:18:08 +00:00
|
|
|
Overrides defective or corrupted data.
|
|
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-@
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Triggers debugger output. Requires debugging level \fB1\-14\fR
|
|
|
|
|
(\fB8\-10\fR \- logging of data). Less than 8 just triggers inxi
|
|
|
|
|
debugger output on screen.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-@
|
|
|
|
|
\fR[\fB1\fR\-\fB7\fR] \- On screen debugger output.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-@ 8
|
|
|
|
|
\- Basic logging. Check \fB/home/yourname/.inxi/inxi*.log
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-@ 9
|
|
|
|
|
\- Full file/sys info logging.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-@ 10
|
|
|
|
|
\- Color logging.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-@ <11\-14>
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
The following create a tar.gz file of system data, plus collecting
|
|
|
|
|
the inxi output to file: To automatically upload debugger data
|
|
|
|
|
tar.gz file to \fIftp.techpatterns.com\fR:
|
2014-04-03 18:35:14 +00:00
|
|
|
|
2017-06-09 17:14:28 +00:00
|
|
|
\fBinxi \-xx@ <11\-14>\fR
|
2014-04-03 18:35:14 +00:00
|
|
|
|
2012-09-15 09:18:08 +00:00
|
|
|
For alternate ftp upload locations: Example:
|
2014-04-03 18:35:14 +00:00
|
|
|
|
2017-06-09 17:14:28 +00:00
|
|
|
.B inxi \-!
|
|
|
|
|
\fIftp.yourserver.com/incoming\fB \-xx@ 14\fR
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-@ 11
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- With tree traversal data file read of \fB/sys\fR, and other system
|
|
|
|
|
data.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-@ 12
|
|
|
|
|
\- With xorg conf and log data, xrandr, xprop, xdpyinfo, glxinfo etc.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-@ 13
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\- With data from dev, disks, partitions, etc.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2017-06-09 17:14:28 +00:00
|
|
|
.B \-@ 14
|
|
|
|
|
\- Everything, full data collection.
|
2012-09-15 09:18:08 +00:00
|
|
|
.SH SUPPORTED IRC CLIENTS
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
BitchX, Gaim/Pidgin, ircII, Irssi, Konversation, Kopete, KSirc, KVIrc, Weechat,
|
|
|
|
|
and Xchat. Plus any others that are capable of displaying either built in or external
|
|
|
|
|
script output.
|
2012-09-15 09:18:08 +00:00
|
|
|
.SH RUNNING IN IRC CLIENT
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
To trigger inxi output in your IRC client, pick the appropriate method from the
|
|
|
|
|
list below:
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
2016-10-29 22:15:43 +00:00
|
|
|
.B Xchat, irssi
|
|
|
|
|
\fR(and many other IRC clients)
|
2017-06-09 17:14:28 +00:00
|
|
|
.B /exec \-o inxi
|
2016-10-29 22:15:43 +00:00
|
|
|
\fR[\fBoptions\fR]
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
If you leave off the \fB\-o\fR, only you will see the output on your local
|
|
|
|
|
IRC client.
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
|
|
|
|
.B Konversation
|
2016-10-29 22:15:43 +00:00
|
|
|
.B /cmd inxi
|
|
|
|
|
\fR[\fBoptions\fR]
|
|
|
|
|
|
2017-09-22 00:12:58 +00:00
|
|
|
To run inxi in konversation as a native script if your distribution or inxi package
|
|
|
|
|
did not do this for you, create this symbolic link [the first works for KDE 4,
|
|
|
|
|
the second for KDE 5]:
|
2012-09-15 09:18:08 +00:00
|
|
|
|
2017-06-09 17:14:28 +00:00
|
|
|
.B ln \-s /usr/local/bin/inxi /usr/share/kde4/apps/konversation/scripts/inxi
|
2012-09-15 09:18:08 +00:00
|
|
|
|
2017-09-22 00:12:58 +00:00
|
|
|
.B ln \-s /usr/local/bin/inxi /usr/share/konversation/scripts/inxi
|
|
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
If inxi is somewhere else, change the path \fB/usr/local/bin\fR to wherever it
|
|
|
|
|
is located.
|
2012-09-15 09:18:08 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
If you are using KDE/QT 5, then you may also need to add the following to get
|
|
|
|
|
the konversation \fR/inxi\fR command to work:
|
2017-09-22 00:12:58 +00:00
|
|
|
|
|
|
|
|
.B ln \-s /usr/share/konversation /usr/share/apps/
|
|
|
|
|
|
2012-09-15 09:18:08 +00:00
|
|
|
Then you can start inxi directly, like this:
|
|
|
|
|
|
2016-10-29 22:15:43 +00:00
|
|
|
.B /inxi
|
|
|
|
|
\fR[\fBoptions\fR]
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
|
|
|
|
.B WeeChat
|
2017-06-09 17:14:28 +00:00
|
|
|
.B NEW: /exec \-o inxi
|
2016-10-29 22:15:43 +00:00
|
|
|
\fR[\fBoptions\fR]
|
2014-04-03 18:35:14 +00:00
|
|
|
|
2017-06-09 17:14:28 +00:00
|
|
|
.B OLD: /shell \-o inxi
|
2016-10-29 22:15:43 +00:00
|
|
|
\fR[\fBoptions\fR]
|
2014-04-03 18:35:14 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Newer (2014 and later) WeeChats work pretty much the same now as other console
|
|
|
|
|
IRC clients, with \fB/exec \-o inxi \fR[\fBoptions\fR]. Also, newer WeeChats
|
|
|
|
|
have dropped the \fB\-curses\fR part of their program name, ie:
|
|
|
|
|
\fBweechat\fR instead of \fBweechat\-curses\fR.
|
2014-04-03 18:15:23 +00:00
|
|
|
|
|
|
|
|
Deprecated:
|
2014-04-03 18:35:14 +00:00
|
|
|
|
2012-09-15 09:18:08 +00:00
|
|
|
Before WeeChat can run external scripts like inxi, you need to install the
|
2017-06-09 17:14:28 +00:00
|
|
|
weechat\-plugins package. This is automatically installed for Debian users.
|
2012-09-15 09:18:08 +00:00
|
|
|
Next, if you don't already have it, you need to install shell.py,
|
|
|
|
|
which is a python script.
|
|
|
|
|
|
|
|
|
|
In a web browser, Click on the download button at:
|
2015-08-28 16:41:55 +00:00
|
|
|
.I https://www.weechat.org/scripts/source/stable/shell.py.html/
|
2012-09-15 09:18:08 +00:00
|
|
|
|
|
|
|
|
Make the script executable by
|
|
|
|
|
|
|
|
|
|
.B chmod +x shell.py
|
|
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Move it to your home folder: \fB/.weechat/python/autoload/\fR then logout,
|
|
|
|
|
and start WeeChat with
|
2012-09-15 09:18:08 +00:00
|
|
|
|
2017-06-09 17:14:28 +00:00
|
|
|
.B weechat\-curses
|
2012-09-15 09:18:08 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Top of screen should say what pythons scripts have loaded, and should include
|
|
|
|
|
shell. Then to run inxi, you would enter a command like this:
|
2012-09-15 09:18:08 +00:00
|
|
|
|
2017-06-09 17:14:28 +00:00
|
|
|
.B /shell \-o inxi \-bx
|
2012-09-15 09:18:08 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
If you leave off the \fB\-o\fR, only you will see the output on your local
|
|
|
|
|
weechat. WeeChat users may also like to check out the weeget.py
|
2012-09-15 09:18:08 +00:00
|
|
|
.SH INITIALIZATION FILE
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
inxi will read the following configuration/initialization files in the
|
|
|
|
|
following order:
|
New version, new tarball. This is a significant change, but inxi should handle it smoothly.
While default configs remain in /etc/inxi.conf, the user overrides now use the following order of tests:
1. XDG_CONFIG_HOME / XDG_DATA_HOME for the config and log/debugger data respectively.
2. Since those will often be blank, it then uses a second priority check:
$HOME/.config $HOME/.local/share to place the inxi data directory, which was previously here:
$HOME/.inxi
3. If neither of these cases are present, inxi will default to its legacy user data: $HOME/.inxi as before
In order to make this switch transparent to users, inxi will move the files from .inxi to the respective
.config/ .local/share/inxi directories, and remove the .inxi directory after to cleanup.
Also, since I was fixing some path stuff, I also did issue 77, manual inxi install not putting man pages in
/usr/local/share/man/man1, which had caused an issue with Arch linux inxi installer. Note that I can't help
users who had a manual inxi install with their man page in /usr/share/man/man1 already, because it's too risky
to guess about user or system intentions, this man location correction will only apply if users have never
installed inxi before manually, and have no distro version installed, unlike the config/data directory,
which does update neatly with output letting users know the data was moved.
Note that if users have man --path set up incorrectly, it's possible that the legacy man page would show up
instead, which isn't good, but there was no perfect fix for the man issue so I just picked the easiest way,
ignoring all man pages installed into /usr/share/man/man1 and treating them as final location, otherwise
using if present the /usr/local/share/man/man1 location for new manual install users.
Also, for users with existing man locations and an inxi manually installed, you have to update to inxi current,
then move your man file to /usr/local/share/man/man1, then update man with: mandb command (as root), after that
inxi will update to the new man location.
Also added some more XDG debugger data as well to cover this for future debugger data.
This closes previous issue #77 (man page for manual inxi install does not go into /usr/local/share/man/man1) and
issue 101, which I made today just to force the update.
Just as a side note, I find this absurd attempt at 'simplifying by making more complex and convoluted' re the XDG
and .config and standard nix . file to be sort of tragic, because really, they've just made it all way more complicated,
and since all 3 methods can be present, all the stuff has to be tested for anyway, so this doesn't make matters cleaner
at all, it's just pointless busywork that makes some people happy since now there's even more rules to follow, sigh.
2016-12-20 02:57:56 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\fB/etc/inxi.conf\fR is the default configurations. These can be overridden
|
|
|
|
|
by user configurations found in one of the following locations (inxi will
|
|
|
|
|
place its config file using the following precedence as well, that is,
|
|
|
|
|
if \fB$XDG_CONFIG_HOME\fR is not empty, it will go there, else if
|
|
|
|
|
\fB$HOME/.conf/inxi.conf\fR exists, it will go there, and as a last default,
|
|
|
|
|
the legacy location is used:
|
New version, new tarball. This is a significant change, but inxi should handle it smoothly.
While default configs remain in /etc/inxi.conf, the user overrides now use the following order of tests:
1. XDG_CONFIG_HOME / XDG_DATA_HOME for the config and log/debugger data respectively.
2. Since those will often be blank, it then uses a second priority check:
$HOME/.config $HOME/.local/share to place the inxi data directory, which was previously here:
$HOME/.inxi
3. If neither of these cases are present, inxi will default to its legacy user data: $HOME/.inxi as before
In order to make this switch transparent to users, inxi will move the files from .inxi to the respective
.config/ .local/share/inxi directories, and remove the .inxi directory after to cleanup.
Also, since I was fixing some path stuff, I also did issue 77, manual inxi install not putting man pages in
/usr/local/share/man/man1, which had caused an issue with Arch linux inxi installer. Note that I can't help
users who had a manual inxi install with their man page in /usr/share/man/man1 already, because it's too risky
to guess about user or system intentions, this man location correction will only apply if users have never
installed inxi before manually, and have no distro version installed, unlike the config/data directory,
which does update neatly with output letting users know the data was moved.
Note that if users have man --path set up incorrectly, it's possible that the legacy man page would show up
instead, which isn't good, but there was no perfect fix for the man issue so I just picked the easiest way,
ignoring all man pages installed into /usr/share/man/man1 and treating them as final location, otherwise
using if present the /usr/local/share/man/man1 location for new manual install users.
Also, for users with existing man locations and an inxi manually installed, you have to update to inxi current,
then move your man file to /usr/local/share/man/man1, then update man with: mandb command (as root), after that
inxi will update to the new man location.
Also added some more XDG debugger data as well to cover this for future debugger data.
This closes previous issue #77 (man page for manual inxi install does not go into /usr/local/share/man/man1) and
issue 101, which I made today just to force the update.
Just as a side note, I find this absurd attempt at 'simplifying by making more complex and convoluted' re the XDG
and .config and standard nix . file to be sort of tragic, because really, they've just made it all way more complicated,
and since all 3 methods can be present, all the stuff has to be tested for anyway, so this doesn't make matters cleaner
at all, it's just pointless busywork that makes some people happy since now there's even more rules to follow, sigh.
2016-12-20 02:57:56 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
\fB$XDG_CONFIG_HOME/inxi.conf\fR or \fB$HOME/.conf/inxi.conf\fR or
|
|
|
|
|
\fB$HOME/.inxi/inxi.conf\fR
|
New version, new tarball. This is a significant change, but inxi should handle it smoothly.
While default configs remain in /etc/inxi.conf, the user overrides now use the following order of tests:
1. XDG_CONFIG_HOME / XDG_DATA_HOME for the config and log/debugger data respectively.
2. Since those will often be blank, it then uses a second priority check:
$HOME/.config $HOME/.local/share to place the inxi data directory, which was previously here:
$HOME/.inxi
3. If neither of these cases are present, inxi will default to its legacy user data: $HOME/.inxi as before
In order to make this switch transparent to users, inxi will move the files from .inxi to the respective
.config/ .local/share/inxi directories, and remove the .inxi directory after to cleanup.
Also, since I was fixing some path stuff, I also did issue 77, manual inxi install not putting man pages in
/usr/local/share/man/man1, which had caused an issue with Arch linux inxi installer. Note that I can't help
users who had a manual inxi install with their man page in /usr/share/man/man1 already, because it's too risky
to guess about user or system intentions, this man location correction will only apply if users have never
installed inxi before manually, and have no distro version installed, unlike the config/data directory,
which does update neatly with output letting users know the data was moved.
Note that if users have man --path set up incorrectly, it's possible that the legacy man page would show up
instead, which isn't good, but there was no perfect fix for the man issue so I just picked the easiest way,
ignoring all man pages installed into /usr/share/man/man1 and treating them as final location, otherwise
using if present the /usr/local/share/man/man1 location for new manual install users.
Also, for users with existing man locations and an inxi manually installed, you have to update to inxi current,
then move your man file to /usr/local/share/man/man1, then update man with: mandb command (as root), after that
inxi will update to the new man location.
Also added some more XDG debugger data as well to cover this for future debugger data.
This closes previous issue #77 (man page for manual inxi install does not go into /usr/local/share/man/man1) and
issue 101, which I made today just to force the update.
Just as a side note, I find this absurd attempt at 'simplifying by making more complex and convoluted' re the XDG
and .config and standard nix . file to be sort of tragic, because really, they've just made it all way more complicated,
and since all 3 methods can be present, all the stuff has to be tested for anyway, so this doesn't make matters cleaner
at all, it's just pointless busywork that makes some people happy since now there's even more rules to follow, sigh.
2016-12-20 02:57:56 +00:00
|
|
|
|
2012-09-15 09:18:08 +00:00
|
|
|
See wiki pages for more information on how to set these up:
|
|
|
|
|
.TP
|
2017-09-22 00:12:58 +00:00
|
|
|
.I https://smxi.org/docs/inxi\-configuration.htm
|
2012-09-15 09:18:08 +00:00
|
|
|
.SH BUGS
|
|
|
|
|
Please report bugs using the following resources.
|
|
|
|
|
|
|
|
|
|
You may be asked to run the inxi debugger tool which will upload a data dump of all
|
|
|
|
|
system files for use in debugging inxi. These data dumps are very important since
|
|
|
|
|
they provide us with all the real system data inxi uses to parse out its report.
|
|
|
|
|
.TP
|
2016-08-26 02:30:38 +00:00
|
|
|
inxi main website/source/wiki, file an issue report:
|
New version, new tarball:
Changes: updated inxi updaters to use github locations.
I will do this commit once for googlecode, and once for github, after that,
all commits will go only to github.
inxi moves to github, despite my dislike of for profit source repos, and git,
I decided that I just don't have the time or energy to do it right, so I'm going
to use github.
The project is already moved, though I have left inxi up for the time being on
code.google.com/p/inxi until I move the wiki to http://smxi.org
Everything is pretty much the same, the project url is:
https://github.com/smxi/inxi
The direct download link for the gz is:
https://github.com/smxi/inxi/raw/master/inxi.tar.gz
git pull is:
git pull https://github.com/smxi/inxi master
svn checkout url:
https://github.com/smxi/inxi
And that's about it.
2015-08-20 23:32:57 +00:00
|
|
|
.I https://github.com/smxi/inxi/issues
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
|
|
|
|
post on inxi developer forums:
|
2017-06-09 17:14:28 +00:00
|
|
|
.I http://techpatterns.com/forums/forum\-32.html
|
2012-09-15 09:18:08 +00:00
|
|
|
.TP
|
|
|
|
|
You can also visit
|
2016-10-29 22:15:43 +00:00
|
|
|
.I irc.oftc.net
|
|
|
|
|
\fRchannel:\fI #smxi\fR to post issues.
|
2012-09-15 09:18:08 +00:00
|
|
|
.SH HOMEPAGE
|
New version, new tarball:
Changes: updated inxi updaters to use github locations.
I will do this commit once for googlecode, and once for github, after that,
all commits will go only to github.
inxi moves to github, despite my dislike of for profit source repos, and git,
I decided that I just don't have the time or energy to do it right, so I'm going
to use github.
The project is already moved, though I have left inxi up for the time being on
code.google.com/p/inxi until I move the wiki to http://smxi.org
Everything is pretty much the same, the project url is:
https://github.com/smxi/inxi
The direct download link for the gz is:
https://github.com/smxi/inxi/raw/master/inxi.tar.gz
git pull is:
git pull https://github.com/smxi/inxi master
svn checkout url:
https://github.com/smxi/inxi
And that's about it.
2015-08-20 23:32:57 +00:00
|
|
|
.I https://github.com/smxi/inxi
|
2017-09-22 00:12:58 +00:00
|
|
|
.I https://smxi.org/
|
2012-09-15 09:18:08 +00:00
|
|
|
.SH AUTHOR AND CONTRIBUTORS TO CODE
|
|
|
|
|
.B inxi
|
|
|
|
|
is is a fork of locsmif's largely unmaintained yet very clever, infobash script.
|
|
|
|
|
|
|
|
|
|
Original infobash author and copyright holder:
|
2017-06-09 17:14:28 +00:00
|
|
|
Copyright (C) 2005\-2007 Michiel de Boer a.k.a. locsmif
|
2012-09-15 09:18:08 +00:00
|
|
|
|
2017-06-29 19:56:23 +00:00
|
|
|
inxi version: Copyright (C) 2008\-17 Harald Hope
|
2012-09-15 09:18:08 +00:00
|
|
|
|
New version, new tarball, new man page. Deprecated xiin uploader, which completes the deprecation
of the xiin.py tool, which is going to become obsolete when python 3 fully replaces python 2.
Since the odds of perl being around and stable are far higher than the odds of xiin.py
even working on python 3, I'm getting ahead of the race. Plus Perl is nicer to work with.
And Perl is a lot faster. I mean, a lot. Not slightly.
And it also works on much older systems, and does not have that Python version < 2.6
failure due to changing Python syntax even between sub versions. xiin.py never ran on
Python 2.5 even when it was relatively recent, which is one reason I'm removing all Python
from inxi.
Basically xiin.py worked only on Python 2.6 or 2.7, period.
Oh, and also handled issue #115 by not making -B show -M data.
2017-08-23 23:14:47 +00:00
|
|
|
Initial CPU logic, konversation version logic, occasional maintenance fixes,
|
|
|
|
|
and the initial xiin.py tool for /sys parsing (deprecated but still very much
|
|
|
|
|
appreciated for all the valuable debugger data it helped generate): Scott Rogers
|
2016-12-21 03:57:41 +00:00
|
|
|
|
|
|
|
|
Further fixes (listed as known):
|
|
|
|
|
|
|
|
|
|
Horst Tritremmel <hjt at sidux.com>
|
2012-09-15 09:18:08 +00:00
|
|
|
|
2017-06-09 17:14:28 +00:00
|
|
|
Steven Barrett (aka: damentz) \- usb audio patch; swap percent used patch.
|
2016-12-21 03:57:41 +00:00
|
|
|
|
2017-06-09 17:14:28 +00:00
|
|
|
Jarett.Stevens \- dmidecode \-M patch for older systems with no /sys
|
2012-09-15 09:18:08 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
And a special thanks to the nice people at irc.oftc.net channels
|
|
|
|
|
#linux\-smokers\-club and #smxi, who all really have to be considered to
|
|
|
|
|
be co\-developers because of their non\-stop enthusiasm and willingness to
|
|
|
|
|
provide real time testing and debugging of inxi development.
|
2016-12-21 03:57:41 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
A further thanks to the Siduction forum members, who have helped get some
|
|
|
|
|
features working by providing a lot of datasets that revealed possible variations,
|
|
|
|
|
particularly for the ram \fB\-m\fR option.
|
2016-12-21 03:57:41 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Further thanks to the various inxi package maintainers, distro support people,
|
|
|
|
|
forum moderators, and in particular, sys admins with their particular issues,
|
|
|
|
|
which almost always help make inxi better, and any others who contribute ideas,
|
|
|
|
|
suggestions, and patches.
|
2012-09-15 09:18:08 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
Without a wide range of diverse Linux kernel based Free Desktop systems to test
|
|
|
|
|
on, we could never have gotten inxi to be as reliable and solid as it's turning
|
|
|
|
|
out to be.
|
2012-09-15 09:18:08 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
And of course, big thanks locsmif, who figured out a lot of the core methods,
|
|
|
|
|
logic, and tricks used in inxi.
|
2012-09-15 09:18:08 +00:00
|
|
|
|
New version, new tarball, new man page. This is the first attempt to correct an
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
2017-11-29 01:23:41 +00:00
|
|
|
This Man page was originally created by Gordon Spencer (aka aus9) and is
|
|
|
|
|
maintained by Harald Hope (aka h2 or TechAdmin).
|
