From owner-freebsd-questions@FreeBSD.ORG Sat Jun 6 12:05:55 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DEF31065840 for ; Sat, 6 Jun 2009 12:05:55 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [IPv6:2001:4070:101:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 384138FC24 for ; Sat, 6 Jun 2009 12:05:51 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (localhost [IPv6:::1]) by wojtek.tensor.gdynia.pl (8.14.3/8.14.3) with ESMTP id n56C5dhU091261; Sat, 6 Jun 2009 14:05:39 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.3/8.14.3/Submit) with ESMTP id n56C5dWR091258; Sat, 6 Jun 2009 14:05:39 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sat, 6 Jun 2009 14:05:39 +0200 (CEST) From: Wojciech Puchar To: Ruben de Groot In-Reply-To: <20090606101422.GB10672@ei.bzerk.org> Message-ID: References: <200906050924.23167.kirk@strauser.com> <200906051208.43135.kirk@strauser.com> <4A29EBB7.9090100@strauser.com> <20090606094648.GA10672@ei.bzerk.org> <20090606101422.GB10672@ei.bzerk.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-questions@freebsd.org, utisoft@gmail.com Subject: Re: Date representation as YY/DDD or YYYY/DDD X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2009 12:06:12 -0000 > rsync isn't bloated and it's well written IMO. It still does only one job, and > it does it well. As you say, most common tasks can still be done with only > short options. This would change if some developer decided to add other, > unrelated functionality. But that's harder if you want to maintain short options > for the common tasks. > Having only long options would place no such restrictions on bloating. > what program you mean about having only long options?