Windows vs. Linux

metaperl wrote:

The reason I'm going with vmware is because I'm afraid that I will need
to compile a C portiion of a Python module and that will not be a
pretty picture under Windows... true or false?

Provided you have the correct compilers installed it is no harder compiling
C extensions under Windows than under Linux. The problem is getting the
correct toolchain installed. You could try the instructions in section A of
http://wiki.python.org/moin/PyrexOnWindows

You only need to follow section B of that document if you want to use
Pyrex, but if you are planning on writing C extensions I strongly recommend
using Pyrex. Also, these days, you can use ctypes for many cases where you
used to have to compile a C extension.

Jul 31 '06 #14

James Stroud

jean-michel bain-cornu wrote:

>Take care to use os.sep

This is an important point. You should read up on the os.path module to
make sure you are doing things in a platform independent way, for
example, its better to use:

os.path.join('my', 'favorite', 'dir')

than

"\\".join(['my', 'favorite', 'dir'])

because the latter will bonk on linux. The former is platform
independent. This hits at the same issue as using os.sep:

os.sep.join(['my', 'favorite', 'dir'])

But os.path has takes care of many of these issues in one module.

James

--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com/

Jul 31 '06 #15

diffuser78

Linux can let you do more in Python and this comes from my personal
exprience. Ubuntu Dapper should let you install drivers easily for
wireless...a little bit tweaking might be required but its worth the
effort. Python and Ubuntu rock...go fot it.

no****@gmail.com wrote:

Okay, once-upon-a-time I tried to start programming by learning C. At
the time I was younger and didn't really understand all that C had to
offer. I eventually moved over to Microsoft's Visual Basic. It was
nice to be able to design a visual application with no effort (too bad
I didn't really learn the ins and outs of programming)

Long story short, I want to get back into programming, and Python looks
like a good choice for me to start with, and maybe become advanced
with. Right now I run Windows as my main operating system. On my old
laptop I ran Ubuntu, and liked it very much; however, my new laptop has
a Broadcom wireless card, and it's not very Linux friendly. Is Windows
an okay enviornment in which to program under Python, or do you
recommend that I run a dual-boot of Linux or maybe a VMWare install to
program under Python?

Jul 31 '06 #16

diffuser78

I'd never recommend dual-boot for anything!

Hardware is cheap, time and trouble is expensive.

Dual-booting if so easy and helpful, I have always found it to be
extremely useful.

You might have a bad experience but I have my laptop and desktop both
running dual boot successfully for 4 and a half years now.

Jul 31 '06 #17

Andy Dingley

di********@gmail.com wrote:

Python and Ubuntu rock...go fot it.

That's nice. I've just burned myself a new Ubuntu f*ck-a-duck release
CD intending to rebuild a flakey old Deadrat box with it. Once it's
done I'd like to be running Python with some USB to Dallas one-wire
hardware on it, re-plugged from an old Windows box. Nice to know I have
a hope of getting somewhere.

Aug 1 '06 #18

OMouse

That is important, but apparently Windows (at least XP) will work fine
with the forward slash that Linux uses. I just tried it in the command
prompt and it works. I'm sure other platforms use the forward slash
separator as well. You've just covered three major platforms (Mac OS X,
WinXP and Linux) without using os.path.join.

And finally, from the Wikipedia entry on Slash (punctuation):
``Note however that the "forward slash" will be translated into a
backslash by most versions of DOS and Windows, in contexts where there
is little ambiguity with command-line options.''

-Rudolf

James Stroud wrote:

jean-michel bain-cornu wrote:
Take care to use os.sep

This is an important point. You should read up on the os.path module to
make sure you are doing things in a platform independent way, for
example, its better to use:

os.path.join('my', 'favorite', 'dir')

than

"\\".join(['my', 'favorite', 'dir'])

because the latter will bonk on linux. The former is platform
independent. This hits at the same issue as using os.sep:

os.sep.join(['my', 'favorite', 'dir'])

But os.path has takes care of many of these issues in one module.

James

--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com/

Aug 1 '06 #19

On 2006-08-01 12:31:01, Sybren Stuvel wrote:

Ehm... replace that with "the latter with bonk on every OS except
Microsoft Windows". Windows is the weird one in OS-land, because they
are the only one that use the most widely used escape-character (the
backslash) as path separator.

Is that really true? From what I know, it's more like this:

- Unix-type systems: '/'
- Windows-type systems: '\'
- Mac OS: ':'
- OpenVMS: '.'
- ...

Maybe someone else can fill in some of the missing OSes. It doesn't seem to
look like Windows is the odd man out; it rather seems that every type of OS
uses its own separator. (URLs probably use the slash because the internet
protocols have been developed largely on Unix-type systems for use with
Unix-type systems?)

Gerhard

Aug 1 '06 #20

On 2006-08-01 16:29:54, Sybren Stuvel wrote:

>- Mac OS: ':'

It's a slash too, at least on non-obsolete Mac OS versions.

I wrote "Mac OS". That's not "Mac OSX". Ask Apple... :) And Mac OSX is
quite arguably a Unix-type system.

>Maybe someone else can fill in some of the missing OSes. It doesn't
seem to look like Windows is the odd man out; it rather seems that
every type of OS uses its own separator.

You can put a whole lot of OSses under "Unix-type", but actually it's
more like this:

Well, you could list a number of DOS versions, too. Doesn't help the fact
that the slash is mainly on Unix-type systems, and that there are or were
quite a number of other systems out there that use other separator
characters.

>(URLs probably use the slash because the internet protocols have been
developed largely on Unix-type systems for use with Unix-type systems?)

It wasn't designed specifically for Unix-type systems, but for universal
access.

Right... the URI/URL syntax was formalized in the early 90ies, when
Unix-type machines were dominant on the internet. There are also quite a
number of concerns that governed the choice of separators and escape
characters for URLs that the IBM, Microsoft and DEC/VMS people couldn't
really foresee in the 70ies (for example, when DEC and IBM started to use
the slash as command line switch character -- which later precluded its use
as path separator).

My point also was that a lot of programming languages use the backslash
as escape character. This has been true at least since the sixties. I
think it's a bad design choice from the Microsoft team to pick this
escape character as a path separator.

Maybe... have you been involved in the decision? Or do you know what the
reasons were? Do you know whether it was even Microsoft's choice?
(Remember, they wrote DOS for IBM. And there was nobody who had foreseen
the PC explosion.)

Did you know that most DOS versions accept the / as path separator? That
DOS was written on Xenix (Posix) systems (using the slash as path
separator)? That Microsoft was for a long time pretty much a pure Xenix
shop?

The problem with the world is stupidity.

Right... And most people are /really/ smart 30 years after the fact; "I
would have known it better" is about as smart as it gets :)

Gerhard

Aug 1 '06 #21

On 2006-08-02 04:42:31, Sybren Stuvel wrote:

I never said "I would have known it better". I just said that IMO it
was a bad design choice ;-)

Well, and I question your qualification to judge that.

In order to say that, you would have to know the reasoning, would have to
put it in the historical context and would have to be able to explain why
that reasoning was wrong at the time. A design choice is not necessarily a
bad choice just because it turns out that some 30 years later there is a
similar common product whose creators made a different choice, and now
programmers have to cater to both. With the same reasoning one could say
that the Unix creators should have used the VMS (or any other existing)
form.

Gerhard

Aug 2 '06 #22

John Salerno

Gerhard Fiedler wrote:

A design choice is not necessarily a
bad choice just because it turns out that some 30 years later there is a
similar common product whose creators made a different choice, and now
programmers have to cater to both.

To be fair, this isn't the reason he gave for it being a bad design
choice. His reason was that MS chose to use the escape character as
their path separator.

But of course I still agree with you that in either case it's not a
judgment you can fairly make 30 years after the fact.

Aug 2 '06 #23

Richard Brodie

"Gerhard Fiedler" <ge*****@gmail.comwrote in message
news:ma***************************************@pyt hon.org...

>With the same reasoning one could say that the Unix creators should have
used the VMS (or any other existing) form.

Only if they used Guido's time machine.

Aug 2 '06 #24

bryanjugglercryptographer

Sybren Stuvel wrote:

John Salerno enlightened us with:
But of course I still agree with you that in either case it's not a
judgment you can fairly make 30 years after the fact.

I don't see Microsoft changing it the next 30 years either... Apple
moved from \r to \n as EOL character. I'm sure the folks at mickeysoft
are smart enough to change from \ to /.

They dis-allow '/' in filenames, and many Microsoft products now
respect
'/' as an alternate to '\'.

>From a WinXP command prompt:

C:\>
C:\>cd /windows/system32

C:\WINDOWS\system32>
For a "Windows vs. Linux" thread, this one has been remarkably
rant-free.

--
--Bryan

Aug 2 '06 #25

br***********************@yahoo.com wrote:

>>From a WinXP command prompt:

C:\>
C:\>cd /windows/system32

C:\WINDOWS\system32>

Not from my Windows XP command prompt it doesn't. Do you have anything
strange installed on your system?

Aug 2 '06 #26

Gerhard Fiedler <ge*****@gmail.comwrote:
...

a few fine points of computing history...:

(URLs probably use the slash because the internet protocols have been
developed largely on Unix-type systems for use with Unix-type systems?)
It wasn't designed specifically for Unix-type systems, but for universal
access.

Right... the URI/URL syntax was formalized in the early 90ies, when

The internet *protocols* were typically developed on non-Unix systems --
that's why each line in text-based protocols must be terminated by
\r+\n, not just \n. The WWW, as you mention, came later (and I believe
it was born on a NEXT cube, i.e., a unix-variant).

My point also was that a lot of programming languages use the backslash
as escape character. This has been true at least since the sixties. I
think it's a bad design choice from the Microsoft team to pick this
escape character as a path separator.

Maybe... have you been involved in the decision? Or do you know what the
reasons were? Do you know whether it was even Microsoft's choice?
(Remember, they wrote DOS for IBM. And there was nobody who had foreseen
the PC explosion.)

Microsoft did *NOT* write DOS -- they purchased it from a small Seattle
company, which called it QDOS (Quick and Dirty OS) and had hacked it up
"in desperation" because CP/M did not run on intel 8086 CPUs, so the
small company's main business, selling 8086 boards, languished. QDOS
was as compatible with CP/M as said small company could make it (rumor
has it that big parts were disassembled from CP/M and reassembled to run
on 8086 rather than 8080). Part of the CP/M compatibility did include
the use of / as flag-indicator (the use of \r+\n as line ending also
comes from CP/M -- in turn, CP/M had aped these traits from some DEC
minicomputer operating systems).

When MS did write an OS -- DOS 2.0, which introduced a directory tree --
they did put in the OS an undocumented switch to make - the
flag-indicator and / the path separator, rather than / and \
respectively. However it was never documented and it got removed in
later versions, perhaps because applications coded to the /-and-\
convention could break if the switch was thrown.

Did you know that most DOS versions accept the / as path separator? That
DOS was written on Xenix (Posix) systems (using the slash as path
separator)? That Microsoft was for a long time pretty much a pure Xenix
shop?

Internally yes (indeed, they developed Xenix, before later selling it to
SCO), but that does not mean that "DOS was written on Xenix" because DOS
was *not* written in Microsoft, as above mentioned.
Alex

Aug 2 '06 #27

jean-michel bain-cornu <py********@nospam.jmbc.frwrote:

Andy Dingley a écrit :
I'd never recommend dual-boot for anything!
Don't agree man, it's good for testing...

It's bothersome for testing: virtualization is much handier in most
cases.
Alex

Aug 2 '06 #28

John Salerno

Sybren Stuvel wrote:

Apple
moved from \r to \n as EOL character.

Interesting. I didn't know that. Although it does seem to make sense to
use both \r\n as EOL (if you still consider one as a carriage return and
one as a newline, a la old school typewriters), \n is much nicer and
cleaner looking. :)

Aug 2 '06 #29

On 2006-08-02 11:29:18, Sybren Stuvel wrote:

John Salerno enlightened us with:
>But of course I still agree with you that in either case it's not a
judgment you can fairly make 30 years after the fact.

I don't see Microsoft changing it the next 30 years either... Apple
moved from \r to \n as EOL character.

AFAIK there are few programs from Apple's \r era that still work in the \n
era systems, or am I mistaken with this? :) I also doubt that the line
terminator had any influence in Apple's decision to change their OS. It was
a mere (unintended) side effect, not an objective. If they had chosen a
line terminator, they better had chosen \r\n (the internet email standard).

Unix-type systems still don't use natively the line terminator that is used
in internet email. Windows-type systems do. So when you want to send a text
file stored on a Unix-type system as email, you have to translate the line
terminations (or vice versa). Just as for MS there are good reasons not to
"fix" the backslash now (what would be a good reason to change it?), there
are good reasons for Unix-type system writers to stick with their
traditional \n.
(From a different message)

I'm talking about the fact that they have chosen a common escape
character as path separator.

What's so specifically bad about a "common escape character"? Any character
that has a special meaning in something can be inconvenient when it has to
be used normally. A backslash in a C string, a dot in a regex, you probably
can find examples for any non-alphanumeric ASCII character.

The only "problem" with the backslash is that you need to escape it in C
strings; I never had any trouble with that. BTW, are you really sure that
the backslash was a "common escape character" in the 70ies? How common was
it back then? Even today, it seems to be mostly a C idiom. (In that
respect, Python is leaning on C, even ever so slightly.)
Get over it... there are any number of definitions out there, some better
chosen than others, and most had a good set of reasons at the time they
were chosen. Mostly by chance, some fit better into the picture some
decades later, and some fit less nicely. Without really getting down to it,
there's no way to tell whether any of the standards was well-chosen. Even
the ones that look now as if they were... could be mere luck.

You're of course entitled to your opinion. I never wanted to doubt that.
But an unfounded opinion usually tells more about the subject than the
object... :)

Gerhard

Aug 2 '06 #30

On 2006-08-02 13:24:10, Dennis Lee Bieber wrote:

Change Directory may work... but

C:\Documents and Settings\Dennis Lee Bieber>cd c:\

C:\>cd /windows/system32

C:\WINDOWS\SYSTEM32>cd c:\

C:\>dir /windows/system32
Parameter format not correct - "windows".

Since '/' is used as standard command line parameter separator, any command
that uses standard Windows command line parameters can't accept a path with
'/' as argument; it wouldn't know how to differentiate between a path
element and an argument. Try

C:\>dir "/windows/system32"
That was one of the original reasons for using backslashes as path
separator: the existing code base that used the slash as command line
argument separator.

Gerhard

Aug 2 '06 #31

On 2006-08-02 12:41:44, Alex Martelli wrote:

Microsoft did *NOT* write DOS

Well, they didn't write most of DOS 1.0. But it seems they did write (or at
least specify) most if not all of the rest up to DOS 6.22 or so. Which is
possibly considerable.

Part of the CP/M compatibility did include the use of / as flag-indicator
(the use of \r+\n as line ending also comes from CP/M -- in turn, CP/M
had aped these traits from some DEC minicomputer operating systems).

At the time, probably pretty good reasons for using the slash as command
line flag indicator.

Internally yes (indeed, they developed Xenix, before later selling it to
SCO), but that does not mean that "DOS was written on Xenix" because DOS
was *not* written in Microsoft, as above mentioned.

I probably should have said "everything between DOS 1.0 and DOS 6.22" was
written on Xenix, to be more precise :)

And, as an aside, I'm sure that MS would have sold more of their Xenix if
the market had wanted it. But the market really wanted DOS...

Gerhard

Aug 2 '06 #32

On 2006-08-02 17:38:54, Sybren Stuvel wrote:

Gerhard Fiedler enlightened us with:

>>Microsoft did *NOT* write DOS

Well, they didn't write most of DOS 1.0. But it seems they did write
(or at least specify) most if not all of the rest up to DOS 6.22 or
so. Which is possibly considerable.

Those are MS-DOS version numbers you're talking about.

Of course. The issue was that I wrote that "Microsoft wrote DOS on Xenix"
and Alex objected. I was of course wrong in that totality, but then, they
still wrote everything between DOS 1.0 and 6.22 on Xenix.

For example, they had nothing to do with FreeDOS, which is also a DOS.

Yup, and a number of other DOSes like Novell DOS etc. Still all (or most?)
of these use the backslash :)

Gerhard

Aug 2 '06 #33

Christopher Weimann

On 08/02/2006-08:06AM, br***********************@yahoo.com wrote:

>
From a WinXP command prompt:

C:\>
C:\>cd /windows/system32

C:\WINDOWS\system32>

This doesn't work the way you think it does.

C:\>cd /windows

C:\WINDOWS>cd /system32

C:\WINDOWS\system32>

C:\WINDOWS\system32>cd /windows
The system cannot find the path specified.

It IGNORES a leading / char.

--
------------------------------------------------------------
Christopher Weimann
http://www.k12usa.com
K12USA.com Cool Tools for Schools!
------------------------------------------------------------

Aug 2 '06 #34

On 2006-08-02 17:36:06, Sybren Stuvel wrote:

IMO it's too bad that "they" chose \r\n as the standard. Having two
bytes as the end of line marker makes sense on typewriters and
similarly operating printing equipment.

I may well be mistaken, but I think at the time they set that standard,
such equipment was still in use. So it may have been a consideration.

Nowadays, I think having a single byte as the EOL maker is quite a bit
clearer.

Rather than thinking in bytes and the like when inserting an EOL marker,
inserting really an EOL marker (that then gets translated by low level code
to the appropriate byte sequence as needed) is probably the less archaic
way to do that :)

On the other hand, with the use of UTF-8 encodings and the like, the
byte-to-character mapping is gone anyway, so perhaps I should just get
used to it ;-)

Yes :) "Bytes" is getting definitely too low level. Especially with higher
level languages like Python... there are not many byte manipulation
facilities anyway. The language is at a much higher level, and in that
sense the classic strings are a bit out of line, it seems.

>Just as for MS there are good reasons not to "fix" the backslash now

Which are those reasons, except for backward compatability?

I don't know how many reasons you need besides backward compatibility, but
all the DOS (still around!) and Windows apps that would break... ?!? I
think breaking that compatibility would be more expensive than the whole
Y2k bug story. And don't be fooled... you may run a Linux system, but you'd
pay your share of that bill anyway.

Less FAQs in this group about people putting tabs, newlines and other
characters in their filenames because they forget to escape their
backslashes?

Or forget to use raw strings. (If you don't want it to be escaped, please
say so :)

But similar as I wrote above with the EOL thing, I think that the whole
backslash escape character story is not quite well-chosen. In a way, this a
mere C compatibility pain in the neck... (Of course there are
implementation and efficiency reasons, mainly because Python is based on C
APIs, but all that is as arbitrary as the selection of the backslash as
path separator.)

There could be other solutions (in Python, I mean). Only accept raw strings
in APIs that deal with paths? Force coders to create paths as objects, in a
portable way, maybe by removing the possibility to create paths from
strings that are more than one level in the path? Or introduce a Unicode
character that means "portable path separator"? Or whatever... :)

Strings and filenames are usually tightly coupled in any program
handing files, though.

Yes, and that's IMO something from way below in the implementation depths.
While file names and paths are strings, not every string is a valid and
useful file name or path. This shows that using strings for file names and
paths has tradition (coming from low level languages like C), but IMO is
not quite appropriate for a higher abstraction level.

Almost every programming language I know of uses it as the escape
character, except for perhaps VB Script and the likes. Not sure about
the different assembly languages, though.

There are so many languages... and I know so few of them...
http://en.wikipedia.org/wiki/Categor...ming_languages

Now it may be predominant (I still think it's mostly present in languages
that are in some way influenced by C), but in the 70ies?

IIRC, Pascal uses '^' for a similar purpose (not quite the same, but
similar). This form is still in ample use in documentation to mean
"Ctrl-<char>"; probably much more common than the backslash notation.

Sure. I've talked more about this specific subject in this thread than
in the rest of my life ;-)

There's a first for everything :)

I think cooperation and uniformity can be a very good thing. On the other
hand, Microsoft want the software written for their platform to stay on
their platform. That's probably one of the major reasons to remain
incompatible with other systems.

Probably. But even if I'd had a say there (and I hate switching between
separator characters just as much as the next guy, and possibly do so more
than you given that I work on a Windows system, with slashes in repository
paths and URIs), I'm not sure I'd make the jump away from the backslash as
path separator. That's just breaking too much code. You don't want to have
all these curses directed at you...

Gerhard

Aug 2 '06 #35

Gerhard Fiedler <ge*****@gmail.comwrote:
...

Part of the CP/M compatibility did include the use of / as flag-indicator
(the use of \r+\n as line ending also comes from CP/M -- in turn, CP/M
had aped these traits from some DEC minicomputer operating systems).

At the time, probably pretty good reasons for using the slash as command
line flag indicator.

In DEC's case, the / was an essentially random choice -- nothing
particularly stood either for or against it -- and there was no
particularly good reason for CP/M to ape it later, either (Unix is even
older than CP/M, _and_ ran on HW essentially identical to that used by
some of said DEC OS's, yet, having good designers, it "broke" both these
points of "compatibility"... yet didn't suffer in the least thereby).

The \r+\n choice is different -- it did indeed have a good reason _at
the time_ DEC chose it: for OSs without real device drivers (on machines
with no power to spare for even the most trivial processing), sending a
bunch of lines to a dumb teletype really needed the lines to be
terminated by telling the tty both to return-carriage (the \r) AND to
advance paper (the \n) -- and the former had to be first because the
carriage-return operation was mechanically slower but could occur at the
same time as the paper advance. But these issues did not apply by the
'70s, when CP/M was born and Unix got its name (from the previous name,
briefly used in the late '60s, of UNICS).

Whether there's "a good reason" to embed the consequences of these
mechanical issues in fileformats and protocols, destined no doubt to
survive for many decades to come, 40 years after said issues had become
essentially moot, is another issue... but backwards-incompatible changes
ARE always hard (and yet, the original designers of successful systems
are basically never as ambitious and visionary as to think of the effect
their choices of today will have 40 or 80 years down the road -- systems
designed with the mindset of thinking many-decades-ahead tend to fail in
their struggle against quick-and-dirty ones, as bemoaned but lucidly
analyzed in Gabriel's deservedly famous essay on "worse is better", e.g.
at <http://www.jwz.org/doc/worse-is-better.html>).

And, as an aside, I'm sure that MS would have sold more of their Xenix if
the market had wanted it. But the market really wanted DOS...

Yes, particularly considering the much higher HW demands of Xenix's
entry point, compared to DOS's -- not only did Xenix always require a
hard disk, but, for over 2 years, Xenix supported only Zilog Z8001 and
later Motorola 68000... it took SCO, in late 1983, to release an 8086
version, and by that time DOS was well entrenched in the marketplace,
also supporting floppy-only machines that remained a much more
affordable entry point than hard-disk ones for further years.
Basically, by the time PCs with hard disks were starting to become
widespread, MS had lost interest in marketing Xenix, which only SCO was
pushing, so it made sense in '87 for MS to sell SCO Xenix outright in
exchange for a large slice of SCO's stock (20%, if I remember right).
Alex

Aug 3 '06 #36

On 2006-08-02 21:09:43, Sybren Stuvel wrote:

Microsoft could provide an emulated environment for backward
compatability, just like Apple did. Wouldn't know what that would cost,
though.

Possibly. Rather than waiting for that, I think that languages that want a
degree of portability should simply provide a wrapper around this low level
system dependent stuff. There's no need to use system dependent path
separation characters in the language API.

>And don't be fooled... you may run a Linux system, but you'd pay
your share of that bill anyway.

How's that?

Pretty much every production cost increase gets in the end paid by the
consumer. With some localized changes, you may be lucky and don't buy any
products that are affected, but with such a widespread change as this would
be, it is more likely that almost everybody is affected close to average.
With that is also mostly the pressure gone to not increase -- because so
many are affected that the few who are not happily increase the prices with
the others.

The only ones likely to make a cut for a short time are a number of Windows
consultants. But those probably would be mostly either people with some
previous involvement with the product or the company, or cheap offshore
resources. Probably neither is your case... :)

Gerhard

Aug 3 '06 #37

Sybren Stuvel <sy*******@YOURthirdtower.com.imaginationwrote:

Gerhard Fiedler enlightened us with:
I don't know how many reasons you need besides backward
compatibility, but all the DOS (still around!) and Windows apps that
would break... ?!? I think breaking that compatibility would be
more expensive than the whole Y2k bug story.

Microsoft could provide an emulated environment for backward
compatability, just like Apple did. Wouldn't know what that would
cost, though.

I believe Microsoft could have saved many billions of dollars of
development costs, and hit the market well in time for the 2006 holiday
season, if they had designed Vista that way -- a totally new system, wih
no direct compatibility constraints, and with virtualization used to run
XP stuff. That strategy (in the Mac OS 9 -Mac OS X migration path,
with "Classic" as the ``virtualization'' layer) is what saved Apple's
bacon when all attempts to craft compatible extensions of old Mac OS had
floundered in excessive costs and complexity. And virtualization is
obviously a prepotently emerging technology -- look at VMWare's huge
profits, at Microsoft's purchase of the makers of VirtualPC, at the rise
of Parallels, at open-source developments such as QEMU and Xen...

I think the folks at microsoft are used to getting cursed at :)

Particularly by their stockholders, with the stock down from a high of
almost 60 to the recent lows of below 22...:-)
Alex

Aug 3 '06 #38

Duncan Booth wrote:

br***********************@yahoo.com wrote:

>From a WinXP command prompt:

C:\>
C:\>cd /windows/system32

C:\WINDOWS\system32>

Not from my Windows XP command prompt it doesn't. Do you have anything
strange installed on your system?

Tons of strange stuff, yes, but I just tried it on a couple
machines on display at BestBuy, and it worked as I showed it.
Maybe a recent change.
--
--Bryan

Aug 4 '06 #39

Christopher Weimann wrote:

On 08/02/2006-08:06AM, br***********************@yahoo.com wrote:
>From a WinXP command prompt:

C:\>
C:\>cd /windows/system32

C:\WINDOWS\system32>

This doesn't work the way you think it does.

C:\>cd /windows

C:\WINDOWS>cd /system32

C:\WINDOWS\system32>

C:\WINDOWS\system32>cd /windows
The system cannot find the path specified.

It IGNORES a leading / char.

Ah, yes, I see.

As Gerhard Fiedler pointed out, they use '/' elsewhere on
command lines to introduce options, so it could be ambiguous as
the first character of a path name.
--
--Bryan

Aug 4 '06 #40

On 2006-08-03 04:53:11, Sybren Stuvel wrote:

>Pretty much every production cost increase gets in the end paid by
the consumer. With some localized changes, you may be lucky and
don't buy any products that are affected, but with such a widespread
change as this would be, it is more likely that almost everybody is
affected close to average.

You still don't tell me how I could be affected by a production cost
increase at a company I'm buying nothing from.

You don't buy your gas as crude from Saudi Arabia oil well, do you? :)
Their production cost increases may affect you nevertheless.

There are very few products you buy that are only affected by costs
generated in one company. Usually that's dozens, if not hundreds of
companies in the chain. (That's not to say that all of them are relevant,
price-wise, but it's more than one that's relevant, usually.) Take your
pick, anything, and try to find out the price building chain. You may be
surprised.

Besides, you probably don't know whether it's not one of your direct
suppliers who's affected. You're sure you don't buy from anybody running a
Windows system? I'd bet against that, and I only bet when I know I win :)

I'm not talking about something obvious like a 10% increase. An overall
(average) 1% increase is easy to dismiss as not relevant -- but it's still
1%, if you add it up. (I'm not claiming it would be 1% though. Just an
example number.)

>With that is also mostly the pressure gone to not increase --
because so many are affected that the few who are not happily
increase the prices with the others.

Either my English isn't as good as I thought, or that's simply
incomprehendable.

Possibly the latter... I'll try again :)

When there's a change in the cost structure of some companies, they try to
pass that on through their prices. That's just natural. If the cost
structure of a whole sector changes, that's easy, because all of them will
want to increase by the same margin, and the cost structure of the whole
sector remains the same. (See gas prices.)

If almost all of a sector are affected, this still doesn't change
(usually): the ones who are not affected often just go with the crowd and
increase nevertheless, figuring they can gain more by increased margins
than they would gain by increased market share due to lower prices. (There
are all kinds of factors that affect this; not always a lower price gets
reflected in a higher market share.)

But they (or some of them) could also decide to stay at their lower price
to gain market share. But if the production cost for 80% of a sector goes
up, it may be that the 20% who don't have that cost increase stay low, but
the average price of that sector still will go up. (Not everybody will move
to the suppliers now with lower cost.) With that, the average production
cost for companies that depend on that sector will go up. So there's an
average hike anyway, even if some or all of the ones who don't have to
increase actually don't.

Gerhard

Aug 4 '06 #41

Bryan Olson wrote:

Duncan Booth wrote:
>br***********************@yahoo.com wrote:

>>From a WinXP command prompt:

C:\>
C:\>cd /windows/system32

C:\WINDOWS\system32>

Not from my Windows XP command prompt it doesn't. Do you have anything
strange installed on your system?

Tons of strange stuff, yes, but I just tried it on a couple
machines on display at BestBuy, and it worked as I showed it.
Maybe a recent change.

As other postings to this thread have shown it is simply that Windows is
taking the forward slash as introducing an option and then ignoring it
entirely if the next letter doesn't match one of the options it knows
about. So for example (/D being an option to CD):

C:\>cd /Documents and settings
The system cannot find the path specified.

C:\>cd /DDocuments and settings

C:\Documents and Settings>

Aug 4 '06 #42

Duncan Booth wrote:

Bryan Olson wrote:

>Duncan Booth wrote:
>>br***********************@yahoo.com wrote:

From a WinXP command prompt:

C:\>
C:\>cd /windows/system32

C:\WINDOWS\system32>
Not from my Windows XP command prompt it doesn't. Do you have anything
strange installed on your system?

>Tons of strange stuff, yes, but I just tried it on a couple
machines on display at BestBuy, and it worked as I showed it.
Maybe a recent change.

As other postings to this thread have shown it is simply that Windows is
taking the forward slash as introducing an option and then ignoring it
entirely if the next letter doesn't match one of the options it knows
about.

Not quite. The first slash is ambiguous and apparently ignored,
but latter slashes are taken as a path separators.

Have you determined why it didn't work on your XP box as it did
on mine and on the machines at BestBuy?
--
--Bryan

Aug 4 '06 #43

Bryan Olson wrote:

Not quite. The first slash is ambiguous and apparently ignored,
but latter slashes are taken as a path separators.

I'm not sure ambiguity enters into it. I think perhaps the bad detection of
the option happens because the CD command can ignore spaces in its
argument. Since it is ignoring spaces they don't actually require a space
after the option strings.

Any other Microsoft commands I try all complain about 'invalid switch'.

>
Have you determined why it didn't work on your XP box as it did
on mine and on the machines at BestBuy?

Simply that I hadn't changed to the root directory first so there was no
subdirectory named 'windows'.

Aug 4 '06 #44

Duncan Booth wrote:

Bryan Olson wrote:

>Not quite. The first slash is ambiguous and apparently ignored,
but latter slashes are taken as a path separators.

I'm not sure ambiguity enters into it. I think perhaps the bad detection of
the option happens because the CD command can ignore spaces in its
argument. Since it is ignoring spaces they don't actually require a space
after the option strings.

You lost me. Spaces are significant in file names, and slashes
within the path are used as path separators, as far as I can
tell.

Try cd'ing several subdirectories deep on XP with forward
slashes. It works for me, and it could not if slashes were
ignored as you suggested.

Any other Microsoft commands I try all complain about 'invalid switch'.

The first I noticed were their build tools. Their version of
"make", called "nmake", and their visual studio tools will
accept either forward or backward slashes in paths.

>Have you determined why it didn't work on your XP box as it did
on mine and on the machines at BestBuy?

Simply that I hadn't changed to the root directory first so there was no
subdirectory named 'windows'.

Ah, my example showed a particular root: "C:\". Does your system
work the same if you set the current directly as shown?
--
--Bryan

Aug 4 '06 #45

andrew clarke

On Tue, Aug 01, 2006 at 05:31:01PM +0200, Sybren Stuvel wrote:

James Stroud enlightened us with:
its better to use:

os.path.join('my', 'favorite', 'dir')

than

"\\".join(['my', 'favorite', 'dir'])

because the latter will bonk on linux.

Ehm... replace that with "the latter with bonk on every OS except
Microsoft Windows". Windows is the weird one in OS-land, because they
are the only one that use the most widely used escape-character (the
backslash) as path separator.

OS/2 (and eComStation) also uses the backslash as the path separator.

Aug 4 '06 #46

Bryan Olson wrote:

Duncan Booth wrote:
>I'm not sure ambiguity enters into it. I think perhaps the bad
detection of the option happens because the CD command can ignore
spaces in its argument. Since it is ignoring spaces they don't
actually require a space after the option strings.

You lost me. Spaces are significant in file names, and slashes
within the path are used as path separators, as far as I can
tell.

Sorry I was unclear. It isn't that spaces are ignored, it is that they do
not count as delimiters in the CD command. In all other DOS commands they
count as argument delimiters unless they are inside quotes.

>Any other Microsoft commands I try all complain about 'invalid
switch'.

The first I noticed were their build tools. Their version of
"make", called "nmake", and their visual studio tools will
accept either forward or backward slashes in paths.

Ok, pedantically I meant the commands that come as part of the system. Most
external tools such as Microsoft's compilers have always accepted forward
slashes interchangeably with backslashes. They also usually accept '-' as
an option character interchangeably with '/'. The 'standard' commands
though seem to go to a lot of effort to reject forward slashes in paths,
and the CD command seems to be the only one where this usage gets through
the net.

Aug 4 '06 #47

On 2006-08-04 05:30:00, Sybren Stuvel wrote:

>Besides, you probably don't know whether it's not one of your direct
suppliers who's affected. You're sure you don't buy from anybody
running a Windows system? I'd bet against that, and I only bet when
I know I win :)

Good point. I don't buy much software, though. The only things I buy
are some games every now and then.

No food? No clothes? No furniture? No household supplies? No
transportation? No bike/bicycle/car? They all (well, most of them) use
computers in their administration; /that's/ the cost I was talking about,
not the cost for the software industry :)

Gerhard

Aug 4 '06 #48

andrew clarke

On Fri, Aug 04, 2006 at 02:01:58PM +0200, Sybren Stuvel wrote:

OS/2 (and eComStation) also uses the backslash as the path
separator.

You mean OS/2 is still in actual use?

'fraid so. :-)

Aug 4 '06 #49