Re: [Fwd: Bug: Perl:IsWinNT undefined & RFE, only use "/" in reg values, not names..?]
On Sat, Feb 28, 2004 at 10:29:01AM -0800, linda w <[EMAIL PROTECTED]> wrote: > I still haven't figured out how to get Tk to build from cpan > w/o the "x" param. It builds when I drop into the build > dir "view Tk" from in cpan, and build it w/the "x", but > to install, I finally just ignore the makefile which seems > to have the target: > install: >all pure_install pure_doc_install. > > The "all" goes off and starts building things again -- if > I just do a make install, it goes off and starts compiling > things even though, supposedly it's already been built. Some kind of clock problem confusing make? Or is this just the normal stuff you see with nested makefiles, where the top-level makefile has to invoke the others to see if they are up-to-date? (Lots of entering directory/leaving directory messages.) The actual make commands you are using and their output would be helpful. Last time you asked, I think you got the answer: Tk-804* builds successfully only with the x option, Tk800* will build without. I just tried most recent versions of both and also see that (though even Tk800.025 gets a number of test failures, so you would need to use the force command from the cpan shell). I see brief mention of this on the pTK list: http://lists.perl.org/showlist.cgi?name=ptk anwered by Nick Ing-Simmons (the perl/Tk maintainer) with an request for someone more familiar with cygwin to help out: http://www.xray.mpe.mpg.de/mailing-lists/ptk/2003-12/msg00296.html But when I try Tk-804.025-beta15, I get a lot farther than that before it fails: gcc -c -I.. -I../pTk/mTk/xlib -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -DUSEIMPORTLIB -O2 -DVERSION=\"804.025\" -DXS_VERSION=\"804.025\" "-I/usr/lib/perl5/5.8.2/cygwin-thread-multi-64int/CORE" -D__WIN32__ -D_WIN32 -Wall -Wno-implicit-int -Wno-comment -Wno-unused -D__USE_FIXED_PROTOTYPES__ Xlib.c Xlib.xs:13: error: syntax error before '*' token Xlib.xs:13: warning: data definition has no type or storage class Xlib.xs: In function `boot_Tk__Xlib': Xlib.xs:378: warning: cast to pointer from integer of different size Xlib.xs:378: warning: cast to pointer from integer of different size Xlib.xs:378: warning: cast to pointer from integer of different size Xlib.xs:378: warning: cast to pointer from integer of different size Xlib.xs:378: warning: cast to pointer from integer of different size Xlib.xs:378: warning: cast to pointer from integer of different size Xlib.xs:378: warning: cast to pointer from integer of different size Xlib.xs:378: warning: cast to pointer from integer of different size Xlib.xs:378: warning: cast to pointer from integer of different size Xlib.xs:378: error: `XlibVtab' undeclared (first use in this function) Xlib.xs:378: error: (Each undeclared identifier is reported only once Xlib.xs:378: error: for each function it appears in.) Xlib.xs:378: error: syntax error before ')' token make[1]: *** [Xlib.o] Error 1 make[1]: Leaving directory `/home/sthoenna/dl/tmp/Tk-804.025_beta15/Xlib' make: *** [subdirs] Error 2 > What is lost by allowing perl to make libwin32 calls, in > this case, is not violating the principle of "least surprise". Again, the perl-libwin32 package containing the Win32 calls first became available via setup *after* the most recent perl package. I expect perl will automatically load the Win32:: stuff (at least to the extent the native win32 port does) with the next release or two. In the meantime, you will either need to patch perl to do this yourself or set PERL5OPT=-MWin32CORE, as I believe was previously mentioned. -- 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/
Re: [Fwd: Bug: Perl:IsWinNT undefined & RFE, only use "/" in reg values, not names..?]
On Sat, Feb 28, 2004 at 10:29:01AM -0800, linda w wrote: >[long, rambling off-topic email deleted] Ok. As mentioned here: http://cygwin.com/ml/cygwin/2003-12/msg00186.html you're now blocked from this mailing list. -- Please use the resources at cygwin.com rather than sending personal email. Special for spam email harvesters: send email to [EMAIL PROTECTED] and be permanently blocked from mailing lists at sources.redhat.com -- 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/
Re: [Fwd: Bug: Perl:IsWinNT undefined & RFE, only use "/" in reg values, not names..?]
The same problem keeps coming up in new and different ways that keep running into. My background also has user interface design, usability in it and I keep running into problems as I try to use things from the perspective of a user like my mom -- or just a windows users not famililar with linux -- trying to use open source tools on the windows platform. I keep running into usability problems because of the apparent need for any user to be a full fledged developer to debug and user so many aspects of the cygwin toolset. Go read "http://www.catb.org/~esr/writings/cups-horror.html";. It's an article by Eric Raymon on why software projects fail to deliver -- all the time maintaining their air of technical superiority. From as near as I can tell, so many programmers, especially young ones, look in contempt and people who don't share their knowledge. When people try to use tools and envionrments in a way that is natural to them and it tails, instead of listening, you have those who have threatened your list membership over things they consider to be off-topic because they are living stories about fighting for what is 'right' in SW and losing to the almight $$. My last manager and the last open source group I worked with was far more concerned about keeping things complex than reworking the system to do it right and make it simple. If it's kept complex, there is job security. But that's not great for average user who finds they have to be a developer expert to use so many pieces of software -- so much so, that even switching from 1 interface like WORD to an open source equiv is something met with alot of food dragging, fear and protests. So rather than developing a new and yet another incompatible toolset, I want something that allows union and merger -- transparancy and easy. The original Cygwin charter -- to allow use of free SW tools transparently in Cyg or Win envinronments. Instead all I get is resistance and excuses that ultimately boil down to ego gratification of creating a new interface that everyone has to learn that doesn't help a wide range audidience but only a narrow set of developers. Ego's about who controls what always seem to get in the way of doing "the right thing"...it always seems to boil down to another example of the "dominator" model -- one side wins and there has to be a loser, vs. a cooperative model where everyone wins. It was a big sticking point between me and my last boss, who called me "Little Linda, bubble of good" in "Casey's evil plan for world domination". I was constantly considered naive for wanting plans where boths sides one -- and in joking, all humor aside, I'd often be asked, where's the fun in doing it if there isn't a loser to gloat over? Where's the fun of doing things right if you would miss someone like me ignorantly running into different variations of incompatibility on a regular basis and get to see 'how stupid' I am by hoping for change? Open source falls short, greatly, in areas of user-friendlyness, and user interface. What matters is the code and the leading edge programming -- the UI is "fluff" and if you (the user) don't like it, go start your own project or branch -- good luck with trying to spend all your time just merging current functionality to keep your branch current. My focus is _usability_. But, obviously, the concept of seeing my problems with non-usability are so amusing that keeping the status quo is useful just because it's fun to watch someone bang their head against another side of the same wall -- everything requires specialized knowledge and requires a new way to learn everything. I still haven't figured out how to get Tk to build from cpan w/o the "x" param. It builds when I drop into the build dir "view Tk" from in cpan, and build it w/the "x", but to install, I finally just ignore the makefile which seems to have the target: install: all pure_install pure_doc_install. The "all" goes off and starts building things again -- if I just do a make install, it goes off and starts compiling things even though, supposedly it's already been built. What is lost by allowing perl to make libwin32 calls, in this case, is not violating the principle of "least surprise". A basic design principle as far back as I remember. I'm not acting "as if" anything. I'm "real", since the problems I come up with are because I try "real things". I don't just sit around and think of ways to run into pre-existing barriers. Your comment is inaccurate, but indicative of your own projections -- If I know myself and know what I bring to a discussion, then things the other person accuses me of that I know I am not bringing to the table, I know projections of what they would do -- since people project onto others their own ideas of how the world works based on how they work in the world. Sorry for the long lines, occasionally -- but Thunderbird likes to default to proportional fonts and has no reformat ability -- so once one has typed in an email
Re: [Fwd: Bug: Perl:IsWinNT undefined & RFE, only use "/" in reg values, not names..?]
> It seems cyg_win_ was designed to add POSIX and unix compatibility > and functionality to the _Win_ environment with the intent of making > things _easier_ (Easy is good -- not everyone can be a master of > every technology). So why not make things easier for perl scripters > as well by starting with a perl that is unix (works with cpan, > handles paths with "//", "/") and win (paths handle "\\", ":" and > "" and define WinNT) compatible? I can't bring up the cygwin site right now for some reason, so I'll go off memory. I do succinctly remember cgf being asked about cygwin "making things easier" and he very clearly stated THAT WAS NOT THE GOAL. The goal was to make a POSIX COMPATIBLE layer for Microsoft Windows Platforms. PERIOD. There is no other goal, focus or mission. At least *that* is what I took from his statements. This discussion is in the archives somewhere. I don't think anyone would argue that "making things easier" is a good thing to strive for - but that in fact is a much *bigger* and *loftier* goal than the one defined for the cygwin project. Cygwin is still a *relatively* new animal and there isn't a big enough cross-over user base wanting hybrid capability to stimulate many developers into working more towards this goal. The fact that libwin32 got ported is proof that such desire *does* exist and that things are *beginning* to move in this direction - but one must have patience!!! Furthermore, the changes needed were introduced into the modules themselves, NOT the cygwin1.dll. (At least, that's my possibly errant understanding). cgf and crew have enough challenge right now just getting the *POSIX* thing right. When that task is someday finished - maybe they too will be inspired to *up the ante*. And I for one completely understand their lack of desire for doing it *now*. Brian Kelly "WellChoice, Inc." made the following annotations on 02/19/2004 03:41:10 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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/
Re: [Fwd: Bug: Perl:IsWinNT undefined & RFE, only use "/" in reg values, not names..?]
On Thu, Feb 19, 2004 at 11:27:29AM -0800, linda w wrote: >What features does one get with a unix perl over a perl built where >"WinNT" is defined as true or false? Many (most? all?) of the Win32 >calls are available in the Cygwin environment, why not compile the perl >as a mixed breed perl that defines WinNT? > >What is lost by allowing Perl to make libwin32 calls. What is lost is the delightful opportunity of having you bring this up, gripe about it, and act as if it was a new topic on a monthly basis. I doubt that there is anyone in the cygwin mailing list who would want to lose the opportunity of seeing you rehash this subject over and over and over again. cgf -- 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/
Re: [Fwd: Bug: Perl:IsWinNT undefined & RFE, only use "/" in reg values, not names..?]
On Thu, Feb 19, 2004 at 11:27:29AM -0800, linda w wrote: > What features does one get with a unix perl over a perl built where > "WinNT" is > defined as true or false? Many (most? all?) of the Win32 calls are > available > in the Cygwin environment, why not compile the perl as a mixed breed > perl that > defines WinNT? If possible, please shorten your lines. > What is lost by allowing Perl to make libwin32 calls. > > If Cygwin is supposed to enable me to run my utils and scripts from bash or > cnd.exe, then why should perl be different? What do I lose by defining > -MWin32 > in the PERL5OPS?, or put another way, why isn't it on and present all > the time? Because the perl-libwin32 package was released a little over 3 weeks ago. Allow some time, please. On the win32-perl/ActiveState side, the stuff in our package is divided into two places, the perl core, and the libwin32 CPAN distribution. -MWin32CORE will get you what is in the perl core for non-cygwin perl's. The need for that should go away at some point. Code using other Win32:: parts should already have "use Win32". Note that cygwin runs not just on WinNT and derivitaves; you can expect Win32::IsWinNT to return false for Win9x, just as it does with ActiveState (IIRC). > Besides, it seems, that the cpan modules for perl can't be for active state > perl since they have their own package manager -- but are for the > floundering > win32-perl that is mostly eclipsed by active state's perl and cygwin's > perl. As far as I know, they are usable with ActiveState (for XS modules assuming you have the same compilation tools ActiveState uses). That lanman thing seems to be an abberation, in that it isn't set up like a real perl module. > It seems cyg_win_ was designed to add POSIX and unix compatibility and > functionality to the _Win_ environment with the intent of making things > _easier_ (Easy is good -- not everyone can be a master of every technology). > So why not make things easier for perl scripters as well by starting with > a perl that is unix (works with cpan, handles paths with "//", "/") and > win (paths handle "\\", ":" and "" and define WinNT) compatible? > > Is there some fundamental reason why they can't both be present in perl? In making POSIX-like paths work in a drive-letter world, you can't have everything. What is it exactly that you would like that you see as missing? -- 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/
Re: [Fwd: Bug: Perl:IsWinNT undefined & RFE, only use "/" in reg values, not names..?]
What features does one get with a unix perl over a perl built where "WinNT" is defined as true or false? Many (most? all?) of the Win32 calls are available in the Cygwin environment, why not compile the perl as a mixed breed perl that defines WinNT? What is lost by allowing Perl to make libwin32 calls. If Cygwin is supposed to enable me to run my utils and scripts from bash or cnd.exe, then why should perl be different? What do I lose by defining -MWin32 in the PERL5OPS?, or put another way, why isn't it on and present all the time? Besides, it seems, that the cpan modules for perl can't be for active state perl since they have their own package manager -- but are for the floundering win32-perl that is mostly eclipsed by active state's perl and cygwin's perl. I suppose I find it frustrating to find books/examples about win32-perl that don't quite work on active state and don't quite work on cyg_WIN_ (vs. a cygunix product that might infer a variant of unix). It seems cyg_win_ was designed to add POSIX and unix compatibility and functionality to the _Win_ environment with the intent of making things _easier_ (Easy is good -- not everyone can be a master of every technology). So why not make things easier for perl scripters as well by starting with a perl that is unix (works with cpan, handles paths with "//", "/") and win (paths handle "\\", ":" and "" and define WinNT) compatible? Is there some fundamental reason why they can't both be present in perl? I think part of the problem is that Perl is both an "app" (can be view as a unix app to be transferred over), or can be viewed as part of the development environment (as it is a development tool) that also understands it is running in a mixed mode. I'm favoring the latter view, obviously, while some have taken the former view. I'm just thinking it makes cygperl so much more accessible/useful to have it understand it's mixed mode heritage as well. Is that something real difficult or impossible to do? (I don't know, never having built perl in the first place.) Linda [EMAIL PROTECTED] wrote: Seems to me you answered your own question. The perl that's bundled with Cygwin is *NOT* an Active-State-*like* Win32 version of perl. It's really a *unix* built version of perl that -requires- Cygwin to even run on Windoze at all. That being the case, Cygwin perl *thinks* its running on unix - not Win32. Therefore, modules that expect direct, non-POSIX access to the Win32 subsystem are gonna need some help that wouldn't otherwise be necessary with a true Win32 build of Perl. Brian Kelly -- 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/
Re: [Fwd: Bug: Perl:IsWinNT undefined & RFE, only use "/" in reg values, not names..?]
On Thu, Feb 19, 2004 at 07:48:48AM -0800, Yitzchak Scott-Thoennes <[EMAIL PROTECTED]> wrote: > On Thu, Feb 19, 2004 at 01:46:05AM -0800, linda w <[EMAIL PROTECTED]> wrote: > > Tried this...some scripts ran. One that didn't wanted lanman.pm located in > > Win32::lanman. > > > > Queerly enough, doing a "i" /lanman" comes up zip even though it is in > > CPAN at > > /CPAN/sources/authors/id/J/JH/JHELBERG/lanman.1.0.10.0.zip. > > > > How would one normally go about installing lanman.pm without manually > > unpacking > > the zip and putting it someplace (which I'm just randomly guessing > > wouldn't work for > > some other reason -- like the lanman dll not being installed in the > > right place. > > lanman doesn't seem to be packaged like a normal CPAN module; > presumably the author is expecting most people to use ActiveState and > ppm to install it. You should download the zip file and unzip it into > a temporary directory and follow the readme's build instructions to > the extent possible, and it may or may not work. Looks like "may not". The author has completely gone without the normal perl module build facilities (e.g. MakeMaker); even ActiveState users have to manually change path settings, etc. to get the (nmake, MSVC++) makefile to work. -- 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/
Re: [Fwd: Bug: Perl:IsWinNT undefined & RFE, only use "/" in reg values, not names..?]
On Thu, Feb 19, 2004 at 01:46:05AM -0800, linda w <[EMAIL PROTECTED]> wrote: > Tried this...some scripts ran. One that didn't wanted lanman.pm located in > Win32::lanman. > > Queerly enough, doing a "i" /lanman" comes up zip even though it is in > CPAN at > /CPAN/sources/authors/id/J/JH/JHELBERG/lanman.1.0.10.0.zip. > > How would one normally go about installing lanman.pm without manually > unpacking > the zip and putting it someplace (which I'm just randomly guessing > wouldn't work for > some other reason -- like the lanman dll not being installed in the > right place. lanman doesn't seem to be packaged like a normal CPAN module; presumably the author is expecting most people to use ActiveState and ppm to install it. You should download the zip file and unzip it into a temporary directory and follow the readme's build instructions to the extent possible, and it may or may not work. > Definitely the win32 lib is a step in the right direction...but why does > cygwin need > a special version? Not sure what you mean. -- 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/
Re: [Fwd: Bug: Perl:IsWinNT undefined & RFE, only use "/" in reg values, not names..?]
> Do all the win32 libraries have to have a special port to work on cygwin > even though > cygwin was supposed to aid in allowing posix type apps (like perl) to > run under > win either from the bash or cjmd.exe shell? > Definitely the win32 lib is a step in the right direction...but why does > cygwin need a special version? Seems to me you answered your own question. The perl that's bundled with Cygwin is *NOT* an Active-State-*like* Win32 version of perl. It's really a *unix* built version of perl that -requires- Cygwin to even run on Windoze at all. That being the case, Cygwin perl *thinks* its running on unix - not Win32. Therefore, modules that expect direct, non-POSIX access to the Win32 subsystem are gonna need some help that wouldn't otherwise be necessary with a true Win32 build of Perl. Brian Kelly "WellChoice, Inc." made the following annotations on 02/19/2004 09:07:12 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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/
Re: [Fwd: Bug: Perl:IsWinNT undefined & RFE, only use "/" in reg values, not names..?]
Tried this...some scripts ran. One that didn't wanted lanman.pm located in Win32::lanman. Queerly enough, doing a "i" /lanman" comes up zip even though it is in CPAN at /CPAN/sources/authors/id/J/JH/JHELBERG/lanman.1.0.10.0.zip. Obviously I'm still a bit too new for this stuff, get, make and install don't work and say it isn't found. I can see the module if I lookup by author, but doesn't seem to like installing it via pathname or substituting backslashes or colons...even got dumped out of cpan a few times: Scanning cache /share/CPAN/build-win for sizes C:\bin\perl.exe (1892): *** unable to remap C:\lib\perl5\5.8.2\cygwin-thread-mul ti-64int\auto\Cwd\Cwd.dll to same address as parent(0xC0) != 0x111 8 [main] perl 1436 sync_with_child: child 1892(0x6C0) died before initiali zation with status code 0x1 14290 [main] perl 1436 sync_with_child: *** child state child loading dlls How would one normally go about installing lanman.pm without manually unpacking the zip and putting it someplace (which I'm just randomly guessing wouldn't work for some other reason -- like the lanman dll not being installed in the right place. Do all the win32 libraries have to have a special port to work on cygwin even though cygwin was supposed to aid in allowing posix type apps (like perl) to run under win either from the bash or cjmd.exe shell? Definitely the win32 lib is a step in the right direction...but why does cygwin need a special version? Thanks for the help... -linda Rafael Kitover wrote: Please try installing perl-libwin32 package, and set: export PERL5OPT="-MWin32" in your environment. HTH -- 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/
Re: [Fwd: Bug: Perl:IsWinNT undefined & RFE, only use "/" in reg values, not names..?]
Is that a new package? I thought I had installed all the perl related cygwin packages? Could just be my failing eyesite, though as well... I, of course, had tried the old fashion way of downloading the win32 modules from CPAN, and tried installing them which was when I got the "you aren't WinNT or NOT WinNT"...:-/ thanks -linda Rafael Kitover wrote: Please try installing perl-libwin32 package, and set: export PERL5OPT="-MWin32" in your environment. HTH -- 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/
RE: [Fwd: Bug: Perl:IsWinNT undefined & RFE, only use "/" in reg values, not names..?]
Please try installing perl-libwin32 package, and set: export PERL5OPT="-MWin32" in your environment. HTH -- Rafael >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of >linda w >Sent: Thursday, February 12, 2004 10:08 AM >To: [EMAIL PROTECTED] >Subject: [Fwd: Bug: Perl:IsWinNT undefined & RFE, only use "/" in reg values, >not names..?] > >I'm on an NT compatible (Windows XP) release trying to run the reg utils >but I >get an error message that IsWinNT is not defined, so they the reg utils >fail to >install. Presumably IsWinNT is to differentiate between Protected and >DOS-based versions of Windows but presumably wouldn't be defined on OS's >where >Windows compatibility is not possible or desired. [SNIP] -- 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/
Re: [Fwd: Bug: Perl:IsWinNT undefined & RFE, only use "/" in reg values, not names..?]
On Thu, 12 Feb 2004, Christopher Faylor wrote: > On Thu, Feb 12, 2004 at 01:44:24PM -0500, Igor Pechtchanski wrote: > >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. 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. > > I've toyed with the idea of making /proc/registry a managed mount but > since managed mounts don't allow '/' in a filename either, that would > require some additional work on the managed stuff. > > cgf IMO, this is different than a managed mount[*]. Managed mounts provide a transparent encoding of characters that are invalid in the underlying filesystem, which isn't visible at the user level. Since /proc/registry is a virtual filesystem, it doesn't really need this, and neither does the encoding need to be transparent. As long as the user can unambiguously specify the value, whatever method is used should be fine... Igor [*] Of course, since managed mounts use URL encoding under the covers, some of the code can certainly be reused. :-) -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "I have since come to realize that being between your mentor and his route to the bathroom is a major career booster." -- Patrick Naughton -- 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/
Re: [Fwd: Bug: Perl:IsWinNT undefined & RFE, only use "/" in reg values, not names..?]
On Thu, Feb 12, 2004 at 01:44:24PM -0500, Igor Pechtchanski wrote: >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. 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. I've toyed with the idea of making /proc/registry a managed mount but since managed mounts don't allow '/' in a filename either, that would require some additional work on the managed stuff. cgf -- 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/
Re: [Fwd: Bug: Perl:IsWinNT undefined & RFE, only use "/" in reg values, not names..?]
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. 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. 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. 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 -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "I have since come to realize that being between your mentor and his route to the bathroom is a major career booster." -- Patrick Naughton -- 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/
[Fwd: Bug: Perl:IsWinNT undefined & RFE, only use "/" in reg values, not names..?]
I'm on an NT compatible (Windows XP) release trying to run the reg utils but I get an error message that IsWinNT is not defined, so they the reg utils fail to install. Presumably IsWinNT is to differentiate between Protected and DOS-based versions of Windows but presumably wouldn't be defined on OS's where Windows compatibility is not possible or desired. Since the purpose of Cygwin is to allow developers to use both the Microsoft Win32 API and/or the Cygwin API to write utils that can be used from both the bash shell and the standard Windows command shell (http://cygwin.com/faq/faq_1.html, 2nd par.), having Cywin perl returning "Not running on top any version of windows) would seem to be a bug. Am I, perhaps, doing something else wrong and this feature does work for others? If so, I'll have to go bury my head for a while under some lines of code. 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 -- 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/