Re: [Fwd: Bug: Perl:IsWinNT undefined & RFE, only use "/" in reg values, not names..?]

Re: [Fwd: Bug: Perl:IsWinNT undefined & RFE, only use "/" in reg values, not names..?]

[Brian.Kelly]

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

[linda w]

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



Brian.Kelly@Empireblue.com 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..?]

[Yitzchak Scott-Thoennes]

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

[Christopher Faylor]

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

[linda w]

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 in
proportional font, it isn't automatically easy to switch
to Courier and reformat the lines -- it doesn't have
basic features that vim has :-(.

The bottom line is that perl on cygwin is also a perl running
on top of NT.  It should merge functionality of both.  I
see no logical technical reason why it shouldn't return
"WinNT" as defined or not based on the underlying OS.  I don't
want to use ASP perl -- they went off in another direction
from standard perl with their own package manager and they
adopted the bill gates "let's use '\'" mentality that seemed
to be born out of a desire to be different than unix --
something that proved the retardedness of that mentality, since
"\" is something as a literlizing character in all of the
common languages these days making it a rather dumb choice for
a FS component separator.  It used to work -- builtin to the
OS, I don't know why they don't move towards "/" as a standard -- it 
would help unify source bases, but Gates doesn't want that -- he wants 
"lockin" program written for NT only working on
NT.  He desires incompatibility -- like any good capitalist desiring to 
control their customers.  Plblblbl.

I happy you find a source of regular, "new" problems
entertaining.  Unlike you might be doing, though if the
circumstances were reversed, I'm not actin.  I really am the way
I seem.  My brain doesn't work the way most people's do due to
some aspects of Attention Regulation Deficit Disorder ARDD. 
I.e. My attention goes off in different directions because I
see different details than the majority see.  Sometimes that
means I'm seeing with a microscope where others are looking
at it through normal glasses while at other times I'm looking
with a telescope or wide angle lens.  I quite literally see
things differently from many others -- sometimes seeing things
that others don't see, other times missing things that others
do see.  But just because I see differently doesn't mean it's
"wrong".  It's just different.

Linda

 

Christopher Faylor wrote:

>On Thu, Feb 19, 2004 at 11:27:29AM -0800, linda w wrote:
>
>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.
>  
>

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

[Christopher Faylor]

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 aaaspam@sourceware.org
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..?]

[Yitzchak Scott-Thoennes]

On Sat, Feb 28, 2004 at 10:29:01AM -0800, linda w <cygwin@tlinx.org> 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:

[Gerrit P. Haase]

Hallo linda,

> Is that something real difficult or impossible to do?

> (I don't know, never having built perl in the first place.)

Try to figure;)

Gerrit
-- 
=^..^=



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

[Brian.Kelly]

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

[Fwd: Bug: Perl:IsWinNT undefined & RFE, only use "/" in reg values, not names..?]

[linda w]

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/

Re: [Fwd: Bug: Perl:IsWinNT undefined & RFE, only use "/" in reg values, not names..?]

[Igor Pechtchanski]

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

<PEDANTIC>
Technically, Cygwin doesn't use "/" in keynames -- it uses it in value
names.
</PEDANTIC>

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/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,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..?]

[Christopher Faylor]

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

[Igor Pechtchanski]

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/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,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..?]

[Rafael Kitover]

Please try installing perl-libwin32 package, and set:

export PERL5OPT="-MWin32"

in your environment.

HTH

-- 
Rafael

>-----Original Message-----
>From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf Of
>linda w
>Sent: Thursday, February 12, 2004 10:08 AM
>To: cygwin@cygwin.com
>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..?]

[linda w]

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

[linda w]

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(0xC00000) != 0x1110000
      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..?]

[Yitzchak Scott-Thoennes]

On Thu, Feb 19, 2004 at 01:46:05AM -0800, linda w <cygwin@tlinx.org> 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..?]

[Yitzchak Scott-Thoennes]

On Thu, Feb 19, 2004 at 07:48:48AM -0800, Yitzchak Scott-Thoennes <sthoenna@efn.org> wrote:
> On Thu, Feb 19, 2004 at 01:46:05AM -0800, linda w <cygwin@tlinx.org> 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/