World cup 2011 Schedule

Staright forward translation of English movie titles.

Die another day= inko roju sachipodaam.
Tomorrow never does: repu enthaki saavadu.
Gold finger: bangaaru velu
Mummy = Amma
Mummy returns= thirigochina Amma
true lies= nijam abaddam aadindi
Terminator: muginchuvaadu
I know what you did last summer: poyina vesavilo nuvvem chesaavo naaku thelsu
Hell Boy: narakapu pilladu.
Fantastic four: adbhuthamina aa naluguru.
 Angels and daemons: devathalu mariyu deyyalu
Evil dead: maa chedda chaavu
Evil dead 2: maa chedda chaavu rendosaari
Evil dead 3 : maa chedda chaavu moodosaari
salt : uppu
Rising bull: piki legusthunna yeddu
Pulp fiction: Gujju gharshana
I am legend: nenu chala goppavaadini.

A Nightmare On Elm Street: ELM veedhilo  peedakala

Wrong turn: Thappu dova
Iron Man: inapa manishi
I know who killed me: nannu sampinodu naaku thelsu
I cant think straight: nenu thinnaga aalochinchalenu.
Men In Black: Cheekatilo magaallu
Tomb rider: samaadhula meeda swari chesedi.
Mission Impossible: Asalu emi cheyyalemu
 G I Joe:The rise of Cobra: G I Joe mariyu piki lesina thachupaamu.
 Gone in 60 sec: nimishamlo poyindi.
Gone woth the wind: Gaalitho paatu poyindi.
paranormal actuivity: asaadhaaranamayina charya.
Hurt locker: Noppini bhandinchevaadu.
Priest: poojaari
vampire kiss: pisacham pettina muddu.

20 Days to the Top free download

For people who wants to sell themselves better

This
book is a winner! I've read many sales books offering the same tired
formulas and "power closes" designed to trap unsuspecting consumers into
a deceitful sales web. Refreshingly, Brian Sullivan offers a proven,
duplicatable formula based on learning what the customer really wants,
and giving it to them in an ethical way they find hard to resist. One
problem with most sales books and training is that the student has no
way to easily remember and implement what they've learned, so the
initial enthusiasm quickly wears off and sales people resort to their
old way of doing things. With easy to remember acronyms and PRECISE call
sheets, you'll soon be asking CLEAR questions and using SHARP responses
to customer concerns, and having more fun and making a lot more money
along the way. Buy this book and become a PRECISE selling superstar.

Free Download : RS Link

 

 

India's 50 Most Powerful People 2009

 From BUSINESS WEEK

In India, change is so rapid it surprises even the powerful. Fortunes vanish, markets melt down, and the most die-hard fans find someone else to love, someone else to vote for. Take, for instance, Navin Chawla. With 712 million voters considering their ballot as Indians vote on who will lead their country, one of India's most powerful men is perhaps the Chief Election Commissioner, N. Gopalaswami. India's elections began on Apr. 15 and take place in stages nationwide over several weeks. During that time, Gopalaswami is a bureaucrat with almost unlimited powers to impose order on an unruly process, moderate hate speech, and herd the world's largest democracy through a peaceful transfer of power. But on June 16, the elections will end, and he will vanish back into the labyrinth of the Indian bureaucracy. In modern India, even powerful reigns can be short-lived. In the newest edition of BusinessWeek's list of the 50 most influential Indians, politicians jostle for space with professors, businessmen with cricketers. The attempt is to pinpoint the shifts in power that defined India in the past year, and to predict the players to watch for in the next year.

LINK : CLICK HERE TO READ MORE 

Linux+ Certification Bible free download

Unleash the power of CompTIA's newest certification! Linux+ is the next hot certification to come from CompTIA, the company behind A+ with a following of 250,000+ certified and growing. Linux+ Certification Bible contains everything you need to know to pass the exam as well as practical information in one comprehensive volume! 

Free Download : Click here

Purging the process Part 1

Introduction to pipes, filters, and redirection, Part 1

Summary
If you've arrived at Unix from the graphical user interface (GUI) world of Windows or Mac OS, you're probably not familiar with pipes and filters. Even among character-based interfaces, only a few of them, such as MS-DOS, provide even rudimentary pipes and redirection.

Redirection allows a user to redirect output that would normally go to the screen and instead send it to a file or another process. Input that normally comes from the keyboard can be redirected to come from a file or another process.

Purging the process: Read the whole series!
Part 1. The basics of pipes and redirections Part 2. Pipes and redirection: More advanced features

When a typical Unix utility starts up, three files are automatically opened for you inside of it. These files are given file descriptor numbers inside the program -- 0, 1, and 2 -- but they're more commonly known as stdin (standard in -- file descriptor: 0), stdout (standard out -- file descriptor: 1) and stderr (standard error -- file descriptor: 2). When the program starts, default assignments for these files are made to /dev/tty, which is the device name for your terminal. The stdin file is assigned to the keyboard of your terminal, while stdout and stderr are assigned to its screen.

Let's start with a simple example using grep. Type a grep command to find lines containing the word hello, then type the following lines at your terminal. At the end of each line press Enter to move down to the next line. Watch what happens as you type say hello.

$ grep "hello"
Now is the time
for every good person to
say hello.

The screen repeats the last line.

$ grep "hello"
Now is the time
for every good person to
say hello.
say hello.

Hold down the Control key and press D to end the input to grep. Control-D is an end-of-file marker and can be entered as a keystroke to stop any utility that is taking its input from the keyboard.

The grep "hello" line is a command to search standard input for lines containing hello and echo any such line found to standard output. The Unix console automatically echoes anything you type, so the three lines appear on the screen as you type them. Then grep hits a line containing hello and decides to output it to standard out, and say hello appears on the screen a second time. The second appearance is the output from grep.

Standard output can be redirected to a file using the right angle bracket (>) as shown in the example below. The same grep command is redirected to send its output to a file named junk.txt. The say hello line doesn't appear a second time because it's been directed to the junk.txt file. After the user presses Control-D, cat is used to display the contents of junk.txt, which contains grep's single output line.

$ grep "hello" >junk.txt
Now is the time
for every good person to
say hello.
(type control-D here)
$ cat junk.txt
say hello.
$

Standard input can be redirected to come from a file by using the left angle bracket (<). In order to demonstrate this, we need a file that can be used for input. Use vi to create the following sample file and save it as hello.txt.

Now is the time
for every good person to
say hello.

When you type the following command, notice that the output from grep is the single say hello. Because input is being drawn from a file, you don't need to use Control-D to stop the process.

$ grep "hello" <hello.txt
say hello.

Both standard input and output are redirected in the following example. Once grep starts up, it takes its input from hello.txt and outputs the result to junk.txt. There is no output on the screen, but you can use cat to display junk.txt and verify the contents.

$ grep "hello" <hello.txt>junk.txt
$ cat junk.txt
say hello.
$

If a redirection to an output file encounters a file that already exists, that file is destroyed and a new one, containing the new output, is created, assuming the user has appropriate permissions to delete and create a new file. You can confirm this by using the previous example to search for a different line of text. In this example, the earlier version of junk.txt has been replaced with the new output from grep, the single line Now is the time

$ grep "Now" <hello.txt >junk.txt
$ cat junk.txt
Now is the time
$

There is a convention used in Unix programs which dictates that, if a file is expected as input to a program but no file is named on the command line, standard input is used. Because grep is designed to search for a string in a file, or files, it uses a command-line syntax that lets you name a file on the command line, and the input redirection symbol is not needed. Internally, grep checks if a file is named on the command line and opens and uses it. If no file name is found, standard input is used. The following command lines for grep have the identical effect.

Internally, the first command reassigns hello.txt to standard input and uses it for input; the second command opens hello.txt as a file and uses it for input. grep doesn't expect an output file to be named on the command line. To get the output into a file, you must use output redirection. It doesn't hurt to redirect grep input, but in the case of grep, the redirection is already taken care of for you on the command line.

$ grep "Now" <hello.txt >junk.txt
$ grep "Now" hello.txt >junk.txt

If you want to preserve the existing output file and append new information to it, use a double right angle bracket (>>). The following example uses echo, which normally outputs to the screen, to create the hello.txt file without using an editor. The output of the echo command is redirected into the file, and two more lines are appended to it.

$ echo "Now is the time" >hello.txt
$ echo "for every good person to" >>hello.txt
$ echo "say hello." >>hello.txt
$ cat hello.txt
Now is the time
for every good person to
say hello.
$

Pipes are created as a means of taking the output of one program and using it as the input to another. The pipe symbol (|) is used as a connector between the two programs. In the following example, look at the first part of the command up to the first pipe symbol. The cat command normally outputs to the screen; in this case, however, the output has been sent into a pipe. On the righthand side of the pipe, this output becomes the input to grep "hello". The output from grep "hello" is in turn sent into another pipe. On the right side of that pipe, the output is used as standard input to a sed command that searches for hello and replaces it with bye. The final result is redirected to a file named result.txt which cat displays on the screen as say bye.

$cat hello.txt | grep "hello" | sed -e "s/hello/bye/" > result.txt
$cat result.txt
say bye.
$

If this were broken down step by step using simple redirection, you would need several commands, as well as the final rm steps to clean up the intermediate work files that were created.

$cat hello.txt >wrk1.txt
$ grep "hello" <wrk1.txt >wrk2.txt
$ sed -e "s/hello/bye/" &ltwrk2.txt >result.txt
$cat result.txt
say bye.
$rm wrk1.txt wrk2.txt

The initial step of getting hello.txt into the grep command could also be done in several other ways. Two examples are shown below. The first redirects input to grep from hello.txt on the lefthand side of the pipe; the second puts parentheses around the grep and sed commands, groups them as a subprocess, then redirects input and output to the grouped process.

$ grep "hello" < hello.txt | sed -e "s/hello/bye/" > result.txt
$( grep "hello" | sed -e "s/hello/bye/" ) < hello.txt > result.txt
$

Redirecting standard error output
So far I've only shown you how to pipe and redirect standard output, but it's frequently useful to do something with error output. In the following example, find is being used to search the entire system (starting at / ) for files with a .txt extension. Whenever one is found, its full directory entry is placed in a file named textfiles. The example below shows sample error messages that are generated when find attempts to access an unavailable directory.

$ find / -name *.txt -exec ls -l {} \; >textfiles
find: /some/directory: Permission denied
find: /another/one: Permission denied
$

The error messages can be suppressed by redirecting them to /dev/null, which is a special device that can be thought of as a wastebasket for bytes written to it on output. Everything that goes to /dev/null disappears. To redirect standard error, use a right angle bracket preceded by a 2, which is the file descriptor number for standard error. If you don't care about error messages, send them to the /dev/null byte bucket.

$ find / -name *.txt -exec ls -l {} \; 2>/dev/null >textfiles
$

The following command combines redirection and pipes to extract and bring a full list of all .txt files sorted in order by the third field in the ls -l directory entry, the owner's name.

$ find / -name *.txt -exec ls -l {} \; 2>/dev/null |sort -k 3 >textfiles
$

Shell scripts can also redirect their output, so the above command could be put into a shell script without redirection, but the output can be redirected when the command is executed.

#!/usr/bin/sh
# usertexts
#    outputs a listing of texts files on the system, ordered by owner id

find / -name *.txt -exec ls -l {} \; 2>/dev/null |sort -k 3

This shell's script could be executed with the output redirection done at the shell script level.

$ usertexts >textfiles
$

Pipes and redirection can be combined to create very powerful tools that start a text stream and then apply different tools to that stream, filtering it as it passes through different processes.

Next month, I'll take a look at more advanced uses of pipes and redirection.

 

Purging the process, Part 2

Advanced topics in pipes, filters, and redirection

Last month I covered several basics, such as input redirection:

$ grep "hello" <hello.txt
say hello.

Purging the process: Read the whole series!
Part 1. The basics of pipes and redirections Part 2. Pipes and redirection: More advanced features

Output redirection:

$ grep "hello" >junk.txt
Now is the time
for every good person to
say hello.
(type control-D here)
$ cat junk.txt
say hello.
$

Input and output redirection, and the use of input files on the command line instead of redirected input:

$ grep "Now" <hello.txt >junk.txt
$ grep "Now" hello.txt >junk.txt

Appending additional data to a file using an output redirection:

$ echo "Now is the time" >hello.txt
$ echo "for every good person to" >>hello.txt
$ echo "say hello." >>hello.txt
$ cat hello.txt
Now is the time
for every good person to
say hello.
$

Redirecting standard output and standard error, and redirecting standard error to the /dev/null byte wastebasket:

$ find / -name *.txt -exec ls -l {} \; 2>/dev/null >textfiles
$

Basic pipes:

$ grep "hello" < hello.txt | sed -e "s/hello/bye/" > result.txt
$( grep "hello" | sed -e "s/hello/bye/" ) < hello.txt > result.txt
$

I also stated that redirecting output to an existing file would delete the file and create a new version of it. In the following example, the fourth line causes hello.txt to be overwritten with a new version of the file containing only a single line, bye.

$ echo "hello" >hello.txt
$ cat hello.txt
hello
$ echo "bye" >hello.txt
$ cat hello.txt
bye

You can set the noclobber option to prevent redirected files from automatically overwriting their predecessors. In the following example, the option causes an error message at line six when the user tries to overwrite the hello.txt file.

$ set noclobber
$ echo "hello" >hello.txt
$ cat hello.txt
hello
$ echo "bye" >hello.txt
File "hello.txt" already exists
$ cat hello.txt
hello
unset noclobber

If noclobber is set, you can force a redirection to clobber any pre-existing file by using the >| redirection operator. This operator looks like a redirection to a pipe, but it's actually just a force redirect to override the noclobber option. In the following example the forced redirection operator prevents any error messages.

$ set noclobber
$ echo "hello" >|hello.txt
$ cat hello.txt
hello
$ echo "bye" >|hello.txt
$ cat hello.txt
bye
unset noclobber

Combining standard output and standard error
Redirection is frequently used for jobs that run for a long period of time, or for jobs that produce a lot of output. For such jobs, redirection can capture the results in a file. When this is done, it's also necessary to capture any output errors. Remember that if you redirect standard output but not standard error, output will go to a file and error messages will still go to your screen. The following find command will save the results to found.txt, although errors still appear on the screen.

$ find / -name *.txt -exec ls -l {} \; >found.txt
find: /some/directory: Permission denied
find: /another/one: Permission denied
$

The redirection operator is actually a number followed by the redirection symbol, as in the following example. If number is omitted, 1 is the default.

$ find / -name *.txt -exec ls -l {} \; 1>found.txt
$

The following commands are equivalent:

$ find / -name *.txt -exec ls -l {} \; 1>found.txt
$ find / -name *.txt -exec ls -l {} \; >found.txt
$

Unix utilities open three files automatically when a program starts up. These files are given file descriptor numbers inside the program -- 0, 1, and 2 -- but they're more commonly known as stdin (standard input -- file descriptor 0), stdout (standard output -- file descriptor 1), and stderr (standard error -- file descriptor 2). When the program starts, default assignments for these files are made to /dev/tty, which is the device name for your terminal. The stdin file is assigned to the keyboard of your terminal, while stdout and stderr are assigned to the screen of your terminal. The output redirection operator defaults to 1; thus > and 1> are equivalent. The input redirection operators < and <0 are equivalent. Redirecting standard error, file descriptor 2, requires that its number be explicitly included in the redirection symbol.

The following examples use 1> to redirect standard output because it helps clarify how the redirection works. When reviewing these examples remember that > and 1> are the same.

One method of handling the logging problem would be to create separate logs for each of the outputs, as in the following example.

$ find / -name *.txt -exec ls -l {} \; 1>found.txt 2>errors.txt
$

It is also possible to redirect an output by attaching it to an already open redirection using the >& redirection operator. In the following example, the standard output of find is redirected to the file result.txt. The 2>&1 redirection command instructs the shell to attach the output from standard error (2) to the output of standard output (1). Now both standard output and standard error are sent to result.txt.

$ find / -name *.txt -exec ls -l {} \; 1>result.txt 2>&1
$

The order of redirection is important. In the following example, the output of file descriptor 2 (standard error) is attached to file descriptor 1. At this point, standard output is still attached to the terminal, so standard error is sent to the terminal. The next redirection sends standard output to result.txt. This redirection doesn't drag file descriptor 2 along with it, so standard error is left pointing to the terminal device.

$ find / -name *.txt -exec ls -l {} \; 2>&1 1>result.txt
find: /some/directory: Permission denied
find: /another/one: Permission denied
$

Input redirection from here documents
Perhaps one of the most useful forms of redirection is redirecting input from a here document. A shell script can be written that executes a command and serves all input to the command. This is frequently used for a command that is normally run interactively. As an extreme example, I will show you how to do this with the editor vi. I am using vi for two reasons: first, it's interactive, and second, you're probably fairly familiar with it already and so will have a better understanding of what the script's doing. Normally, hands-off editing is done with the sed command.

First, create a text file with several hello strings in it, as in the following example, then name it hello.txt.

sample hello.txt
hello world
hello broadway
hello dolly

Create a file named here.sh that contains the lines in the example below. The second line starts the vi editor on the hello.txt file and the <<END-OF-INPUT option states that vi will run taking its input from this current file, here.sh, reading in a line at a time until a single line containing END-OF-INPUT is read in. The subsequent lines are vi commands to globally search for hello, replace each instance of it with bye, write the file back out, then quit. The next line is the END-OF-INPUT line and final echo statement to indicate that the editing is complete.

# here.sh - sample here document
vi hello.txt <<END-OF-INPUT
:g/hello/s//bye/g
:w
:q!
END-OF-INPUT
echo "Editing complete"

Change the mode on the file to make it executable:

$ chmod a+x here.sh

When you execute the here.sh script, you may receive a warning from vi that it's not running in interactive mode. Next, the actual editing takes place; afterwards, you can cat out the hello.txt file and see your handiwork.

$ ./here.sh
Vim: Warning: Input is not from a terminal
Editing complete
$ cat hello.txt
sample bye.txt
bye world
bye broadway
bye dolly

If you really want to suppress the vi warning, redirect the error to the /dev/null device, as in the following version of here.sh:

# here.sh - sample here document
vi hello.txt 2>/dev/null <<END-OF-INPUT
:g/hello/s//bye/g
:w
:q!
END-OF-INPUT
echo "Editing complete"

here documents frequently appear as small pieces of larger scripts. In order to make the here portion stand out, it's helpful to indent that section of the shell. Using a minus (-) in front of the end-of-input marker eats the white spaces at the beginning of a line and prevents them from being passed on to the program. The following is an example:

# here.sh - sample here document
vi hello.txt 2>/dev/null <<-STOP-HERE
:g/hello/s//bye/g
:w
:q!
STOP-HERE
echo "Editing complete"

Because it's an interactive program, the ftp utility is a common candidate for here document status. The following example starts ftp and redirects standard output and standard error to xfr.log. The process logs in to a remote system named nj_system, switches to binary transfer mode, creates two directories, transfers a file named newstuff.a to the remote system, and signs out again. Using a here document makes it possible to execute ftp through a shell script while seeing what the script is doing. The second example below is another method of doing this, but it involves a separate file with the ftp commands.

# xfr.sh - Transfers to a remote system
district=nj
ftplog=xfr.log
insbase=/usr/installations
insdir=$insbase/new
inskit=newstuff.a
echo "Transferring to" $district
ftp 1>>$ftplog 2>&1 $district"_system" <<-ALL-DONE
        user mo ddd789
        binary
        mkdir $insbase
        chmod 777 $insbase
        mkdir "$insdir"
        chmod 777 $insdir
        put $inskit $insdir/$inskit
        chmod 777 $insdir/$inskit
        bye
ALL-DONE
echo "Transfer to" $district "complete."

The first file would have to contain nothing but the commands for ftp, and couldn't take advantage of script variables. Here's a sample input for ftp:

user mo ddd789
binary
mkdir /usr/installations
chmod 777 /usr/installations
mkdir /usr/installations/new
chmod 777 /usr/installations/new
put newstuff.a /usr/installations/new/newstuff.a
chmod 777 /usr/installations/new /newstuff.a
bye

# xfr.sh - Transfers to a remote system
district=nj
ftplog=xfr.log
echo "Transferring to" $district
ftp 1>>$ftplog 2>&1 $district"_system" <ftp_commands
echo "Transfer to" $district "complete."

In our next installment, I'll cover Unix system and global variables. What are they and how do you use them? I have been meaning to do this one for a while, and now seems like a good time.