procinfo and procinfo-ng : Get system information from /proc.

The Fedora Project logo
The Fedora Project logo (Photo credit: Wikipedia)

Install procinfo or procinfo-ng. The procinfo contains three programs :

/usr/bin/lsdev
/usr/bin/procinfo
/usr/bin/socklist

and procinfo-ng contains ::

/usr/bin/procinfo-ng

The description for both of them is similar ::

Name        : procinfo-ng
Version     : 2.0.304
Release     : 5.fc17
Architecture: i686
Install Date: Tue 24 Jul 2012 05:45:10 PM IST
Group       : Applications/System
Size        : 140366
License     : GPLv2 and LGPLv2
Signature   : RSA/SHA256, Mon 12 Mar 2012 09:56:55 PM IST, Key ID 50e94c991aca3465
Source RPM  : procinfo-ng-2.0.304-5.fc17.src.rpm
Build Date  : Wed 29 Feb 2012 02:30:54 AM IST
Build Host  : x86-06.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : http://sourceforge.net/projects/procinfo-ng/
Summary     : Console-based system monitoring utility
Description :
Procinfo-NG is a complete rewrite of the old system monitoring application
procinfo.  The goal is to make more readable (and reusable) code and to
restore broken functionality.

So, just install these with ::

sudo yum install procinfo procinfo-ng
Enhanced by Zemanta

colorgcc – Color your compiler output on Fedora

Lets start with installing colorgcc :

sudo yum install colorgcc

Now once that is done, you will need to ensure that the call to g++, gcc and others that you want to use, you will need to create a link in the “~/bin” directory, like so:

for i in g++ gcc c++ cc 
do
    ln -s $(which colorgcc) ~/bin/$i
done

The one liner above will create the links for colorgcc as your favourite compiler in your homedir. Don’t forget to add the bin diretory to your PATH variable:

export PATH=~/bin:$PATH

And now finally the ~/.colorgccrc file taken from Ubuntu for your reference:

#
# colorgcc configuration file
#
# $Id: colorgccrc,v 1.1.1.1 1999/04/25 15:24:03 jamoyers Exp $
#
# This file should be named $HOME/.colorgccrc
#
#
# The following groups of attributes may be combined for a given color:
#
# clear         black      on_black
# reset            red        on_red
# bold            green      on_green
# underline     yellow     on_yellow
# underscore    blue       on_blue
# blink            magenta    on_magenta
# reverse       cyan       on_cyan
# concealed     white      on_white
#
# For example, srcColor: bold cyan on_yellow
#

# gccVersion: if defined, append "-" to the compiler paths
# defined hereunder. Otherwise, those paths remains as is set
# gccVersion: 4.1.1

# Define the paths to the actual location of the various compilers.
# (Currently, colorgcc only understands these: g++ gcc c++ cc g77 f77 gcj)
g++: /usr/bin/g++
gcc: /usr/bin/gcc
c++: /usr/bin/g++
cc:  /usr/bin/gcc
#g77: /usr/bin/g77
#f77: /usr/bin/g77
#gcj: /usr/bin/gcj

# Don't do color if our terminal type ($TERM) is one of these.
# (List all terminal types on one line, seperated by whitespace.)
nocolor: dumb emacs

# Text between ` and ' is usually source code.
srcColor: bold cyan

# Text other than a warning or error.
introColor: reset

# Warnings and errors both have similar formats:
#    filename:999:Message
# Each field may be assigned a different color.

# Warnings
warningFileNameColor: reset
warningNumberColor:   blue
warningMessageColor:  yellow

# Errors
errorFileNameColor: reset
errorNumberColor:   blue
errorMessageColor:  bold red

# Possible translations, if you use localized compiler.
# (List all translations on one line, seperated by whitespace.)
warningTranslations:
errorTranslations:
Enhanced by Zemanta

/bash debugger

9.2. A bash Debugger

In this section we’ll develop a very basic debugger for bash.[10] Most debuggers have numerous sophisticated features that help a programmer in dissecting a program, but just about all of them include the ability to step through a running program, stop it at selected places, and examine the values of variables. These simple features are what we will concentrate on providing in our debugger. Specifically, we’ll provide the ability to:

[10] Unfortunately, the debugger will not work with versions of bash prior to 2.0, because they do not implement the DEBUG signal.

  • Specify places in the program at which to stop execution. These are called breakpoints.
  • Execute a specified number of statements in the program. This is called stepping.
  • Examine and change the state of the program during its execution. This includes being able to print out the values of variables and change them when the program is stopped at a breakpoint or after stepping.
  • Print out the source code we are debugging along with indications of where breakpoints are and what line in the program we are currently executing.
  • Provide the debugging capability without having to change the original source code of the program we wish to debug in any way.

As you will see, the capability to do all of these things (and more) is easily provided by the constructs and methods we have seen in previous chapters.

9.2.1. Structure of the Debugger

The bashdb debugger works by taking a shell script and turning it into a debugger for itself. It does this by concatenating debugger functionality and the target script, which we’ll call the guinea pig script, and storing it in another file that then gets executed. The process is transparent to users—they will be unaware that the code that is executing is actually a modified copy of their script.

The bash debugger has three main sections: the driver, the preamble, and the debugger functions.

9.2.1.1 The driver script

The driver script is responsible for setting everything up. It is a script called bashdb and looks like this:

 # bashdb - a bash debugger # Driver Script: concatenates the preamble and the target script # and then executes the new script.

echo 'bash Debugger version 1.0'

_dbname=${0##*/}

if (( $# < 1 )) ; then echo "$_dbname: Usage: $_dbname filename" >&2 exit 1 fi

_guineapig=$1

if [ ! -r $1 ]; then echo "$_dbname: Cannot read file '$_guineapig'." >&2 exit 1 fi

shift

_tmpdir=/tmp _libdir=. _debugfile=$_tmpdir/bashdb.$$  # temporary file for script that is being debugged cat $_libdir/bashdb.pre $_guineapig > $_debugfile exec bash $_debugfile $_guineapig $_tmpdir $_libdir "$@"

bashdb takes as the first argument the name of guinea pig file. Any subsequent arguments are passed on to the guinea pig as its positional parameters.

If no arguments are given, bashdb prints out a usage line and exits with an error status. Otherwise, it checks to see if the file exists. If it doesn’t, exist then bashdb prints a message and exits with an error status. If all is in order, bashdb constructs a temporary file in the way we saw in the last chapter. If you don’t have (or don’t have access to) /tmp on your system, then you can substitute a different directory for _tmpdir.[11] The variable _libdir is the name of the directory that contains files needed by bashdb (bashdb.pre and bashdb.fns). If you are installing bashdb on your system for everyone to use, you might want to place them in /usr/lib.

[11] All function names and variables (except those local to functions) in bashdb have names beginning with an underscore (_), to minimize the possibility of clashes with names in the guinea pig script.

The cat statement builds the modified copy of the guinea pig file: it contains the script found in bashdb.pre (which we’ll look at shortly) followed by a copy of the guinea pig.

9.2.1.2 exec

The last line runs the newly created script with exec, a statement we haven’t discussed yet. We’ve chosen to wait until now to introduce it because—as we think you’ll agree—it can be dangerous. exec takes its arguments as a command line and runs the command in place of the current program, in the same process. In other words, a shell that runs exec will terminate immediately and be replaced by exec’s arguments.[12]

[12] exec can also be used with an I/O redirector only; this makes the redirector take effect for the remainder of the script or login session. For example, the line exec 2>errlog at the top of a script directs standard error to the file errlog for the rest of the script.

In our script, exec just runs the newly constructed shell script, i.e., the guinea pig with its debugger, in another shell. It passes the new script three arguments—the name of the original guinea pig file ($_guineapig), the name of the temporary directory ($_tmpdir), and the name of the library directory ($_libdir)—followed by the user’s positional parameters, if any.

9.2.2. The Preamble

Now we’ll look at the code that gets prepended to the guinea pig script; we call this the preamble. It’s kept in the file bashdb.pre and looks like this:

 # bashdb preamble # This file gets prepended to the shell script being debugged. # Arguments: # $1 = the name of the original guinea pig script # $2 = the directory where temporary files are stored # $3 = the directory where bashdb.pre and bashdb.fns are stored

_debugfile=$0 _guineapig=$1

_tmpdir=$2 _libdir=$3

shift 3

source $_libdir/bashdb.fns _linebp= let _trace=0 let _i=1

while read; do _lines[$_i]=$REPLY let _i=$_i+1 done < $_guineapig

trap _cleanup EXIT let _steps=1 trap '_steptrap $(( $LINENO -29 ))' DEBUG

Head over to :
http://book.chinaunix.net/special/ebook/oreilly/Learning_bash_Shell/0596009658/bash3-CHP-9-SECT-2.html
Enhanced by Zemanta