Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Message-ID: <3C03E5D5.9070405@ece.gatech.edu>
Date: Tue, 27 Nov 2001 14:13:25 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
CC: cygwin-apps AT cygwin DOT com
Subject: Re: [RFP] misc from cygutils
References: <3C032ACF DOT 2040006 AT ece DOT gatech DOT edu> <00f801c17729$209b2ed0$0200a8c0 AT lifelesswks>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Robert Collins wrote:

>>1) can I add misc to the official dist?
> IMO, yes.


That's one.


>>2) can anybody come up with a better name?  This package is intended to
>>be a grab-bag of simple utilities (each executable requires only a
>>single source code file of moderate length).
> 
> Uhmm, not really :[. I don't think it's worth the effort to split the
> tools out, and they dont' fit neatly into any one category...
> 
> BTW, it seems to me that dump == od, and [put|get]clip are somewhat
> redundant.


Except dump is prettier:


   Addr     0 1  2 3  4 5  6 7  8 9  A B  C D  E F 0 2 4 6 8 A C E
--------  ---- ---- ---- ---- ---- ---- ---- ---- ----------------
00000000  4d5a 9000 0300 0000 0400 0000 ffff 0000 MZ..............
00000010  b800 0000 0000 0000 4000 0000 0000 0000 8.......@.......
00000020  0000 0000 0000 0000 0000 0000 0000 0000 ................
00000030  0000 0000 0000 0000 0000 0000 e000 0000 ............`...
00000040  0e1f ba0e 00b4 09cd 21b8 014c cd21 5468 ..:..4.M!8.LM!Th
00000050  6973 2070 726f 6772 616d 2063 616e 6e6f is program canno

Has the buffersize limitation of /dev/clipboard been removed? Since 
'cat' uses a 4k internal buffer, and /dev/clipboard (didn't) support 
state between calls, you couldn't
   cat /dev/clipboard
if the clipboard contained more than 4k of data.
   And, of course, /dev/clipboard was not always writeable...although it 
IS now...

Putclip/getclip allocate storage for the entire contents (of 
stdin(putclip), of /dev/clipboard(getclip)) before calling 
SetClipboardData or GetClipboardData, so they avoid the buffersize 
problem...

 

To be honest, even though I wrote the original read-only /dev/clipboard 
support, I don't use it...I use putclip and getclip. :-)


>>3) Did I make the right decision w.r.t. the IPC tools?  Eventually we'll 
>>have real, built-in IPC and those tools can then be distributed
>>without requiring cygipc...
>>
> IMO, yes. I'm sure there will be bug reports, but hey :}.


Good thing you agree -- since I added these at your request. :-)

--chuck