Tech

techAdmin

About inxi
inxi is a fork of infobash by locsmif. Because the code was simply not workable, and required a full refactoring, and because trash80 has already started rewriting the core logic engines, we decided we might as well start the script fork now.

inxi svn
Here is the inxi svn site. Here is the svn source view and checkout.

Download and install options
You can download the latest version here (shortcut url to googlecode).

I recommend putting inxi into /usr/local/bin to make sure you don't misplace it or get multiple version in conflicting paths, but you don't have to. But you really should.

ALERT: Arch Linux users report that /usr/local/bin is NOT in their default system path, so they will need to put inxi in /usr/bin instead.

Here's a one liner download and install, you must do this as root:

:: Code ::

cd /usr/local/bin && wget -Nc techpatterns.com/inxi && chmod +x inxi

After the code is more or less refactored, I'll probably add this to the smxi.zip installer package as well to make things easier for everyone.

smxi + inxi installer
smxi will have an option now to install inxi as well. I'm removing the infobash installer option because infobash is just too bit rotted to use any longer, and it has some bugs that aren't fixed, so that's going to be dropped in smxi.

inxi script self updater, inxi -U
Rather than force you to redownload each latest release, I added an option to do that automatically: inxi -U (for update).

If you chmod or chown /usr/local/bin/inxi to user, you can do -U as user. That's what I am doing for dev purposes, it's more convenient that way.

Long term project goals

replace the Cathbard infobash.deb with inxi.deb package
refactor all core variable names and functions to make clear, logical ordering and variable naming.
remove and refactor all features that use incomprehensible and non-debuggable bash methods.
replace all core engines with the new ones trash80 is working on in his spare time. This should be close to done by the end of December 2008.
fix options to use standard option syntax, and add more useful output options as deemed possible and worthwhile. The days of infobash being stuck in buggy bit purgatory are ending now.
add, for developers, useful debugger logging of all data.

That's about it for now, I expect to have most refactoring done within a few days, at least the basic stuff, then trash80 will probably get to his parts at some point when he gets some free time.

Coding Conventions
This project is open to serious developers who are willing to abide by sane, standard coding conventions:

indentation: tabs (that way you all set your desired tab width, it's cleaner that way)
No one liner flow controls under any circumstances, ie: [ "$something" == 'x' ] && statement...
No use of ';' instead of newline, except for if/elif. This means, no ....; do.... done type things, same for some_function(){.
:: Code ::
if [[ $something == 'true' ]];then
# but
while something
do
.....
done
# and
some_function()
{
....
}
# NEVER!!! do
statement;more statements;other statements
# ALWAYS do
statement
more statements
other statements

This is about easily scan-able vertical column flow, ie, all statements are on the same line vertically, all flow controls start and end on the same vertical column.
no use of [ ..... ], always [[ ..... ]]
within [[...]] always use &&, || operators, -a or -o don't work. This helps keep things clear and readable.
always use == or -eq for tests, and = for assignments
Use clear variable names for tests, do not put the test into the condition, create a clear variable name that explicitly states what the test is, then test that variable in the condition.
All global variables are upper case, clear words separated by _, ie: SCRIPT_COLORS. All globals must be initialized on top of the script, without exception.
All functions that use local variables must initialize the local variables at the beginning of each function, without exception. Local variables take the form some_value, ie, lower case, words separated by _.
IMPORTANT - Readability is ALWAYS to be preferred over terseness or brevity, this is the top reason we had to fork this project, the code was totally unreadable, so there's no way we'll let that type of bad habit back in again.

Final comments
And that's about it for now, just wanted to get something up so anyone who wants to get involved can do so.

Since inxi is aimed at all linux distros, without exception, serious developers are encouraged to join, after showing they are reliable and can follow the coding conventions. The current project owners are trash80 and myself, which is probably where it will stay unless someone shows long term commitment, but we're happy to add developers as non owning contributors with svn access.
Back to top

trash80

Because of the many modifications done to inxi since the fork with infobash, the dependency of Bash 2.05b has been upgraded to a minimum of Bash 3.0, but it is suggested that Bash 3.1 be installed.

Bash 2.05b is too outdated, having a release date of 2000. It does not handle "grep -m" at all.
Bash 3.0 does not handle arrays, but otherwise works ok.
Bash 3.1 was released in 2005, and currently supports all inxi features.

Currently, DSL is the only known distro using Bash 2.05b.
Puppy Linux uses Bash 3.0, even in its current release ( Dec, 2008) 4.1.2
I put in a request to have Bash 3.1 added to the next Puppy release.
Back to top

trash80

Find whether a cpu is hyperthreaded or not started out as a pita, the locsmif found this site:

www.vanginderachter.be/2008/smp-vs-multi-core-vs-hyper-threading/

which explains how to detect whether a system:

1) Has more than one physical processor
2) Has more than one core per processor
3) Has Hyper-Threading (HT) technology on the cpu

We also found out information about bash 3.0, basically:
arrays were enabled beginning in release 2.05, but a bug in 3.0 broke the array handling. Which was fixed with a patch, which isn't always included. 3.1 included the fix.

Here are the links that explains it:

ftp.gnu.org/gnu/bash/bash-3.0-patches/bash30-008
lists.gnu.org/archive/html/bug-bash/2004-08/msg00144.html
Back to top

techAdmin

Ghstryder 2x dual core, Xeon cpu, reporting as single core, with 4 cores

:: Code ::

System: Host gx280-debian Kernel 2.6.28-1.slh.2-sidux-686 i686 (32 bit) Distro Debian GNU/Linux 5.0
CPU: Single Core HT Intel Xeon cache 1024 KB flags (sse3 nx lm) bmips 7181.88
Clock Speeds: (1) 3590.941 MHz (2) 3590.941 MHz (3) 3590.941 MHz (4) 3590.941 MHz
Client Shell inxi 0.9.5

:: Quote ::

For what it's worth. Obviously nothing creates any hardship.
The system has (2) 3.6 GHz dual core Xeons.

:: Code ::

processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Xeon(TM) CPU 3.60GHz
stepping : 1
cpu MHz : 3590.941
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 3
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pebs bts pni dtes64 monitor ds_cpl est tm2 cid cx16 xtpr
bogomips : 7181.88
clflush size : 64
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Xeon(TM) CPU 3.60GHz
stepping : 1
cpu MHz : 3590.941
cache size : 1024 KB
physical id : 3
siblings : 2
core id : 0
cpu cores : 1
apicid : 6
initial apicid : 6
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 3
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pebs bts pni dtes64 monitor ds_cpl est tm2 cid cx16 xtpr
bogomips : 7181.71
clflush size : 64
power management:

processor : 2
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Xeon(TM) CPU 3.60GHz
stepping : 1
cpu MHz : 3590.941
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 1
initial apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 3
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pebs bts pni dtes64 monitor ds_cpl est tm2 cid cx16 xtpr
bogomips : 7181.70
clflush size : 64
power management:

processor : 3
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Xeon(TM) CPU 3.60GHz
stepping : 1
cpu MHz : 3590.941
cache size : 1024 KB
physical id : 3
siblings : 2
core id : 0
cpu cores : 1
apicid : 7
initial apicid : 7
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 3
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pebs bts pni dtes64 monitor ds_cpl est tm2 cid cx16 xtpr
bogomips : 7181.70
clflush size : 64
power management:

Back to top

trash80

Those are actually 2 individual single core, HT capable processors; Ghst was using information reported by the kernel. Upon further research, I found the correct specifications for the processor.

Operating Systems see the HT core as another processor when it is really just parts of a processor that can run some types of threads.

So far, after many benchmarks I've looked at online, HT does not seem to do much at all. At least not until multi-threaded apps are the norm.

Anyhow, Single Core HT is right, per my logic. The information I had, I used in the logic, and there was no information about Xeon's being HT. At the time the i7 processor had not been fully released, which is the only multi-core processor with HT.

So now I have to reconfigure the logic to find HT in SMP and HT in Multi-Core.

At this time there is not enough testers for SMP Multi-Core, the logic may have to be adjusted again. But I do believe that part is sound.

Thanks,
Back to top

trash80

!!! Information reguarding ssh forwarding of graphics info !!!

:: Quote ::

I ran across the cure for this a while ago on the net, and just happened to brush it
off....
I found this while looking for ways to turn an old cheap laptop into a digital
picture frame, which sometimes needs the user to ssh onto the "frame" from a remote
computer. Anyhow, during this adventure, I came across an option in ssh to forward
the guest box graphics data back to the host box. So I know it can be done, but I
have forgotten the option and the website.

What I'm saying is: this is not an inxi feature or bug, but user know how on ssh.
This "issue" needs to be "fixed" (removed) as it is a non-issue for inxi.

If/when I find this info again, it will be posted on the techpatterns' forum.

I posted this to a feature request/bug report on the svn site, and thought it should also be here in the dev forum to for future reference.
Back to top

trash80

The Konversation dev's decided to change their api for the qt4 version, which caused inxi to stop working correctly (Konversation 1.2).

On change was an improvement--the move to dbus. Dbus is a better internal messaging system for programs. It improves upon Dcop, while maintaining a similer api (similar, not same).

ie dcop
dcop <port> <object> say <server> <channel> "<print this>"

qdbus (qt's version of dbus)
qdbus org.kde.konversation /irc say <server> <channel> "<print this>

in dcop, port was the app name, ie 'Konversation'
with dbus, the port is removed. I am unsure if this is a qdbus change or the Konversation dev's changed it. But it seems to be the second to me.

Because of this change--assumed Konversation api change--we can no longer tell inxi who called it (konversation). Therefore I have implemented a temporary fix/band-aid for the new qt4 dbus Konversation 1.2 alpha. This beta version of inxi can be used by 'inxi -! 12'.

Although I might create a new branche for this beta (alpha?) inxi until the release of konvi 1.2. Nothing has changed for previous versions of konvi.

The 'fix' allows inxi to see if any other irc client is the parent, if not, then it falls into a test to see if Konvi 1.2 is running. From this test, inxi just infers the presence and usage of Konvi 1.2. This is not great, but seems to work. It could possibly cause a bug. ie two irc clients are open, one Konvi 1.2, the other could be an unsupported irc client that fails the inxi client test. The test could allow a false positive presence of Konversation--which is present, but not necessarily the parent calling app. This would cause inxi to fail to post to the unsupported irc client.

Because of how dbus is settup, calling inxi from an unsupported irc client won't post to Konversation. It would not have the <server> and <channel>, unless the unsupported irc client passes them as $1 and $2. Then an inadvertent post to Konvi 1.2 could occur. But this would not be bad. The only way this could happen is if both unsupported icr client and Konvi 1.2 are on the same servers and channels, which the user was intending to display inxi anyhow.

I don't like this fix, and am posting a bug to Konvi 1.2. And since Konvi 1.2 is alpha, there is no reason to officially support it at this time.

As more information comes in, inxi for konvi 1.2 will address changes that effect it's usage.
Back to top

trash80

Since ban_string is the only var not declared, it automatically takes $@, which is the information sent to it. By declaring it first, removes $@. But if you declare ban_string as $@, it works.

:: Code ::

# Filter boilerplate & buzzwords.
# args: $1 - quoted: "$@" array of ban terms
make_ban_lists()
{
eval $LOGFS
local ban_list=''
# Iterate over $@
## note: this is a weird, non-intuitive method, needs some documentation or rewriting
## if you declare ban_string it stops working, have to read up on this
for ban_string
do
   # echo "term=\"$ban_string\"" # >&2
   if [[ ${ban_string:0:1} = $'\2' ]];then
      ban_list="${ban_list}${ban_list+|}${ban_string:1:${#ban_string}-1}"
   else
      # Automatically escapes [ ] ( ) . and +
      ban_list="${ban_list}${ban_list+|}$( echo "$ban_string" | gawk '{
         gsub(/([\[\]+().])/,"\\\\&")
         print
      }' )"
   fi
done

echo "$ban_list"
eval $LOGFS
}
# make_ban_lists "${A_CPU_BANS[@]}";exit

Back to top

trash80

Updated and hopefully simplified the
get_cpu<data>. We no longer care what the
numbers are, all we do is count unique
ids. Now we ignore the id identifier
number, since the new i series from Intel
either kills a logical processor or ships
flawed quad cores as dual or dual HT,
maybe even tri-core sometime. The new
logic only cares about the number of
cores, the number of physical processors,
and the number of virtual processors.
Back to top

KenJackson

This code is in function get_networking_wan_ip_data():

:: Code ::

ip=$( wget -q -O - http://smxi.org/opt/ip.php | gawk -F 'is: ' '{
#gsub("\n","",$2")
print $2
}' )

It could be simplified slightly with this line. This queryip.net URL does the same thing, but it returns only the IP address, with no extraneous text--not even a new-line character.

:: Code ::

ip=$(wget -q -O- http://queryip.net/ip/)

Back to top

Tech

Tech

patterns.com

tech forums