This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Reading /proc/registry/... returns extra char


On Sun, May 30, 2010 at 17:35, 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.

And if the registry were a text file you would be exactly correct in
your expectations, but the registry is a binary file with some text
embedded in it.

>> 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.

Because they are purpose built applications designed to work with the
binary format of the registry. If you want this kind of behavior under
cygwin through the /proc/registry interface you need to write a filter
or utility to provide it. It should not be a modification of cat which
is intended to read the raw data from is input and write it to its
output.

>
> --
> WBR,
> ?Andrey Repin (anrdaemon@freemail.ru) 31.05.2010, <3:29>
>
> Sorry for my terrible english...
>
>
> --
> 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
>
>

--
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]