Steven W. Orr wrote:
On Friday, Mar 20th 2009 at 00:39 -0000, quoth Cameron Simpson:
=>On 19Mar2009 18:55, Daniel B. Thurman <dant@xxxxxxxxx> wrote:
=>> Cameron Simpson wrote:
=>>> Ok, but I strongly recommend you never us a regexp unquoted - the
=>>> necessary backslash nesting gets nasty real fast. A better way is like
=>>> this:
=>>> re='s/b/h/'
=>>> sed -e "$re"
=>[...]
=>>> The point here, unrelated to the pipe exit status issue, is to keep the
=>>> sed stuff easy to write and undamaged by shell substitution. [...]
=>>
=>> Another person sent me private email
=>> warning of the double-quotes, but thanks
=>> for your information, it is interesting!
=>>
=>> This is what I ended up doing, so please give
=>> your constructive critiques, if you so like?
=>
=>Untested, but here is how I would write each of you code pieces were I doing
=>it myself:
=>
=>> TRACKER="Tracker.log"
=>> SFILE="Bad_Hosts_File.txt"
=>> TFILE="Bad_Hosts_File_$$.txt"
=>
=>tracker=Tracker.log
=>sfile=Bad_Hosts_File.txt
=>tfile=Bad_Hosts_File_$$.txt
=>
=>Your quotes are unneeded here. Plenty of people find the "" marks and in
=>similar cases, to use ${foo} instead of $foo elsewhere, but I find the
=>syntactic noise annoying if there's no other necessity.
=>
=>Also, you should never use UPPER CASE names for script local variables (i.e.
=>that are not to be exported). I give some background why here:
=>
=> http://markmail.org/message/awimhb3nmu6ssvwp
One historical tidbit I'd like to share with you. Back when the TRex was
tromping around, I worked at Data General during Soul Of A New Machine.
The deal there was that all external variables under AOS had to be
uppercase. The reason for this was because we sometimes needed to access
variables by name at link-time and the CLI (Command Line Interface, a sort
of macro processor) was case insensitive, so all commands caused
everything to be flipped to uppercase, no matter what we wanted. The
result was that all external variables ended up as uppercase, just in
case. :-)
=>
=>> pat="EACC"
=>
=>pat=EACC
=>
=>> re1="-e '/$pat/s/^.*Received:\[from\s\+\(.*\)\s\+(.*/\1/'"
=>> re2="-e '/^.*cdkkt.com$/d'"
=>
=>Note that this "$" should probably be backslashed. As it happens, $/ is
=>not a shell special variable, so it is left alone. However, has you used
=>$# or one of the others ($!, et al) there would have been substitution
=>done, mangling your sed code.
=>
=>> rex="sed $re1 $re2"
=>
=>I would strongly reommend putting this in a sed script file, perhaps
=>like this:
=>
=> cat >sedf$$ <<X
=> /$pat/s/^.*Received:\[from\s\+\(.*\)\s\+(.*/\1/
=> /^.*cdkkt.com\$/d
=> X
=> rex="sed -f sedf$$"
=>
=>Hmm, actually, maybe not. Maybe like this:
=>
=> sedline="/$pat/s/^.*Received:\[from\s\+\(.*\)\s\+(.*/\1/; /^.*cdkkt.com\$/d"
=>
=>and then:
=>
=> sed -e "$sedline"
=>
=>in your pipeline lower down.
=>
=>> echo -en "\033[0;36m>> \033[0;35mExtracting data from:\n \
=>> [\033[0;34m${TRACKER}\033[0;35m and appending to\n \
=>> [\033[0;34m${TFILE}\033[0;35m]\033[0m"
=>
=>I usually put escape sequences into their own variables for readbility,
=>like this:
=>
=> http://www.cskk.ezoshosting.com/cs/rc/shell/colour_ansi
=>
=>Then you can talk about ${tty_green}, ${tty_normal} etc in your text;
=>somewhat more readable. You can do even better than this, actually.
=>Since not all terminals use the ANSI colour escapes, it is better to use
=>tput, like this:
=>
=> http://www.cskk.ezoshosting.com/cs/css/bin/with-colour
=>
=>and then in your script:
=>
=> esc_tracker=`with-colour green echo "$TRACKER"`
=>
=>and then use ${esc_tracker} in messages. And so forth.
=>
=>> out=$(grep "$pat" "${TRACKER}" | \
=>> eval "$rex" | sort -n | \
=>> uniq >> "${TFILE}"); ret="$?";
=>>
=>> if [ "$ret" -gt 0 ] || \
=>> [ "$PIPESTATUS[0]" -gt 0 ] || \
=>> [ "$PIPESTATUS[1]" -gt 0 ] || \
=>> [ "$PIPESTATUS[2]" -gt 0 ] || \
=>> [ "$PIPESTATUS[3]" -gt 0 ]; then
=>> echo -e " \033[0;31mFailed.\n \
=>> \033[0;35m-- ErrorStatus:<ret=$ret>,\
=>> PipeStatus:<$PIPESTATUS[@]>\n\
=>> -- out:<$out>\033[0m"
=>> echo -e "\033[0;31m>> \033[0;31m$PROG exited.\033[0m\n"
=>> exit 1
=>> fi
=>> echo -e " \033[0;32mDone.\033[0m";
=>>
=>> I guess the ugly part is the multiple $PIPESTATUS[n]
=>> in the if statement test block. but perhaps this is the best
=>> I can do?
=>
=>Nah. You can do this:
=>
=> if out=$(grep "$pat" "$tracker" | $rex | sort -un >>"$tfile")
Please note:
When I tried `sort -un', the data was truncated, i.e.
there is data loss. So, when I went back to my original
code using 'sort -n | uniq', there is no data loss. There
seems to be a problem using the `sort -un' method.
What I do in my code, is to create a copy of the sorted
and uniq'd original file to a temp file, and then append
new data to the temp file, then sorted and uniq the temp
file back into the original file. The result was a file that
ended up much smaller than the original file!
=> then
=> case " $PIPESTATUS" in
=> *' '[1-9]*)
=> echo exit ok, but PIPESTATUS=$PIPESTATUS
=> ;;
=> *)echo exit ok and PIPESTATUS all zeroes
=> ;;
=> esac
=> else
=> echo exit not ok
=> fi
=>
=>Um, you are aware that $out will always be empty? You have sent
=>standard out to the temp file. Standard error is not collected by back
=>ticks or $(); it will be displayed directly and not land in $out.
=>You probably need to go:
=>
=> out=$(exec 2>&1; grep .... >>"$tfile")
=>
=>An easy test is like this:
=>
=> out=$(ls /no/such/file >>temp)
=> echo "out=[$out]"
=>
=>versus:
=>
=> out=$(exec 2>&1; ls /no/such/file >>temp)
=> echo "out=[$out]"
=>
=>Cheers,
=>--
=>Cameron Simpson <cs@xxxxxxxxxx> DoD#743
=>http://www.cskk.ezoshosting.com/cs/
=>
=>The aim of AI is to make computers act like the ones in the movies.
=> - Graham Mann
=>
=>--
=>fedora-list mailing list
=>fedora-list@xxxxxxxxxx
=>To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
=>Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
=>
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
