On Thu, Jan 09, 2003 at 02:16:38AM -0500, Christopher Faylor wrote:
I wasn't aware of that but then I haven't been reading perl5-porters for a while
now. I don't know what smokes is but I assume it's a periodic test run of perl
on various platforms.
Yes, it's smoke testing. H Merijn Brand
I've found that it's always easy to look back at a previously made design
decision and question it, especially when one wasn't involved in the
design discussion that weighed the current needs with the benefits and
detriments of possible implementations. Rethinking a design decision
isn't bad of
On Fri, Jan 10, 2003 at 10:30:23AM -0800, Shankar Unni wrote:
linda w (cyg) wrote:
What were the _original_ design goals of Cygwin -- i.e. as sponsored
by RedHat?
Cygwin predates RedHat. See http://cygwin.com/history.html (the
earliest date in the file is Dec 1995). RedHat bought Cygnus
Well surely EVERYONE knows not to take your word, you're just mean after
all. ;)
-Original Message-
From: Christopher Faylor [mailto:[EMAIL PROTECTED]]
Sent: 10 January 2003 19:23
To: [EMAIL PROTECTED]
Subject: Re: Repost, different list...File::Spec, cygwin,
Syntactic vs
--- Christopher Faylor [EMAIL PROTECTED] wrote:
On Fri, Jan 10, 2003 at 10:30:23AM -0800, Shankar Unni wrote:
linda w (cyg) wrote:
What were the _original_ design goals of Cygwin -- i.e. as sponsored
by RedHat?
Cygwin predates RedHat. See http://cygwin.com/history.html (the
earliest
Ah, yes. Teeth gnashing! Those were the good old days! ;-)
Larry
Original Message:
-
From: Rick Rankin [EMAIL PROTECTED]
Date: Fri, 10 Jan 2003 11:44:47 -0800 (PST)
To: [EMAIL PROTECTED]
Subject: Re: Repost, different list...File::Spec, cygwin, Syntactic vs.
Semantic path
Interesting...wonder why they wouldn't just create pseudo devices
in /dev and do the normal unix mount thing? Seems odd to complicate the simple
namespace model needlessly by adding a special syntax.
Even still, just because one wants to have more traditional unix names doesn't
preclude the
Interesting...wonder why they wouldn't just create pseudo devices in /dev and do the
normal unix mount thing? Seems odd to complicate the simple namespace model
needlessly by adding a special syntax.
Even still, just because one wants to have more traditional unix names doesn't
preclude the
One would have to wonder...
On Fri, Jan 10, 2003 at 03:25:17PM -0800, LA Walsh wrote:
Interesting...wonder why they wouldn't just create pseudo devices
in /dev and do the normal unix mount thing? Seems odd to complicate the simple
namespace model needlessly by adding a special syntax.
Even
...why there are two messages with the same body and different
from addresses.
Please fix your configuration problem and stop duplicating your messages.
On Fri, Jan 10, 2003 at 03:27:49PM -0800, linda w (cyg) wrote:
Interesting...wonder why they wouldn't just create pseudo devices in /dev and do
Hello H.Merijn,
H.M Great. I'll continue off-list to get our goals in sync :)
Hmm, why not continue in public (cygwin/perl5-porters lists)?
(Blead-)Perl issues:
What's the stance of cygwin in threading?
CGF We're for it! We have pretty extensive pthreads support.
From: Robert Collins [mailto:[EMAIL PROTECTED]]
There you go again, making relative assertions about good/bad
again. It's common practice to define a $(ROOT)/foobar
underwhich to
build or install a program. It is common to have ROOT=/
when you want
to install it on a live
On Thu, 2003-01-09 at 19:08, LA Walsh wrote:
Ok, did I mention POSIX? Posix != Unix. So what's your point?
Cygwin targets POSIX compatability wherever posible. Any discussion
about paths that ignores the POSIX standards will need to be reviewed
with POSIX in mind. It's easier to do
Ok, did I mention POSIX? Posix != Unix. So what's your point?
I've been on multiple unices [bogus latinization, but unix's
doesn't roll of the tongue nearly so well]: sun, hp, sgi, linux,
xenix, sco, others I don't remember. I don't recall // being
anything other than / on any of
Cygwin targets POSIX compatibility wherever possible. Any
discussion about paths that ignores the POSIX standards will
need to be reviewed with POSIX in mind. It's easier to do
that up front.
---
What were the _original_ design goals of Cygwin -- i.e. as
sponsored by RedHat?
On Jan 09, linda w (cyg) wrote:
Cygwin targets POSIX compatibility wherever possible. Any
discussion about paths that ignores the POSIX standards will
need to be reviewed with POSIX in mind. It's easier to do
that up front.
---
What were the _original_ design goals of Cygwin --
linda w \(cyg\) [EMAIL PROTECTED] wrote:
: What were the _original_ design goals of Cygwin -- i.e. as
:sponsored by RedHat?
I do not think perl5-porters is the best place to be having that
discussion; perhaps it would be better served by a new thread
in the appropriate forum.
Thanks,
On Wed 08 Jan 2003 05:56, Christopher Faylor [EMAIL PROTECTED] wrote:
I'm sorry. I thought the cygwin project -- was to provide a Posix type
platform to [aid, assist, help] in porting *nix/gnu utils to the Win32
environment.
Cygwin's primary purpose is to provide a UNIX environment for
Cygwin's primary purpose is to provide a UNIX environment for
Windows. Although it can be used in other ways, the basic
purpose is not to provide a stepping stone to helping port
programs to native Windows. Things like Win32 path names and
accommodating pure-win32 processes are
Cygwin's primary purpose is to provide a UNIX environment for
Windows. Although it can be used in other ways, the basic
purpose is not to provide a stepping stone to helping port
programs to native Windows. Things like Win32 path names and
accommodating pure-win32 processes are
Sorry for butting in again, but you have a factual error that needs
highlighting.
On Thu, 2003-01-09 at 13:18, linda w (cyg) wrote:
Understanding that double slashes at the
beginning of a path are special is good sense for any
portable program.
---
There you go again, making
I'm sure that everyone in perl5-porters is sick of this discussion
(although I think I remember similar discussions from the days when I
was an occasional contributor) and so I apologize.
Let me make some points and then I'll shut up:
1) I'm the person who currently sets the direction of the
On Wed, Jan 08, 2003 at 03:30:25PM +0100, H.Merijn Brand wrote:
On Wed 08 Jan 2003 05:56, Christopher Faylor [EMAIL PROTECTED] wrote:
I'm sorry. I thought the cygwin project -- was to provide a Posix type
platform to [aid, assist, help] in porting *nix/gnu utils to the Win32
environment.
From: Christopher Faylor
I am not clear on why we are devoting so much time to what is
required for a straight win32 environment in a cygwin mailing
list. As odd as it sounds, this seems somewhat off-topic to
me. Or at least uninteresting.
===
I'm sorry. I thought the cygwin
On Tue, Jan 07, 2003 at 07:44:42PM -0800, linda w (cyg) wrote:
From: Christopher Faylor
I am not clear on why we are devoting so much time to what is required
for a straight win32 environment in a cygwin mailing list. As odd as
it sounds, this seems somewhat off-topic to me. Or at least
If a user calls the 'normalize' function, it should convert it
to \ -- since that is the OS standard/default -- HOWEVER...
I tend to agree that as windows uses the back-slash as a default path
seperator so should `normalize' but also in the interest of
compatability with windows 95 (in dos
Right, so:
Perl for Cygwin uses /
Perl for win32 uses \ and :.
Seems pretty straight forward to me.
Cygwin may be 'just a partial posix layer', but if you are compiling for it, you
should use / delimited paths.
And thats just what I meant to end with before hitting that send button.
-Original Message-
From: Hack Kampbjorn [mailto:[EMAIL PROTECTED]]
Cygwin, and possibly, the Win32 module, are inconsistent in
handling
the differences between i:/foobar/ and i:. On one hand i: is
considered a 'volume' but on the other hand i:/ seems to
evaluate to
-Original Message-
From: Elfyn McBratney [mailto:[EMAIL PROTECTED]]
I tend to agree that as windows uses the back-slash as a
default path seperator so should `normalize' but also in the
interest of compatability with windows 95 (in dos mode) as it
doesn't support the
On Mon, Jan 06, 2003 at 09:43:30AM -0800, LA Walsh wrote:
So it seems that 'syntactically', one can't always determine if a / is
invalid in a straight win32 environment -- at least not when a network name
is involved, but I'd agree it is pathological and should be ignored (and
documented as
On Sun, 05 Jan 2003 00:41:31 PST, LA Walsh wrote:
Syntactically, this can't be anticipated or interpreted and the use of a simpl
e, documented limitation -- the assumption of non-intermixing of \ and / as pa
thname component separators in the same pathname would be used. So the first
/ sets the
On Sun, 05 Jan 2003 21:10:09 +0100, Jos I. Boumans wrote:
Gurusamy Sarathy wrote:
I agree with most of your points, and in particular with the one above.
I consider File::Spec::Win32 currently broken because it hijacks all
paths and turns them into the backslashed variety, which is completely
Jos I. Boumans wrote:
Gurusamy Sarathy wrote:
I agree with most of your points, and in particular with the one
above. I consider File::Spec::Win32 currently broken because it
hijacks all paths and turns them into the backslashed variety, which
is completely wrong from the portability
On Sun, Jan 05, 2003 at 11:02:02AM -0800, Gurusamy Sarathy wrote:
As far as the Win32 native port goes (I'm not really that cygwin-savvy to
comment on what should happen for that port) I like to see:
I'm cygwin savvy and pretty perl savvy (although it's been quite some
time since I've posted
Gurusamy Sarathy wrote:
I agree with most of your points, and in particular with the one
above. I consider File::Spec::Win32 currently broken because it
hijacks all paths and turns them into the backslashed
variety, which
is completely wrong from the portability POV. (By which I
So I think a fix could to change F::S::Win32 to convert all win32
pathseperators to unix pathseperators, and hand it off to F::S::Unix
to do the actual catfile(), etc calls...
Sounds fine, as long as we still do the right thing when
handed paths with backslashes in them (i.e. result should
36 matches
Mail list logo
