From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 23 17:10:40 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57AC816A423; Thu, 23 Feb 2006 17:10:40 +0000 (GMT) (envelope-from gcorcoran@rcn.com) Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAC9943D46; Thu, 23 Feb 2006 17:10:39 +0000 (GMT) (envelope-from gcorcoran@rcn.com) Received: from 207-172-241-254.c3-0.tlg-ubr1.atw-tlg.pa.cable.rcn.com (HELO [10.56.78.130]) ([207.172.241.254]) by smtp02.mrf.mail.rcn.net with ESMTP; 23 Feb 2006 12:10:38 -0500 X-IronPort-AV: i="4.02,141,1139202000"; d="scan'208"; a="208114817:sNHT3181003544" Message-ID: <43FDED8A.90208@rcn.com> Date: Thu, 23 Feb 2006 12:14:50 -0500 From: Gary Corcoran User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: John Baldwin References: <200602221550.17842.nvass@teledomenet.gr> <20060223050659.GA89118@svzserv.kemerovo.su> <200602230956.47263.nvass@teledomenet.gr> <200602231133.35747.jhb@freebsd.org> In-Reply-To: <200602231133.35747.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Eugene Grosbein , Nikos Vassiliadis Subject: Re: (feature change request) remove link-layer generated routes from netstat -r X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2006 17:10:40 -0000 John Baldwin wrote: > On Thursday 23 February 2006 02:56, Nikos Vassiliadis wrote: >> On Thursday 23 February 2006 07:06, Eugene Grosbein wrote: >>> On Wed, Feb 22, 2006 at 03:50:17PM +0200, Nikos Vassiliadis wrote: >>>> netstat -r prints link-layer generated routes and many >>>> times the output becomes somehow obscure. For >>>> example: >>>> >>>> root@brad:0:/usr/home/src/FreeBSD-6/src/usr.bin/netstat# netstat >>>> -ranfinet Routing tables >>>> >>>> Internet: >>>> Destination Gateway Flags Refs Use Netif >>>> Expire default 10.1.1.244 UGS 0 31016 >>>> rl0 10.1.1/24 link#1 UC 0 0 rl0 >>>> 10.1.1.181 00:0f:1f:fb:02:f5 UHLW 1 0 rl0 >>>> 10.1.1.182 00:e0:fc:38:d4:40 UHLW 1 0 rl0 >>>> 10.1.1.183 00:e0:fc:65:07:fd UHLW 1 0 rl0 >>>> 10.1.1.244 00:50:fc:fe:74:3b UHLW 2 1 rl0 >>>> 10.1.1.254 00:0c:cf:70:50:06 UHLW 1 0 rl0 >>>> 127.0.0.1 127.0.0.1 UH 0 1117 lo0 >>>> 192.168.1 link#5 UC 0 0 fxp0 >>>> 192.168.1.25 00:05:5d:4d:19:58 UHLW 1 0 fxp0 >>>> 192.168.1.45 00:11:43:b6:a1:55 UHLW 1 0 fxp0 >>>> 192.168.1.71 00:0c:f1:b9:38:50 UHLW 1 1645 fxp0 >>>> 192.168.1.84 00:04:23:af:79:66 UHLW 1 0 fxp0 >>>> 192.168.1.112 00:30:4f:21:3b:8a UHLW 1 0 fxp0 >>>> 192.168.1.196 00:07:e9:40:1f:c5 UHLW 1 0 fxp0 >>>> 192.168.1.199 00:e0:81:21:28:21 UHLW 1 0 fxp0 >>>> 192.168.1.200 00:30:4f:03:88:03 UHLW 1 0 fxp0 >>>> >>>> >>>> when the information I was actually looking for is: >>>> >>>> root@brad:0:/usr/home/src/FreeBSD-6/src/usr.bin/netstat# netstat -rnfinet >>>> Routing tables >>>> >>>> Internet: >>>> Destination Gateway Flags Refs Use Netif >>>> Expire default 10.1.1.244 UGS 0 31016 >>>> rl0 10.1.1/24 link#1 UC 0 0 rl0 >>>> 127.0.0.1 127.0.0.1 UH 0 1117 lo0 >>>> 192.168.1 link#5 UC 0 0 fxp0 >>>> root@brad:0:/usr/home/src/FreeBSD-6/src/usr.bin/netstat# >>>> >>>> >>>> The attachment patch ("cvs diff -u -rHEAD route.c" generated) prints >>>> link-layer generated routes when -a is specified and ignores them >>>> the rest of the time. >>>> >>>> Thoughts? POLA violation? >>> Just use: >>> >>> netstat -rn | awk '$3 !~ /L/ { print }' >> That's exactly the point Eugene, I don't want to find ways to filter it out. >> It happens frequently. I didn't say it's difficult to remove it, I just don't >> want it there all the time. That's why you can use -a to get the old >> behavior. > > Using simple pipelines with awk and sed, etc. is the UN*X way though. Instead > of building all-singing all-dancing programs you build simpler utilities that > you "glue" together to build more complex behavior. Yes, when you want do do something "complicated", which doesn't belong in a single program, that's the way. But IMO that doesn't apply here. I agree with Nikos. He just wants to limit the often-useless (to most users) output which is *already* in the program. Just providing a simple command line option to get back the full output, if ever needed, seems like a good, simple solution, to make things easier for us poor humans to scan. :) Gary