Doing anything more really doesn't gain you much, because the shell doesn't do much, and you wouldn't be able to eliminate a single fork. So you'd be replacing one launcher with another. Why bother?

With respect, the shell can do quite a lot. Korn shell and Bash are more than just program launchers, Bash 3, for example, supports Extended REs. Whole applications are written in Korn, however mis-guided that might be.
I agree that converting a shell script that just called external programs to a perl script that called the same external programs would be a waste of time, but I hope to replace utility programs with Perl equivalents.

No, you can't really eliminate any forks, because you don't know who needs to know $? at the right time, or depends on a certain number of kids being present.

It's like any translation problem... there's the surface syntax, which might appear relatively easy to translate, but then there's the deep semantics: all the side effects of the steps. So you either have to emulate the deep semantics precisely, or you have to analyze and understand enough of the rest of the program to know what you can avoid emulating. Ugh, on either side.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

#!/bin/ksh
####### Error Log Script #############################################
+####################
######################################################################
+#####################
function find
{
        flag=0
        if [ ! -d ~/logs ]; then
                mkdir ~/logs
        fi
                date=`date +%Y-%m-%d-%s`
                while true
                do
                grep -ni "$keyword" $source | while read line
                do
                        if [ "$(ls -A ~/logs 2> /dev/null)" == "" ]; t
+hen
                             echo $line >> ~/logs/sanity-$date.log
                             flag=1
                        else
                                result=`cat ~/logs/* | grep -F "$line"
+`
                                if [ "$result" != "$line" ]; then
                                        echo $line >> ~/logs/sanity-$d
+ate.log
                                        flag=1
                                fi
                        fi
                done
                done
                if [ $flag == 1 ];  then
                        echo "########################################
+#############################################"
                        echo "Errors or Exception found. Extraction is
+ copied in the file ~/logs/sanity-$date.log"
                        echo "########################################
+#############################################"
                else
                        echo "###################"
                        echo "No new logs Found"
                        echo "###################"
                fi
}
action=$1       #Start or Stop
dir=$2
file=$3         #Source filename
keyword=$4      #Search String
case $action in
                start)
                        if [ "$dir" == "" ]; then
                                echo "Enter the path"
                                exit
                        fi
                        if [ ! -d $dir ]; then
                                echo "Directory not found"
                                exit
                        fi
                        if [ "$file" == "" ]; then
                                echo "Enter the filename"
                                exit
                        fi
                        if [ ! -f $dir/$file ]; then
                                echo "No File found"
                                exit
                        fi
                        source=$dir/$file
                        if [ "$keyword" == "" ]; then
                                echo "Enter a keyword for search"
                                exit
                        fi
                        find
                        exit
                ;;
                stop)
                        echo "killed"
                        exit
                ;;
                *)
                        echo '########################################
+##############################'
                        echo 'Usage: sh parser.sh [start/stop] [Direct
+ory path] [Filename] [Keyword]'
                        echo 'Sample: sh parser.sh start /var/log/ mes
+sages "test"'
                        echo '########################################
+##############################'
                        exit
                ;;

esac
[download]

Sounds like a fun project with lots of pain. :-)

How about about patching 'bash' to show what is done? There might even be some debugging stuff in there already, which could be used?

Then you could get a log of:

 Line X:   run program "a" and store output into "b".
 Line X+1: Do something if $? == c
[download]

It should make it easier to generate Perl code and you could get the return codes, etc.

Hmm... could generate Perl programs that just did "system" calls and then rewrite them by parts.

Yep, I looked at that. I also considered 'lifting' the parser from Bash rather than writing my own, seemed daft to write my own parser when there was already a perfectly good one there. Unfortunately I found that it was not so easy to extract it as a separate entity, it is integrated into the whole product. Someone like Chet Ramey could probably do it, not me.
As for the pain, this is working out to be almost as good as whipping myself with nettles - Ahhhhh. (No nettles were harmed in the writing of this post).

Thanks for the encouragement, yours is exactly the kind of project this is for. Fancy helping with the testing later?

It seems to me you've got 3 options there:

1. auto-translate;
con: GIGO ie crud shell input => crud Perl output.
pro: quick/low effort


2. Hand code new Perl modules as you go.
con: Takes a while, same cruddy architecture as original
pro: you'll get good, maintainable Perl that does logging etc. Also means you can replace shell files gradually, instead of the big bang approach.


3. Design a new/better ctrl system in Perl from scratch.
pro: Gives you better code and more integrated approach.
con: more effort upfront & big bang approach

I once had to do a FORTRAN to C job (Y2K) and we originally tried option (1.), but I ended up doing a fair bit of (2.) to make it work properly.
A straight option (2.) approach might have been quicker in the long run, otherwise you end up with weird looking code due to the auto-converter.


HTH Cheers
Chris

Here you are suggesting that using a shell and calling other program is necessary (much) slower than doing it all in Perl. I beg to differ. Sure, if all your program is doing is calling a different program hundreds of time, and each time it just takes a fraction of a second to run, the shell loses because of the forking overhead.

But any Perl program starts with a backstart - the start up time of a Perl program is larger than of a shell script. And the shell typically calls utilities that have been written in C, and have been optimized for decades. Your systems' 'grep' and 'sort' will typically be much faster that the Perl equivalents - the Perl equivalents pay the price of being more powerfull, and having to deal with Perl variables.

Good point, and I agree, but it's a question of scale. When these programs are called in loops (and often are) it is not unusual to get a script forking hundreds or thousands of child processes. I agree that a well written shell script can be more efficient than a Perl program, particularly when the Perl loads modules. If you have such a script I doubt it would be a candidate for conversion.

One group where I worked did such a script, to push a bunch of 'csh' scripts into the new Millennium. We wrote a simplistic mechanical translator. The scripts were a bunch of cut-and-paste monstrosities, and the results were just as cruddy. Don't expect human-readable, maintainable results.

One word of advice, anything that requires punting on the translator side should at least KNOW that it requires punting. Output a comment with '#REVIEW:' next to any surely-incomplete translated statements, for example. Then you have a little bit less work to do in hunting down the worst problems with the translated scripts.

The rest of the problems will lurk in obscurity forever.