On 8/1/05, Guy Harris <gharris@xxxxxxxxx> wrote:
[read from a process]
> It can already do the latter, but you have to manually create a FIFO
> file and run the other process with its standard output redirected to
> the file; the former is a convenience feature.
Yes, that is correct. But it is a major convenience: you can stop and
restart the capture, without having to restart the process manually,
because that would be done by Ethereal.
> (BTW, with this feature, is the "read from a FIFO" feature still useful?)
Maybe not so much from a user perspective, but on the program side
exactly that code would be used to read from the pipe to the child
process.
[Checkbox vs magic character]
> Another question, though, is which of those is better from a UI
> perspective. "|" would probably be very obvious to those experienced
> with UN*X at the command line
Yes, I like the idea, but you could also call it rather obscure :-).
There may be a security aspect because not everybody may know that
Ethereal can spawn a process, and that '|' triggers it. Then again,
anyone using Ethereal without knowing how is living dangerously
anyway.
> Buffering is an issue on the send side, so I'm not sure there's any way
> to solve it in Ethereal.
Correct.
> It could be solved *for the case where
> Tethereal is the only program in the pipeline* by adding a flag to
> Tethereal to cause it to "fflush()" the standard output for each packet
> or each batch of packets - the latter requires a change to the main loop
> to use pcap_dispatch() rather than pcap_loop(), so that batch boundaries
> can be seen. A similar option could be added to tcpdump.
I will test that.
> Netcat appears to have no option to control *its* buffering.
That may be because it does not buffer... but I know that a pipe to
ssh buffers usually, unless it goes through a vt.
Thomas