Hey, I saw your question and came up with this jibberish, in attempt to learn a bit of bash script:
Quote:
#!/bin/bash
declare -a lineArray
if [ -e "$1" ]; then
FILE=`cat -E $1`
else
FILE=`cat -E file1`
fi
i=0
for line in $FILE; do
lineArray[$i]="${lineArray[$i]} ${line%*\$}"
if [ "$line" != "${line%*\$}" ]; then
let "i++"
fi
done
for ((s=0;s<i;s++)); do
echo ${lineArray[$s]}
done
|
The problem with your script may be 1)directly flipping the cat into loop's test w/out buffer 2)the incrementation of i in your while loop(could be a different num of elements than expected: with 5 line file 12 i's or so), or 3) bash is borked, inherently, when it comes to parsing within files--probably not 2, maybe a bit of both 3 and 1.
That stuff I wrote above seems to function to an extent, but when using 'larger' files like XF86Config it outputs some shady material. With a larger file(large maybe being line length instead of #of lines causing the problem in the string parts) there's an extra line or two about the files in my current directory; plus there's that confusing for/while read/line scope wierdness
Maybe a better solution is:
#!/bin/bash
perl parseStuff.pl
exit 0
-notaslacker
P.S. Could someone who understands bash scripting well test the above script on an xf86config or something and see if they get the same 'extra' lines? I'm curious about the possibility that it's a bug or goof on my system, rather than one of my average logic oversights. Removed comments to make it more readable.