From owner-freebsd-current Fri Jul 25 08:37:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA08659 for current-outgoing; Fri, 25 Jul 1997 08:37:42 -0700 (PDT) Received: from ns.tar.com (ns.tar.com [204.95.187.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA08653 for ; Fri, 25 Jul 1997 08:37:37 -0700 (PDT) Received: from ppro.tar.com (ppro.tar.com [204.95.187.9]) by ns.tar.com (8.8.6/8.8.5) with SMTP id KAA28194 for ; Fri, 25 Jul 1997 10:37:30 -0500 (CDT) Message-Id: <199707251537.KAA28194@ns.tar.com> From: "Richard Seaman, Jr." To: "freebsd-current@freebsd.org" Date: Fri, 25 Jul 97 10:37:27 -0500 Reply-To: "Richard Seaman, Jr." Priority: Normal X-Mailer: PMMail 1.92 For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Whats happened to ping? Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk It seems that there have recently been changes to the sematics of "ping -c N". Unless I'm mistaken, the old behavior was that "ping -c N" meant try to send N packets. Now it means keep trying until N packets are actually sent. The practical effect of this is that "ping -c N" might loop endlessly, if, for example, the network is down and the sendto fails. An actual example: # ping -c 1 -n -q 204.95.160.35 PING 204.95.160.35 (204.95.160.35): 56 data bytes ping: sendto: Network is down ping: sendto: Network is down ping: sendto: Network is down ping: sendto: Network is down ping: sendto: Network is down ping: sendto: Network is down ping: sendto: Network is down ping: sendto: Network is down ping: sendto: Network is down ping: sendto: Network is down ping: sendto: Network is down ping: sendto: Network is down ping: sendto: Network is down ping: sendto: Network is down ping: sendto: Network is down ping: sendto: Network is down ping: sendto: Network is down ping: sendto: Network is down ^C --- 204.95.160.35 ping statistics --- 0 packets transmitted, 0 packets received, The problem with this is that if you put "ping -c N" in a script, expecting it to return at some point, you can now effectively have your script hang. Which, of course, is what happened to me. While I'm sure there are good reasons for the change, I wonder: a) If it wouldn't be a good idea to leave the "-c" option with the old meaning, and have a new option for the new behaviour b) If you don't restore the old meaning, a lot of people who depend on ping to return when using the "-c" option will get burned when they upgrade to current. Now, if I'm the only one affected, I can certainly work around this new behaviour. But, I wonder if there aren't others in the same boat.