On Wed, Mar 20, 2013 at 12:43:37AM +, Creamy wrote:
On Tue, Mar 19, 2013 at 06:34:31PM -0600, Theo de Raadt wrote:
Using netcat to reliably get data is never going to be appropriate
for a production system, IMHO.
Wow. You sure do set the bar low. Probably a lot of people are
Whatever behavior you settle on for netcat, it will break somebody's
script somewhere. That is the point I was trying to make.
And that right there is your misunderstanding.
Currently, it not possible to write a script with nc that works reliably.
Every script is already broken now.
On Wed, Mar 20, 2013 at 09:21:10AM +0100, Otto Moerbeek wrote:
On Wed, Mar 20, 2013 at 12:43:37AM +, Creamy wrote:
On Tue, Mar 19, 2013 at 06:34:31PM -0600, Theo de Raadt wrote:
Using netcat to reliably get data is never going to be appropriate
for a production system, IMHO.
wfd is stdin, so doing a shutdown on it will mostly be a noop, right?
Of course you're right. I was so focused on finding the bug I didn't
look above what the fd is :-(
Are you okay with removing this particular shutdown(2) line?
--
Martin Pelikan
On Tue, Mar 19, 2013 at 04:00:46PM +0100, Martin Pelikan wrote:
wfd is stdin, so doing a shutdown on it will mostly be a noop, right?
Of course you're right. I was so focused on finding the bug I didn't
look above what the fd is :-(
Are you okay with removing this particular shutdown(2)
On 2013/03/19 18:26, Otto Moerbeek wrote:
On Tue, Mar 19, 2013 at 04:00:46PM +0100, Martin Pelikan wrote:
wfd is stdin, so doing a shutdown on it will mostly be a noop, right?
Of course you're right. I was so focused on finding the bug I didn't
look above what the fd is :-(
Are
On 2013/03/19 18:26, Otto Moerbeek wrote:
On Tue, Mar 19, 2013 at 04:00:46PM +0100, Martin Pelikan wrote:
wfd is stdin, so doing a shutdown on it will mostly be a noop, right?
Of course you're right. I was so focused on finding the bug I didn't
look above what the fd is :-(
Are
On Tue, Mar 19, 2013 at 17:39, Stuart Henderson wrote:
On 2013/03/19 18:26, Otto Moerbeek wrote:
On Tue, Mar 19, 2013 at 04:00:46PM +0100, Martin Pelikan wrote:
wfd is stdin, so doing a shutdown on it will mostly be a noop, right?
Of course you're right. I was so focused on finding the
On Tue, Mar 19, 2013 at 07:48:41PM +0100, Otto Moerbeek wrote:
On Tue, Mar 19, 2013 at 02:35:49PM -0400, Ted Unangst wrote:
On Tue, Mar 19, 2013 at 17:39, Stuart Henderson wrote:
On 2013/03/19 18:26, Otto Moerbeek wrote:
On Tue, Mar 19, 2013 at 04:00:46PM +0100, Martin Pelikan wrote:
Yes, but it would even be better if there would be an option to get
the shutdown on EOF behaviour back.
Some servers wait until they see the shutdown from the client to finish
their work.
woah. Can somebody explain, using very small words, exactly what the
problem is?
Once upon a
On 2013/03/19 14:35, Ted Unangst wrote:
On Tue, Mar 19, 2013 at 17:39, Stuart Henderson wrote:
On 2013/03/19 18:26, Otto Moerbeek wrote:
On Tue, Mar 19, 2013 at 04:00:46PM +0100, Martin Pelikan wrote:
wfd is stdin, so doing a shutdown on it will mostly be a noop, right?
Of course
OK, thanks, I think I get it. Let me summarize:
nc currently calls shutdown() when it gets EOF on input. This is the
right thing to do, because that's how well written network clients
indicate end of input. Some broken servers, however, treat shutdown as
a disconnect and abort the connection.
nc
On Tue, Mar 19, 2013 at 20:24, Otto Moerbeek wrote:
Now that I better understand the problem, something like the -q
[delay] option seems like the better solution. Even when talking to a
broken server, we don't necessarily want nc hanging around forever,
and maybe we don't know if the server
On Tue, Mar 19, 2013 at 08:12:15PM +0100, Martin Pelikan wrote:
Yes, but it would even be better if there would be an option to get
the shutdown on EOF behaviour back.
Some servers wait until they see the shutdown from the client to finish
their work.
woah. Can somebody
Otto Moerbeek o...@drijf.net writes:
On Tue, Mar 19, 2013 at 03:16:50PM -0400, Ted Unangst wrote:
OK, thanks, I think I get it. Let me summarize:
nc currently calls shutdown() when it gets EOF on input. This is the
right thing to do, because that's how well written network clients
If we cared more about compat with past openbsd releases, then it
would be -q 0, but if I'm not mistaken, we're leaning towards switching
behavior to be compatible with gnu netcat by default.
Actually, OpenBSD nc is the incompatible one.
hobbit nc did not do shutdown.
gnu nc does not do
On Tue, Mar 19, 2013 at 08:43:55PM +0100, J??r??mie Courr??ges-Anglas wrote:
Otto Moerbeek o...@drijf.net writes:
On Tue, Mar 19, 2013 at 03:16:50PM -0400, Ted Unangst wrote:
OK, thanks, I think I get it. Let me summarize:
nc currently calls shutdown() when it gets EOF on input.
It would be rather weird to have OpenBSD change the default behavior of
its netcat version and then see the GNU folks doing the opposite change
because they prefer it and don't see a need to maintain compatibility
(which is what the GNU project has done for lots of software).
The
Theo de Raadt dera...@cvs.openbsd.org writes:
If we cared more about compat with past openbsd releases, then it
would be -q 0, but if I'm not mistaken, we're leaning towards switching
behavior to be compatible with gnu netcat by default.
Actually, OpenBSD nc is the incompatible one.
Just
Using netcat to reliably get data is never going to be appropriate
for a production system, IMHO.
Wow. You sure do set the bar low. Probably a lot of people are glad
that I don't accept that kind of balony.
Look at it this way. Truncated output from some query is the worst
case -- it is a mysterious sometimes you get scewed behaviour.
By default, I want to get the maximum.
It all depends on the protocol / applications used, IMHO. What about
servers that expect the client to close their
On Tue, Mar 19, 2013 at 06:34:31PM -0600, Theo de Raadt wrote:
Using netcat to reliably get data is never going to be appropriate
for a production system, IMHO.
Wow. You sure do set the bar low. Probably a lot of people are glad
that I don't accept that kind of balony.
Then make the
(trimming the CC list...)
Creamy cre...@nocrater.com writes:
On Tue, Mar 19, 2013 at 06:34:31PM -0600, Theo de Raadt wrote:
Using netcat to reliably get data is never going to be appropriate
for a production system, IMHO.
Wow. You sure do set the bar low. Probably a lot of people are
(trimming the CC list...)
Don't worry, I'm sure 99% of subscribers send my mail to /dev/null anyway.
Using netcat to reliably get data is never going to be appropriate
for a production system, IMHO.
Wow. You sure do set the bar low. Probably a lot of people are glad
that I don't
Whatever behavior you settle on for netcat, it will break somebody's
script somewhere. That is the point I was trying to make.
And that right there is your misunderstanding.
Currently, it not possible to write a script with nc that works reliably.
Every script is already broken now.
The rest
Hi!
Theo pointed out an issue with nc(1), as mentioned in
https://groups.google.com/forum/?hl=enfromgroups=#!topic/muc.lists.freebsd.bugs/0yNFZVHClcI
and
https://bugs.launchpad.net/ubuntu/+source/netcat-openbsd/+bug/544935
that was causing people headaches.
For me, this diff (which seems
On Mon, Mar 18, 2013 at 03:14:59PM +0100, Martin Pelikan wrote:
Hi!
Theo pointed out an issue with nc(1), as mentioned in
https://groups.google.com/forum/?hl=enfromgroups=#!topic/muc.lists.freebsd.bugs/0yNFZVHClcI
and
27 matches
Mail list logo
