469,327 Members | 1,290 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,327 developers. It's quick & easy.

Windows vs. Linux

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 30 '06
53 4887
On Tue, 1 Aug 2006 14:47:59 -0300, Gerhard Fiedler <ge*****@gmail.comwrote:
On 2006-08-01 12:31:01, Sybren Stuvel wrote:
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.
AmigaDOS: '/'. (On the other hand, it didn't understand '.' and '..' without
third-party patches, and it didn't have the '/' directory.).
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.
In the 1980s, MS-DOS /was/ an ugly bastard child; lots of other systems
existed that I have never heard about. As for what path separator they used
and why, I'm afraid you'd have to ask on alt.folklore.computers ...


// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org R'lyeh wgah'nagl fhtagn!
Aug 4 '06 #51
Duncan Booth wrote:
Bryan Olson wrote:
>Duncan Booth wrote:
>>Any other Microsoft commands I try all complain about 'invalid

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.
That seems right, though I don't think Microsoft is deliberately
being difficult. They never put much effort into the command
line; they were trying to imitate the the Mac GUI more than the
Unix shell.

I just tried, and on XP the "explorer" will accept forward
slashes, immediately re-displaying them as backslashes.
Aug 4 '06 #52
Andy Dingley 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
Now, just out of curiosity, what's f*ck-a-duck?

Aug 6 '06 #53

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

C:\>cd /DDocuments and settings

C:\Documents and Settings>
that's because the
cd /D is interpreted as
"change drive and directory"
so I imagine it enables some kind of command extension

but anyway you're right: m$ CMD is weird

Aug 8 '06 #54

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Gaetan Poitras | last post: by
9 posts views Thread by John Eric Hanson | last post: by
4 posts views Thread by John Owens | last post: by
4 posts views Thread by Tim Golden | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by Purva khokhar | last post: by
reply views Thread by haryvincent176 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.