Launch file in Notepad

Discussion in 'Python' started by George, May 12, 2005.

  1. George

    George Guest

    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
     
    George, May 12, 2005
    #1
    1. Advertising

  2. 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
     
    Brian van den Broek, May 12, 2005
    #2
    1. Advertising

  3. [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.

    --
    Richie Hindle
     
    Richie Hindle, May 12, 2005
    #3
  4. On 2005-05-12, Brian van den Broek <> wrote:

    >> 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".


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

    --
    Grant Edwards grante Yow! Ask me the DIFFERENCE
    at between PHIL SILVERS and
    visi.com ALEXANDER HAIG!!
     
    Grant Edwards, May 12, 2005
    #4
  5. George

    George Guest

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

    >
    >
    > 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
     
    George, May 12, 2005
    #5
  6. On Thu, 12 May 2005 15:41:14 +0200, George <gtog@_no___spam_myrealbox.com> wrote:

    >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.,

    >>> print '-->>%s<<--' % raw_input('Enter text please: > ')

    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):
    >>> print '-->>%s<<--' % input('Enter text please: > ')

    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:
    >>> print '-->>%s<<--' % input('Enter text please: > ')

    Enter text please: > "c:\test.txt"
    -->>c: est.txt<<--
    ^^--there's that tab \t again, unless you escape the backslash

    >>> print '-->>%s<<--' % input('Enter text please: > ')

    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:
    >>> b1="c:\\test.txt"
    >>> print '-->>%s<<--'%b1

    -->>c:\test.txt<<--

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

    -->>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
     
    Bengt Richter, May 12, 2005
    #6
  7. George

    George Guest

    Grant Edwards wrote:
    > On 2005-05-12, Brian van den Broek <> 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, May 12, 2005
    #7
  8. George

    George Guest

    Bengt Richter wrote:
    > On Thu, 12 May 2005 15:41:14 +0200, George <gtog@_no___spam_myrealbox.com> wrote:


    >>(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
     
    George, May 12, 2005
    #8
  9. On Thu, 12 May 2005 14:20:29 -0000, Grant Edwards <> wrote:

    >On 2005-05-12, Brian van den Broek <> wrote:
    >
    >>> 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".

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

    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
     
    Bengt Richter, May 12, 2005
    #9
  10. On 2005-05-12, Bengt Richter <> wrote:

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

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

    --
    Grant Edwards grante Yow! .. If I had heart
    at failure right now,
    visi.com I couldn't be a more
    fortunate man!!
     
    Grant Edwards, May 12, 2005
    #10
  11. On Thu, 12 May 2005 15:14:09 GMT, (Bengt Richter) declaimed
    the following in comp.lang.python:


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

    --
    > ============================================================== <
    > | Wulfraed Dennis Lee Bieber KD6MOG <
    > | Bestiaria Support Staff <
    > ============================================================== <
    > Home Page: <http://www.dm.net/~wulfraed/> <
    > Overflow Page: <http://wlfraed.home.netcom.com/> <
     
    Dennis Lee Bieber, May 12, 2005
    #11
  12. Brian van den Broek wrote:

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


    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>
     
    Fredrik Lundh, May 12, 2005
    #12
  13. On Thu, 12 May 2005 16:30:36 GMT, Dennis Lee Bieber <> wrote:

    >On Thu, 12 May 2005 15:14:09 GMT, (Bengt Richter) declaimed
    >the following in comp.lang.python:
    >
    >
    >>
    >> 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.
    >

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

    Regards,
    Bengt Richter
     
    Bengt Richter, May 12, 2005
    #13
  14. George

    Greg Krohn Guest

    George wrote:
    > 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
     
    Greg Krohn, May 12, 2005
    #14
  15. Fredrik Lundh said unto the world upon 2005-05-12 13:52:
    > Brian van den Broek wrote:
    >
    >
    >>>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.

    >
    >
    > 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
     
    Brian van den Broek, May 12, 2005
    #15
  16. On Thu, 12 May 2005 15:34:39 -0000, Grant Edwards <>
    declaimed the following in comp.lang.python:


    > 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!)

    --
    > ============================================================== <
    > | Wulfraed Dennis Lee Bieber KD6MOG <
    > | Bestiaria Support Staff <
    > ============================================================== <
    > Home Page: <http://www.dm.net/~wulfraed/> <
    > Overflow Page: <http://wlfraed.home.netcom.com/> <
     
    Dennis Lee Bieber, May 13, 2005
    #16
  17. On 2005-05-13, Dennis Lee Bieber <> wrote:

    > On Thu, 12 May 2005 15:34:39 -0000, Grant Edwards <>
    > declaimed the following in comp.lang.python:
    >
    >> 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.

    > 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 grante Yow! Don't hit me!! I'm in
    at the Twilight Zone!!!
    visi.com
     
    Grant Edwards, May 13, 2005
    #17
  18. George

    Roger Upole Guest

    "Dennis Lee Bieber" <> wrote in message
    news:...
    > On Thu, 12 May 2005 15:34:39 -0000, Grant Edwards <>
    > declaimed the following in comp.lang.python:
    >
    >
    >> 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

    --
    This signature was intentionally left blank.
    (except it's not, wtf ??????)





    ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
    ---= East/West-Coast Server Farms - Total Privacy via Encryption =---
     
    Roger Upole, May 13, 2005
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. JDS
    Replies:
    4
    Views:
    8,278
    ForestHonerkamp
    Nov 11, 2008
  2. =?Utf-8?B?Uk4gRGFz?=
    Replies:
    5
    Views:
    8,278
    srajput
    May 23, 2008
  3. Replies:
    0
    Views:
    501
  4. boris
    Replies:
    1
    Views:
    1,839
  5. JDS
    Replies:
    3
    Views:
    195
    gnari
    May 24, 2004
Loading...

Share This Page