delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2010/05/30/19:51:13

X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Sun, 30 May 2010 19:51:00 -0400
From: Christopher Faylor <cgf-use-the-mailinglist-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Reading /proc/registry/... returns extra char
Message-ID: <20100530235100.GD21673@ednor.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20100513181249 DOT GE13784 AT cupro DOT opengvs DOT com> <2BF01EB27B56CC478AD6E5A0A28931F2F01D44 AT A1DAL1SWPES19MB DOT ams DOT acs-inc DOT net> <20100526114733 DOT GG10652 AT calimero DOT vinschen DOT de> <1254830174 DOT 20100526174227 AT mtu-net DOT ru> <20100526143428 DOT GN10652 AT calimero DOT vinschen DOT de> <326990670 DOT 20100530001515 AT mtu-net DOT ru> <20100530055757 DOT GA3251 AT trixie DOT casa DOT cgf DOT cx> <1656998784 DOT 20100531033519 AT mtu-net DOT ru>
MIME-Version: 1.0
In-Reply-To: <1656998784.20100531033519@mtu-net.ru>
User-Agent: Mutt/1.5.20 (2009-06-14)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Mon, May 31, 2010 at 03:35:19AM +0400, Andrey Repin wrote:
>Greetings, Christopher Faylor!
>>>>> >> > $ cat >a.dat
>>>>> >> > /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Syst
>>>>> >> > emBootDevice
>>>>> 
>>>>> > This trailing NUL character was always there, already with Cygwin 1.5.
>>>>> > It's part of the file content.  If strings are stored with a trailing
>>>>> > NUL in a file, you don't want Cygwin to remove it for you, right?
>>>>> 
>>>>> Wrong. The training NULL is a string value terminator for REG_SZ variables,
>>>>> also a string separator for REG_MULTI_SZ ones. (Which ends with a spare NULL)
>>>>> It must not be exposed to the user.
>>>
>>>> I disagree.  When you're using tools like regtool, you're right.  But
>>>> when accessing the registry as *files* via the virtual /proc filesystem,
>>>> you want the file content.
>>>
>>>Yep. And I certainly not expect the NULL in text files. You know, not every
>>>console program is binary-safe when working with STDIO? Not even cygwin, as we
>>>can see in this thread.
>>>
>>>> And the file contains the trailing NUL in REG_SZ and REG_EXPAND_SZ values,
>>>> and multiple NULs in REG_MULTI_SZ values.
>>>
>>>That's right and true, when you're working with interface directly, but... all
>>>the programs I've used in the past, and all the interfaces, they do not expose
>>>trailing NULL to the client application.
>>>In this case, /proc/registry is an interface, but cat is the application.
>
>> NAME
>>        cat - concatenate files and print on the standard output
>
>> I don't see anything in cat's description which claims it should know
>> that some files are special and should be handled differently.
>
>I didn't said about cat, but rather about file it reading from.
>
>>>> What do you suppose Cygwin should do with the NULs in REG_MULTI_SZ values?
>>>> Just remove them?
>>>
>>>Convert them to appropriate EOL sequences. And back to NULL's on write. As per
>>>definition of a text as "multiple strings".
>>>You don't need to argue over it, just document it properly :)
>
>> Converting a NUL to a EOL would be very strange behavior.
>
>Strange? I don't think so. I expect text data from text file. Not binary
>stream.
>
>> I don't think you really know what you're asking for.
>
>I know. Look at windows own regedit and Registry Browser FAR plugin as two
>examples.
>They do such two-way conversion transparently for user.

Ok.  I'm done trying to educate.

We're not going to be changing Cygwin unless we find that there is a bug
in its representation of the data in /proc/registry.  If the data is
being exactly represented as it is retrieved from the registry API, it
is not a bug.

Even if there is a bug, we are not going to be translating NUL to EOL.
I'm fairly confident that Corinna will back me up on that.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019