Re: Problems with older "nc" without "-N" option ... also how to detect "nc" version

2014-08-28 Thread Clint Pachl

Alan McKay wrote, On 08/27/14 09:56:

I'm writing some scripts to clone over the network, and since I have
mostly boxes that do not have the -N option on nc, this is proving to
be an issue.

I have a bunch of dump files - one for each filesystem - that were
created from a live system.  When I want to send them back over the
network to another system, it seems that the sender never really sees
the end of the file.

One the sender I do

nc   < dump.file

On the receiver I do simply

nc -l  | restore -rf -

That send/receive pair will just hang there forever.  But if I add the
-N option to the sender, it works as expected.

However I've also implemented some rudimentary handshaking - when the
recipient is done with the file I do :

echo "OK" | nc  

Note no -N option - and it works great.  The other end is just doing
"nc -l "


hmmm ... that's not what happens between my 5.5 systems. Neither end 
will shutdown when the -N option is omitted (receiver or transmitter).


I wonder why your connection shuts down here without -N?


The difference seems to be the pipe.

So I'm thinking maybe introduce a superfluous dd on the original
sender, perhaps :

dd if=dump.file | nc  

But I try that and get the same results - they will just stay in that
state forever.

Any ideas on how to solve this problem?


I think the best solution is using the nc(1) -w timeout, which you 
seemed to have discovered. I've seen the "timeout solution" recommended 
in the past for this exact situation. I'm not sure there is another way 
to shutdown the connection without the -N option.




Re: Problems with older "nc" without "-N" option ... also how to detect "nc" version

2014-08-27 Thread Alan McKay
On Wed, Aug 27, 2014 at 12:56 PM, Alan McKay  wrote:
> Anyone have any ideas here?

Well I'd been through the nc man page close to a dozen times ... and
just this one last time noticed the -w option for "timeout"

Works a charm!



-- 
"Don't eat anything you've ever seen advertised on TV"
 - Michael Pollan, author of "In Defense of Food"



Problems with older "nc" without "-N" option ... also how to detect "nc" version

2014-08-27 Thread Alan McKay
Hi folks,

I'm writing some scripts to clone over the network, and since I have
mostly boxes that do not have the -N option on nc, this is proving to
be an issue.

I have a bunch of dump files - one for each filesystem - that were
created from a live system.  When I want to send them back over the
network to another system, it seems that the sender never really sees
the end of the file.

One the sender I do

nc   < dump.file

On the receiver I do simply

nc -l  | restore -rf -

That send/receive pair will just hang there forever.  But if I add the
-N option to the sender, it works as expected.

However I've also implemented some rudimentary handshaking - when the
recipient is done with the file I do :

echo "OK" | nc  

Note no -N option - and it works great.  The other end is just doing
"nc -l "

The difference seems to be the pipe.

So I'm thinking maybe introduce a superfluous dd on the original
sender, perhaps :

dd if=dump.file | nc  

But I try that and get the same results - they will just stay in that
state forever.

Any ideas on how to solve this problem?  Is there some way I can tell
dd to do something differently?  Looking at the man page did not turn
up much obvious.

Also, I'd like for my script to use the -N option if it is available,
but I don't see any easy way to detect that.  I can do a "man nc" and
grep for -N, which seems clumsy.   nc does not seem to have a command
line option to get it to tell you what version it is.  I tried just
doing a pseudo-call with -N and checking the return code, but it seems
to always return 1 no matter what I do.  I even went into the source
code to see what was up with that.

Anyone have any ideas here?

The only thing I can think of is to write a little subroutine on the
sender which backgrounds itself and monitors the mounted disk.   When
the disk usage does not change for X seconds, kill the running 'nc'.
It should work buy oh man is that hacky!

thanks,
-Alan

-- 
"Don't eat anything you've ever seen advertised on TV"
 - Michael Pollan, author of "In Defense of Food"