Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <402FF7F4.4090407@tlinx.org> Date: Sun, 15 Feb 2004 14:51:32 -0800 From: linda w User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: only use "/" in values, not names..?] References: <402BC0EE DOT 9070203 AT tlinx DOT org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Igor Pechtchanski wrote: >On Thu, 12 Feb 2004, linda w wrote: > > >>[snip] >>Speaking of compatibility -- there is only 1 application I know of that >>uses "/" in keynames -- Cygwin. Since it's already been noted that this >>makes it very awkward to access these keys in /proc, perhaps cygwin >>could op for better windows compatibility and go with the unofficial >>custom of not using "/" in keynames? Many or most examples I've seen of >>manipulating the registry show the use of some "change separator" >>facility and then use "/" as the example separator in code examples -- >>as "/" is already the separator in other parts of the OS and "\" is a >>pain to use since most modern languages use it for literalizing the next >>character >> >>What do you think? Are these fixable/changable? >> >>Thanks, >>-linda >> >> > > >Technically, Cygwin doesn't use "/" in keynames -- it uses it in value >names. > > > === Yeah yeah yeah...and I probably don't cross all my t's either! :-) >I believe that backward compatibility will preclude any attempts to change >the mount key names... Especially with the plans to move the mount >information out of the registry altogether, the extra effort to change the >key names now is probably not justified. > > ---- ? If it's moved out of the registry, that's fine, but if it isn't, I'd have to ask how many apps rely on this functionality and whether or not it really would break anything. Certainly moving it out of the registry entirely would have no less impact on "backward compatibility"...ahem! Sometimes I get the idea that you are are onery/cantankerous just to be so, not always for reasons you strongly believe in...as though you like to play "devil's advocate", so to speak, just because! :-) >I don't see that as much of a problem, though. Most command-line registry >manipulating tools (including Cygwin's regtool) provide a way to change >the key/value separator. API calls don't care one way or another, as they >walk through keys as explicit strings, and rarely do parsing. > >The only mechanism I can think of that is adversely affected by this >convention is /proc/registry, because of its attempt to map the registry >onto a filesystem. > --- Attempt? It seems like a pretty darn good idea/attempt. What is the registry but a hierarchical, typed, filesystem? It even needs to be "defragged" like a primitive filesystem. Often, I wish users could supply their own registry manipulation routines that do things like keep key creation and access times, what user or program created the key, etc., so later on it would be easier to delete old cruft. But specifically, the power of unix, traditionally, was the orthongonality of the various command line tools and the ability to pipe output from one program into another. Wouldn't it be rather 'cool'/nice to be able to manipulate and edit the registry using the same tools you can use on files. Never have entirely figured out why, but accessing keys in the registry seems so dang slow and the only tools to mess with the registry are cumbersome and error-prone and designed to be dangerous and obscure to incline people not to edit it directly. The concept of an editor, in this day and age not having an "Undo" feature. Not having drag and drop -- but if it was a file system, the you could use explorer to drag/drop it and have automatic undo functionality. MS likes to keep users ignorant and uninformed so they can play fast and loose with bad algorithms and code, hinder reverse engineering and create obstacles to using mixed-OS environments. > Because the registry doesn't have the same set of >invalid characters in names as the underlying filesystem, this mapping >sometimes fails, as in the case of mounts values. It might be possible to >change the /proc/registry implementation to translate "/"s in key and >value names to valid character combinations (e.g., URL encoding). PTC. > Igor > > True, but it also would also seem prudent not to be the only known (to me, at least) application to use a specific feature -- I could easily see MS restricting "/" from key/value names in a future OS release, possibly, even, to support their own Unix compatibility efforts. As for the registry concept, in general, I don't think it would be the worst idea to implement on Unix/Linux systems -- like /etc/sysconfig+/proc+multiple ..rc files. Rather than having each app use it's own method of storing config values, and many apps using 100 bytes out of a 4k allocation unit, it might not be so bad to have a "registry" file system type that would allow storing of small config values in many small spread-out randomly named and placed config files. If you had a per-system, and a per-user file, it would make saving the config state of a machine or a user's preferences trivial to copy to a new machine, potentially. Linda -- In the marketplace of "Real goods", capitalism is limited by safety regulations, consumer protection laws, and product liability. In the computer industry, what protects the consumer? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/