Launch file in Notepad

[George]

Newbie question:

I'm trying to lauch Notepad from Python to open a textfile:

import os
b1="c:\test.txt"
os.system('notepad.exe ' + b1)

However, the t of test is escaped by the \, resulting in Notepad trying
to open "c: est.txt".

How do I solve this?

(By the way, b1 comes from a command line parameter, so the user enters
c:\test.txt as command line parameter.)

George

 

[Brian van den Broek]

George said unto the world upon 2005-05-12 09:41:

Newbie question:

I'm trying to lauch Notepad from Python to open a textfile:

import os
b1="c:\test.txt"
os.system('notepad.exe ' + b1)

However, the t of test is escaped by the \, resulting in Notepad trying
to open "c: est.txt".

How do I solve this?

There are several ways, but the preferred solution is to switch the
slash direction: "c:/test.txt". Python's smart enough to notice its
running on Windows and do the right thing with the slash. (Other
choice include using raw strings: r"c:\test.txt", and explicitly
escaping the backslash: "c:\\test.txt".)

Best,

Brian vdB

 

[Richie Hindle]

[George]

b1="c:\test.txt"

With this code, your problem is the embedded tab as you say. Use either
r"c:\test.txt" or "c:\\test.txt". However, if this is true:

By the way, b1 comes from a command line parameter, so the user enters
c:\test.txt as command line parameter.

then there will be no embedded tab. How are you prompting the user? When
I run this:

import os
b1=raw_input("Enter a filename: ")
os.system('notepad.exe ' + b1)

and enter c:\test.txt, it works as expected.

[Brian]

There are several ways, but the preferred solution is to switch the
slash direction: "c:/test.txt". Python's smart enough to notice its
running on Windows and do the right thing with the slash.

In fairness to Windows, I don't believe Python does anything special here.
Windows itself happily accepts either forward slash or backslash at the OS
level - it's only the shells (explorer.exe or to a lesser extent cmd.exe)
that don't accept forward slashes.

 

[Grant Edwards]

There are several ways, but the preferred solution is to switch the
slash direction: "c:/test.txt". Python's smart enough to notice its
running on Windows and do the right thing with the slash.

Does Python really look at the string and mess with the slash?
I don't think it needs to, since the Windows system calls have
always accepted forward slashses, haven't they?

 

[George]

How are you prompting the user? When I run this:

import os
b1=raw_input("Enter a filename: ")
os.system('notepad.exe ' + b1)

and enter c:\test.txt, it works as expected.

So it does with me, but the user does not enter the filename, he
launches my Python script file from the DOS-prompt with a command line
parameter, for example:

test.py c:\test.txt

In that case the \ escapes the t. (read on!)

That is, until now. For some very strange reason it suddenly works as
expected. I don't understand it anymore, but never mind. Maybe I changed
my little proggie somehow, causing it accidentally to work. Thanks anyway.

George

 

[Bengt Richter]

Newbie question:

I'm trying to lauch Notepad from Python to open a textfile:

import os
b1="c:\test.txt"

os.system('notepad.exe ' + b1)

However, the t of test is escaped by the \, resulting in Notepad trying
to open "c: est.txt".

Right. '\t' is a tab, not two characters. You can get the characters you want
by escaping the escape

How do I solve this?

(By the way, b1 comes from a command line parameter, so the user enters
c:\test.txt as command line parameter.)

It should be ok then, unless you have somehow processed the command line parameter and interpreted
the backslash as an escape. E.g., pargs.py here prints command line args and backslash is
an ordinary string character as you see in argv[3] below. If it were a tab, you would see
whitespace instead of the backslash.

[ 7:35] C:\pywk\parse\ast>type c:\util\pargs.py
import sys
for i in xrange(len(sys.argv)):
print 'argv[%d]: "%s"' % (i,sys.argv)

[ 7:35] C:\pywk\parse\ast>py24 c:\util\pargs.py abc def c:\test.txt
argv[0]: "c:\util\pargs.py"
argv[1]: "abc"
argv[2]: "def"
argv[3]: "c:\test.txt"

If by "command line" you mean your own programmed input, make sure you use raw_input, not input, e.g.,
Enter text please: > c:\test.txt
-->>c:\test.txt<<--

But input evaluates the input string (also posing security problems if you don't trust the user):Enter text please: > c:\test.txt
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<string>", line 1
c:\test.txt
^
SyntaxError: invalid syntax

That was from evaluating, so we can quote: Enter text please: > "c:\test.txt"
-->>c: est.txt<<--
^^--there's that tab \t again, unless you escape the backslash
Enter text please: > "c:\\test.txt"
-->>c:\test.txt<<--


But in your example above,

>>> b1="c:\test.txt"
>>> b1 'c:\test.txt'
>>> list(b1) ['c', ':', '\t', 'e', 's', 't', '.', 't', 'x', 't']
>>> print '-->>%s<<--'%b1

-->>c: est.txt<<--

Escaping the escape: -->>c:\test.txt<<--

Using raw string format (prefixed r on string), which won't work if
string ends in backslash BTW) -->>c:\test.txt<<--

To see the single tab character in your original

>>> b1="c:\test.txt"
>>> b1[2] '\t'
>>> ord(b1[2])

9

BTW, you might want to use os.system('start notepad ' + b1)
if you want an independent process and not wait for notepad to finish.


Regards,
Bengt Richter

 

[George]

> On 2005-05-12, Brian van den Broek <[email protected]> wrote:

> Does Python really look at the string and mess with the slash?
> I don't think it needs to, since the Windows system calls have
> always accepted forward slashses, haven't they?

It did, but now not anymore. I don't understand why, maybe I've changed
something in the code. See my other post.

George

 

[George]

(By the way, b1 comes from a command line parameter, so the user enters
c:\test.txt as command line parameter.)

It should be ok then, unless you have somehow processed the command line parameter and interpreted
the backslash as an escape. E.g., pargs.py here prints command line args and backslash is
an ordinary string character as you see in argv[3] below. If it were a tab, you would see
whitespace instead of the backslash.

Perhaps that's what I did (processing the command line parameter). For
some reason it works now.

If by "command line" you mean your own programmed input, make sure you use raw_input, not input, e.g.,

I was referring to the user launching my script with a filename as
parameter:

test.py c:\test.txt

Here's my code so far (it removes blank lines from the input file (for
example c:\test.txt), and creates a new file (c:\test_new.txt) to store
the output):

import string
import sys
import os
if len(sys.argv)<=1:
print 'Usage: dbl.py [filename]'
sys.exit()
b1=sys.argv[1]
b2=b1[:-4] + '_new' + b1[-4:]
f1=open(b1,'r')
f2=open(b2,'w')
r1=f1.readlines()
for r in r1:
if string.capwords(r)<>'':
f2.write(r)
f1.close()
f2.close()
print 'Output file: ' + b2
os.system ('start notepad.exe ' + b2)

George

 

[Bengt Richter]

Does Python really look at the string and mess with the slash?
I don't think it needs to, since the Windows system calls have
always accepted forward slashses, haven't they?

For a path parameter, I think so. But various command shells us '/' the
way unix uses '-' -- i.e., for options/switches. E.g.
ls -R foo/bar
would work as
dir /s "foo/bar"
since the shell would pass on the quoted string to the os level (with quotes removed)
Likewise
dir foo\bar/s
would work, but not
dir foo/bar/s
or
dir/s foo/bar

I don't know why MS used backslashes when unix had a perfectly good path syntax
(not to mention drive letter idiocy). Maybe some legal idiocy, wanting to be
different to be safe from SCO types?

Regards,
Bengt Richter

 

[Grant Edwards]

For a path parameter, I think so. But various command shells us '/' the
way unix uses '-' -- i.e., for options/switches. E.g.

You're right. It's the applications that choke on the forward
slash. Back in the bad old days there was a way to tell DOS to
use '-' for the switch character, but not all apps paid
attention to the setting.

I don't know why MS used backslashes when unix had a perfectly
good path syntax (not to mention drive letter idiocy). Maybe
some legal idiocy, wanting to be different to be safe from SCO
types?

I think the use of forward slashes for command line switches
was adopted by CP/M from DEC's OSes (e.g. RSX-11). CP/M didn't
have directories in the beginning, so nobody worried about what
to use for path separators (DEC used colons, IIRC). DOS was a
straight-up ripoff of CP/M and kept '/' as the option
character. Later when directories were added to DOS, they
picked '\' as the path seperator becuase '/' was the default
switch caracter. The C-language "system calls" always accepted
either, but they may have been translating forward to backward
before making the DOS call calls.

 

[Dennis Lee Bieber]

I don't know why MS used backslashes when unix had a perfectly good path syntax
(not to mention drive letter idiocy). Maybe some legal idiocy, wanting to be
different to be safe from SCO types?

The MS-DOS precursor (and/or CP/M) used "/" to introduce command
line options. This meant, when subdirectories were introduced, they had
to come up with a new separator character.

--

 

[Fredrik Lundh]

There are several ways, but the preferred solution is to switch the
slash direction: "c:/test.txt". Python's smart enough to notice its
running on Windows and do the right thing with the slash.

that's slightly misleading: on the API level, most functions can handle
both kinds of slashes. functions like open(), os.remove(), shutil.copy()
etc. handles either case just fine. and in most cases, this is handled
on the Win API level (or in the C library), not by Python.

however, in this case, the user passes a string to os.system(). that
string is passed *as is* to the command shell (which, in this case,
passes it on to notepad.exe as is).

</F>

 

[Bengt Richter]

The MS-DOS precursor (and/or CP/M) used "/" to introduce command
line options. This meant, when subdirectories were introduced, they had
to come up with a new separator character.

Or overcome some NIH and switch to '-' for command line options? ;-)

Regards,
Bengt Richter

 

[Greg Krohn]

Newbie question:

I'm trying to lauch Notepad from Python to open a textfile:

import os
b1="c:\test.txt"
os.system('notepad.exe ' + b1)

However, the t of test is escaped by the \, resulting in Notepad trying
to open "c: est.txt".

How do I solve this?

(By the way, b1 comes from a command line parameter, so the user enters
c:\test.txt as command line parameter.)

George

The \t will only be interpreted as TAB if it was entered as part of
your python code. If the \t was entered as a command line arg it will
be interpreted as a \ and a t. For example:


#test.py
import sys
b1 = sys.argv[1]
b2 = "C:\test.txt"
print b1
print b2

will result in this:

C:\>test.py C:\test.txt
C:\test.txt
C: est.txt


-greg

 

[Brian van den Broek]

Fredrik Lundh said unto the world upon 2005-05-12 13:52:

Brian van den Broek wrote:




that's slightly misleading: on the API level, most functions can handle
both kinds of slashes. functions like open(), os.remove(), shutil.copy()
etc. handles either case just fine. and in most cases, this is handled
on the Win API level (or in the C library), not by Python.

however, in this case, the user passes a string to os.system(). that
string is passed *as is* to the command shell (which, in this case,
passes it on to notepad.exe as is).

</F>

Thanks to Fredrik and everyone else who contributed to the thread to
correct my mistake.

Best to all,

Brian vdB

 

[Dennis Lee Bieber]

I think the use of forward slashes for command line switches
was adopted by CP/M from DEC's OSes (e.g. RSX-11). CP/M didn't
have directories in the beginning, so nobody worried about what
to use for path separators (DEC used colons, IIRC). DOS was a

I can't speak for the various PDP-11 family, but VMS syntax was:

hardware:[toplevel.nextlevel.ad.infinitum]filename.ext;version

where hardware could be a drive specification or a logical name (only
other OS I've encountered with logical names is AmigaOS, which also
allowed one to specify disks by volume label -- and would prompt the
user to insert volume X into a drive if needed!)

--

 

[Grant Edwards]

I think the use of forward slashes for command line switches
was adopted by CP/M from DEC's OSes (e.g. RSX-11). CP/M didn't
have directories in the beginning, so nobody worried about what
to use for path separators (DEC used colons, IIRC). DOS was a

I can't speak for the various PDP-11 family, but VMS syntax was:

hardware:[toplevel.nextlevel.ad.infinitum]filename.ext;version

Ah yes, that's looking familiar. The colon separated the
"logical drive" from the path in brackets, in which the
seperator was a dot. I spent most of my time under VMS running
DECShell, so I used mostly 'normal' Unix path syntax.

 

[Roger Upole]

I think the use of forward slashes for command line switches
was adopted by CP/M from DEC's OSes (e.g. RSX-11). CP/M didn't
have directories in the beginning, so nobody worried about what
to use for path separators (DEC used colons, IIRC). DOS was a

I can't speak for the various PDP-11 family, but VMS syntax was:

hardware:[toplevel.nextlevel.ad.infinitum]filename.ext;version

And in a clustered VMS environment, there's also
nodename::hardware:[toplevel.nextlevel.ad.infinitum]filename.ext;version
(somewhat analogous to a UNC path)

Roger