0
votes

I am using TCL to control a traffic generator. When the traffic received, I want to use shark command to convert the .pcap file to a .txt file, and then I can do some other job.

But when run the exec in the program the following info print out:


    while executing
"exec tshark -Vxr /var/tmp/PCRF/create_req.pcap"
    ("eval" body line 1)
    invoked from within
"eval exec  {tshark -Vxr /var/tmp/PCRF/create_req.pcap}"
    (file "./tcp_test.tcl" line 7)

The following is the TCL script:

# Radius accounting request start packets
# Version 1.0
# Date 2014/4/16 16:38

puts "\n Begin to decode the capture file\n"
#source /var/tmp/PCRF/convert_pcap.tcl
eval exec  {tshark -Vxr /var/tmp/PCRF/create_req.pcap}
puts "\n end of the file decode and the result is rrr\n"
1
Just confirming: that was a blank line first before the rest of the trace? - Donal Fellows
When I only use exec, the followings are the script and logs: puts "\n Begin to decode the capture file\n" #source /var/tmp/PCRF/convert_pcap.tcl exec tshark -Vxr /var/tmp/PCRF/create_req.pcap puts "\n end of the file decode and the result is rrr\n" The logs: -bash-3.2# tclsh ./tcp_test.tcl Begin to decode the capture file Running as user "root" and group "root". This could be dangerous. while executing "exec tshark -Vxr /var/tmp/PCRF/create_req.pcap" (file "./tcp_test.tcl" line 7) -bash-3.2# - Adrian

1 Answers

0
votes

Tcl's exec can throw an error for two reasons. It does so if either:

  1. The subprocess returns a non-zero exit code.
  2. The subprocess writes to standard error.

The first one can be annoying, but it is genuinely how programs are supposed to indicate real errors. It can be a problem if the program also uses it in other ways (e.g., to say that nothing was found, like grep does) but that. However, in this case you get the error message child process exited abnormally so it is easy to at least figure out what happened.

More problematic is when something is written to standard error; the message written there is used as the error message after newline stripping. Even just a newline will trigger a failure, and that failure overwrites any chance of getting the real out from the program (and in the case of just a newline, is highly mysterious). Here's a (possibly) reproduction of your problem:

% exec /bin/sh -c {echo >&2}

% set errorInfo

    while executing
"exec /bin/sh -c {echo >&2}"

How to fix this? Well, you can try the -ignorestderr option (if supported by your version of Tcl, which you don't mention):

exec -ignorestderr tshark -Vxr /var/tmp/PCRF/create_req.pcap

Or you can try merging the standard output and standard error channels with 2>@1, so that the error messages are part of the overall output stream (and picked up as a normal result):

exec tshark -Vxr /var/tmp/PCRF/create_req.pcap 2>@1

Or you could use a merge-pipe (needed for older Tcl versions):

exec tshark -Vxr /var/tmp/PCRF/create_req.pcap |& cat

Or you can even direct the subprocess's standard error to the main standard error: the user (or exterior logger) will see the “error” output, but Tcl won't (and the exec won't fail):

exec tshark -Vxr /var/tmp/PCRF/create_req.pcap 2>@stderr

More elaborate things are possible with Tcl 8.6, which can make OS pipes with chan pipe, and you can (in all Tcl versions) run subprocesses as pipelines with open |… but these are probably overkill.


You don't need eval exec {stuff…}; plain old exec stuff… is precisely equivalent, shorter to write and a bit easier to get correct.