[issue14192] stdout.encoding not set when redirecting windows command line output
New submission from Redoute redo...@tortenboxer.de: When running a python script from windows command line (cmd.exe) and redirecting its output, stdout.encoding is set to None and printing non-ascii chars fails. Encoding should be the same as without redirecting. Example: [Code unictest.py] # -*- coding: utf-8 -*- from sys import stdout, stderr print stderr, 'stdout.encoding: ', stdout.encoding print u'äöüß' [/Code] [windows command prompt] C:\Datentestunic.py stdout.encoding: cp850 äöüß C:\Datentestunic.py testunic.txt stdout.encoding: None Traceback (most recent call last): File C:\Daten\Cmd\testunic.py, line 5, in module print u'├ñ├Â├╝├ƒ' UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-3: ordin al not in range(128) [/windows command prompt] -- components: Windows messages: 154885 nosy: Redoute priority: normal severity: normal status: open title: stdout.encoding not set when redirecting windows command line output type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14192 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14192] stdout.encoding not set when redirecting windows command line output
Martin v. Löwis mar...@v.loewis.de added the comment: That is impossible to implement. When outputting to a terminal window, the terminal's encoding is queried and used. When the Python script is run on its own, there may not even exist a terminal encoding. In any case, this issue is resolved in Python 3 (not by setting the encoding to the terminal's encoding, but to the system code page). For 2.7, changing this would be a new feature, so I'm closing this as resolved - please upgrade to Python 3. -- nosy: +loewis resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14192 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14192] stdout.encoding not set when redirecting windows command line output
Redoute redo...@tortenboxer.de added the comment: Martin, thanks for your response. I have to take it, although I am not really convinced. The system codepage probably differs from the console codepage (here 1152 vs. 850). Print statements on the other hand are typical for console programs. Calling python.exe (vs. pythonw.exe) means console program means print output has to use console codepage as default. It is disappointing that output changes and programs fail because of a command line redirection. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14192 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14192] stdout.encoding not set when redirecting windows command line output
Martin v. Löwis mar...@v.loewis.de added the comment: I have to take it, although I am not really convinced. The system codepage probably differs from the console codepage (here 1152 vs. 850). Print statements on the other hand are typical for console programs. Calling python.exe (vs. pythonw.exe) means console program means print output has to use console codepage as default. I think in practice, this statement is incorrect for most applications. When they use print, they want to create text files, and those will be opened with notepad (or some other text editor on Windows), and will have to be in cp1252. So guessing that it should be cp850 will be incorrect most of the time. In any case, you have perfectly described why the initial design decision in Python 2 was to refuse to guess. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14192 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Strange Behavior on Python 3 Windows Command Line
When I try running any Python Script on the command line with Python 3.2 I get this weird behavior. The cursor dances around the command line window and nothing ever happens. Pressing Ctr+C does nothing. When I close the window (mouse click on X in top right corner), an error dialog appears asking me to force it to close. See a short (26 sec) video of it here: https://vimeo.com/36491748 Also, the printer suddenly starts printing multiple copies of the contents of the command line window - which has wasted much paper. Strangely it was working fine the other day. Then while debugging a script it suddenly started do this and now does this for every script I've run in Python 3.2. Multiple system reboots had no effect. I also have Python 2.5 2.7 installed and they work fine. Even the most basic script results in this behavior: if __name__ == __main__: print(Hello, World!) In an attempt to check the exact version of Python, even this causes the strange behavior: c:\Python32\python.exe -V I'm on Windows XP if that matters. IDLE (which works fine) tells me I'm on Python 3.2.2 Any suggestions? -- http://mail.python.org/mailman/listinfo/python-list
Re: Strange Behavior on Python 3 Windows Command Line
On 13 February 2012 19:50, waylan way...@gmail.com wrote: When I try running any Python Script on the command line with Python 3.2 I get this weird behavior. The cursor dances around the command line window and nothing ever happens. Pressing Ctr+C does nothing. When I close the window (mouse click on X in top right corner), an error dialog appears asking me to force it to close. I'm not a Windows user, so I can't be of assistance but it may help others if you explained how you installed Python 3.2 on your computer. Also have you tried reinstalling it? Strangely it was working fine the other day. Then while debugging a script it suddenly started do this and now does this for every script How were you debugging? -- Arnaud -- http://mail.python.org/mailman/listinfo/python-list
Re: Strange Behavior on Python 3 Windows Command Line
On Mon, Feb 13, 2012 at 3:16 PM, Arnaud Delobelle arno...@gmail.com wrote: Strangely it was working fine the other day. Then while debugging a script it suddenly started do this and now does this for every script How were you debugging? I think I may have been attempting to use pipes to redirect stdin and/or stdout when the problem first presented itself. Unfortunately, once I closed the window, I lost whatever pipe combination I had tried. It just occurred to me that I was unsure if I had been doing that pipe correctly, and that maybe I overwrote python.exe. Sure enough, the modify date on that file indicated I overwrote it. A re-install has resolved the problem. It's just a little embarrassing that I didn't think of that until now, but the fact that everything else seems to work was throwing me off. Of course, everything else was running `pythonw.exe` not `python.exe`. Anyway, thanks for the pointer Arnaud. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- http://mail.python.org/mailman/listinfo/python-list
[issue9126] errors='replace' does not work at Windows command line
John Van Praag j...@jvp247.com added the comment: According to the documentation of the open function: errors is an optional string that specifies how encoding and decoding errors are to be handled–this cannot be used in binary mode. Pass 'strict' to raise a ValueError exception if there is an encoding error (the default of None has the same effect), or pass 'ignore' to ignore errors. (Note that ignoring encoding errors can lead to data loss.) 'replace' causes a replacement marker (such as '?') to be inserted where there is malformed data. If a replacement marker such as '?' were replacing the bad characters, the print function would not have a problem. The open function is not working as described in the documentation. On Wed, 30 Jun 2010 22:29 +, Ezio Melotti rep...@bugs.python.org wrote: Ezio Melotti ezio.melo...@gmail.com added the comment: The problem is not in the reading part, but in the print(). Since the default encoding of your terminal is cp437 and cp437 is not able to encode the bad character (U+2019 RIGHT SINGLE QUOTATION MARK), an error is raised. -- nosy: +ezio.melotti resolution: - invalid stage: - committed/rejected status: open - closed type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9126 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9126 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9126] errors='replace' does not work at Windows command line
R. David Murray rdmur...@bitdance.com added the comment: The characters are fine when you read them (that is, they decode correctly to unicode). They are only invalid when you write them to the windows terminal, which can't handle all the valid characters that are in the file. The Idle output window uses a more capable character set, and can display those characters. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9126 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9126] errors='replace' does not work at Windows command line
New submission from John Van Praag j...@jvp247.com: The declaration errors='replace' works from within IDLE but not at the Windows command line. I am attaching a program and text file that demonstrate the problem. The error shows up at the Windows command line as follows: C:\Users\John\Documents\Python\bug_reports\001python -m read_my_file aaa a aaa a bbb bbb Traceback (most recent call last): File C:\Python31\lib\runpy.py, line 128, in _run_module_as_main __main__, fname, loader, pkg_name) File C:\Python31\lib\runpy.py, line 34, in _run_code exec(code, run_globals) File C:\Users\John\Documents\Python\bug_reports\001\read_my_file.py, line 20, in module readf() File C:\Users\John\Documents\Python\bug_reports\001\read_my_file.py, line 17, in readf print(line) File C:\Python31\lib\encodings\cp437.py, line 19, in encode return codecs.charmap_encode(input,self.errors,encoding_map)[0] UnicodeEncodeError: 'charmap' codec can't encode characters in position 10-11: character maps to undefined NOTE: It appears I can only attach 1 file to this report. So I am copying the program here. The text file to read is attached. ''' read_my_file.py: Reads lines from faulty file. Hangs at line 3 when run from Windows command line. Platforms: Windows Vista Ultimate 64-bit Python 3.1.2 ''' #The file to read. my_file = 'junk.txt' def readf(): #The declaration errors='replace' is suppposed replace characters the reader does not recognize with a dummy character such as a question mark. #This fix works in the interpreter, but not from the Windows command line. fh_read = open(my_file, errors='replace') for line in fh_read: print(line) #Run. readf() -- components: Windows files: junk.txt messages: 108987 nosy: jvanpraag priority: normal severity: normal status: open title: errors='replace' does not work at Windows command line versions: Python 3.1 Added file: http://bugs.python.org/file17816/junk.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9126 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9029] errors='replace' works in IDLE, fails at Windows command line.
John Van Praag j...@jvp247.com added the comment: I just now resubmitted, with a text file and program demonstrating the problem: Issue9126. I am new to submitting Python bug reports and I would like to do it right. I found I could only attach 1 file to the bug report. However, I had two files: The text file to read, and the program doing the reading. Is there some way to attach multiple files to a bug report? If not, what is the customary way to handle submissions where there is a file to be processed, and a program doing the processing? And perhaps other files exhibiting output(s)? Thanks, John On Sat, 19 Jun 2010 12:48 +, R. David Murray rep...@bugs.python.org wrote: R. David Murray rdmur...@bitdance.com added the comment: What you show is not a complete program, nor do you provide the complete traceback or the data causing the problem. The most helpful thing would be a complete small program and data file demonstrating the problem. That said, I'm wondering if your problem is the encoding of the terminal window. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9029 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9029 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9029] errors='replace' works in IDLE, fails at Windows command line.
Changes by Benjamin Peterson benja...@python.org: -- resolution: - duplicate status: open - closed superseder: - errors='replace' does not work at Windows command line ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9029 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9126] errors='replace' does not work at Windows command line
Ezio Melotti ezio.melo...@gmail.com added the comment: The problem is not in the reading part, but in the print(). Since the default encoding of your terminal is cp437 and cp437 is not able to encode the bad character (U+2019 RIGHT SINGLE QUOTATION MARK), an error is raised. -- nosy: +ezio.melotti resolution: - invalid stage: - committed/rejected status: open - closed type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9126 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9029] errors='replace' works in IDLE, fails at Windows command line.
R. David Murray rdmur...@bitdance.com added the comment: What you show is not a complete program, nor do you provide the complete traceback or the data causing the problem. The most helpful thing would be a complete small program and data file demonstrating the problem. That said, I'm wondering if your problem is the encoding of the terminal window. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9029 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9029] errors='replace' works in IDLE, fails at Windows command line.
New submission from John Van Praag j...@jvp247.com: Platforms: Windows Vista Ultimate 64 bit Python v3.1.2 Goal is to read a tab-separated CSV file. Some records have garbage characters in them. The following code fragment works when the program is run in IDLE, but fails when run from the Windows command line. ... fh_read = open(company_info, encoding='utf_8', errors='replace') fh_write = open(quotes_file, 'w') count = 0 try: rdr = csv.reader(fh_read, delimiter='\t') wrt = csv.writer(fh_write, delimiter='\t', quotechar='', lineterminator='\n') for row in rdr: ... Within IDLE the code works with or without the encoding='utf_8' declaration; and it fails with or without the declaration when run from the Windows command line. The error message from the Windows command line is as follows: 'charmap' codec can't encode character '\u2019' in position 207: character maps to undefined -- components: Windows messages: 108130 nosy: jvanpraag priority: normal severity: normal status: open title: errors='replace' works in IDLE, fails at Windows command line. type: behavior versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9029 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Can module tell if running from interpreter vs Windows command line ?
The WConio console module produces different colors, sometimes quite different, when run from Windows command line vs from Python interpreter . A good foregnd/backgnd combination under one may be unreadable under the other : ( I'm using Python 3.0 with the corresponding WConio on XP. Is there any way for the module to detect under which it has been started ?Thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: Can module tell if running from interpreter vs Windows command line ?
On Jul 16, 10:41 am, alex23 wuwe...@gmail.com wrote: It's recommended that you search through the list for similar questions before posting. Of course, it's even MORE important that one actually ensures they're responding to the _same_ question before pointing at an answer... This older post should help: http://groups.google.com/group/comp.lang.python/browse_frm/thread/6c587ba377ae045a/0df10b077f5ee5d4 But the quick answer is to import sys into your program, and do a test on hasattr(sys, 'ps1'), which is only created when running the interactive prompt. -- http://mail.python.org/mailman/listinfo/python-list
Re: Can module tell if running from interpreter vs Windows command line ?
On Jul 16, 10:07 am, pdlem...@earthlink.net wrote: The WConio console module produces different colors, sometimes quite different, when run from Windows command line vs from Python interpreter . A good foregnd/backgnd combination under one may be unreadable under the other : ( I'm using Python 3.0 with the corresponding WConio on XP. Is there any way for the module to detect under which it has been started ? Thanks It's recommended that you search through the list for similar questions before posting. This was covered just yesterday: http://groups.google.com/group/comp.lang.python/browse_frm/thread/fb2f075ccc796b63# -- http://mail.python.org/mailman/listinfo/python-list
Re: Can module tell if running from interpreter vs Windows command line ?
On Wed, 15 Jul 2009 19:07:18 -0500, pdlem...@earthlink.net wrote: The WConio console module produces different colors, sometimes quite different, when run from Windows command line vs from Python interpreter . A good foregnd/backgnd combination under one may be unreadable under the other : ( I'm using Python 3.0 with the corresponding WConio on XP. Is there any way for the module to detect under which it has been started ?Thanks Thanks Alex It worked : import sys hasattr(sys, 'ps1') yields True when started from interpreter and False run from Windows command line Dave WB3DWE -- http://mail.python.org/mailman/listinfo/python-list
Re: Can module tell if running from interpreter vs Windows command line ?
On Jul 16, 10:47 am, alex23 wuwe...@gmail.com wrote: ... This older post should help:http://groups.google.com/group/comp.lang.python/browse_frm/thread/6c5... But the quick answer is to import sys into your program, and do a test on hasattr(sys, 'ps1'), which is only created when running the interactive prompt. As you note there, this will work when running the vanilla shell (ie running it from the command line), but not (potentially) in other interactive environments (IronPython being the example you give). Another instance: there is not sys.ps1 when running a python shell under idle. Since this solution differs whether the interactive session is taking place from the cmd line, idle, IronPython etc. it seems to me not terribly robust. Depending on the use case, it is of course easy to tell whether the module was executed on the command line, or imported (from an interactive shell or another script) using the __name__ trick. (eg. is_imported = __name__ == '__main__') -- http://mail.python.org/mailman/listinfo/python-list
Re: Can module tell if running from interpreter vs Windows command line ?
On Jul 16, 12:56 pm, Asun Friere afri...@yahoo.co.uk wrote:
As you note there, this will work when running the vanilla shell (ie
running it from the command line), but not (potentially) in other
interactive environments (IronPython being the example you give).
Actually, that was IPython, which is an enhanced interactive prompt,
and a totally different beastie altogether :)
Another instance: there is not sys.ps1 when running a python shell
under idle. Since this solution differs whether the interactive
session is taking place from the cmd line, idle, IronPython etc. it
seems to me not terribly robust.
Well, none of {idle, IronPython, IPython} were specified by the OP AND
you're citing back what I myself wrote in the link to which I also
referred the OP - whom has subsequently posted his success with this
technique - so I'm not really sure what the point is here other than
if you have a different use case, you'll need a different
solution...
Depending on the use case, it is of course easy to tell whether the
module was executed on the command line, or imported (from an
interactive shell or another script) using the __name__ trick. (eg.
is_imported = __name__ == '__main__')
That should be:
is_imported = __name__ != '__main__'
And such a test is all well and good if the main code body is the one
that needs to know about the execution mode, but if you need to know
under which conditions the program is being run within a module
imported by the main body, well, that check is _always_ going to be
true...
--
http://mail.python.org/mailman/listinfo/python-list
Re: Can module tell if running from interpreter vs Windows command line ?
On Jul 16, 2:14 pm, alex23 wuwe...@gmail.com wrote: ... AND you're citing back what I myself wrote in the link to which I also referred the OP - whom (sic) has subsequently posted his success with this technique - so I'm not really sure what the point is here other than if you have a different use case, you'll need a different solution... Please don't take offence where none was intended. I know that I was citing you and that I was highlighting the caveat you raised, explicitly so. No criticism of your post was intended nor implied. Moreover the fact that it worked for OP on a single occasion does not speak for its robustness. Depending on the use case, it is of course easy to tell whether the module was executed on the command line, or imported (from an interactive shell or another script) using the __name__ trick. (eg. is_imported = __name__ == '__main__') That should be: is_imported = __name__ != '__main__' Doh! ... Yup I actually used that when I tried it out, my bad. And such a test is all well and good if the main code body is the one that needs to know about the execution mode, but if you need to know under which conditions the program is being run within a module imported by the main body, well, that check is _always_ going to be true... Which is what the paragraph you just quoted says. Hence the attribute is called 'is_imported' rather that 'running_non_interactively'. -- http://mail.python.org/mailman/listinfo/python-list
Re: windows command-line
En Wed, 08 Jul 2009 14:23:54 -0300, Emile van Sebille em...@fenx.com escribió: On 7/8/2009 10:07 AM Lucas Junqueira said... Hi, I'd like to run a simple windows command-line program from within my python script and agt all the returt it generates. Is this possible? How can I do it? Depending on python version, look into subprocess, commands or os.pipe and related. commands is Unix only, and os.pipe by itself doesn't solve the problem - so we are left with subprocess, and that would be my reccomendation too. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
windows command-line
Hi, I'd like to run a simple windows command-line program from within my python script and agt all the returt it generates. Is this possible? How can I do it? Thank you! Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com-- http://mail.python.org/mailman/listinfo/python-list
Re: windows command-line
On 7/8/2009 10:07 AM Lucas Junqueira said... Hi, I'd like to run a simple windows command-line program from within my python script and agt all the returt it generates. Is this possible? How can I do it? Depending on python version, look into subprocess, commands or os.pipe and related. Emile -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows command line not displaying print commands
On Mar 31, 11:42 am, Terry Reedy tjre...@udel.edu wrote: JonathanB wrote: Ok, I'm sure this is really simple, but I cannot for the life of me get any print statements from any of my python scripts to actually print when I call them from the windows command line. What am I doing wrong? hello.py: print Hello World! command line: E:\Python\devpython hello.py E:\Python\dev I'm using Python 2.6.1 I suspect that it opens the window, prints to it, and closes it in a blink of an eye. What window? He's *already* in a Command Prompt window, he's typing a command python hello.py, and getting only a blank line and another prompt. If so, adding an input prompt after the print will stop the window from closing until you respond to the prompt. a = input(hit return to close) tjr -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows command line not displaying print commands
On Mar 31, 9:57 am, JonathanB doulo...@gmail.com wrote: On Mar 30, 6:28 pm, John Machin sjmac...@lexicon.net wrote: On Mar 31, 8:37 am, Irmen de Jong irmen.nos...@xs4all.nl wrote: Does just typing: python Yes, just typing python takes me to my interactive prompt Or do you have a module in your E:\Python\dev directory called 'os', 'sys' or something else that may clobber one of the default library modules. The only module in the directory is called pyfind.py So what do you classify hello.py as? A script? Please tell us what other files are in the directory. or perhaps there's a file named python.bat that does nothing. What directory is Python installed in? What does your Windows PATH look like? Is this your very first attempt to do anything at all with Python or have you managed to get any output from a Python script before? If the latter, what have you changed in your environment? Does E: refer to a removable disk? Unfortunately, this problem is on my work computer, so I'm not in front of it right now. I've done the development on this in PortablePython, but I have python installed in C:/Python25 and that should be in my path (I went though and added it). I've never run a script that output to the command line before, only django apps. Django will output stuff though, which makes me wonder if I've somehow borked my stdout in the script. Not sure how I could have done that, but I'll post the script I've written in the next post just in case I'm somehow messing up the calls (although print var seems fairly user-proof...). E: does refer to a removable disc. If hello.py doesn't print, then the problem is unlikely to be in your big script. I suspect that your best approach would be to (a) ensure that you have the latest release of Portable Python [there was one in the last few days] and (b) ask the author for help. Other things to try that might diagnose where the problem really is: just follow my example below. | C:\junkpython -c print 9876 | 9876 | | C:\junkpython | Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)] on | win32 | Type help, copyright, credits or license for more information. | print hello | hello | print 9876 | 9876 | ^Z | | | C:\junkcopy con test1.py | print 9876 | ^Z | 1 file(s) copied. | | C:\junkpython test1.py | 9876 | | C:\junkcopy con test2.py | 1 / 0 | ^Z | 1 file(s) copied. | | C:\junkpython test2.py | Traceback (most recent call last): | File test2.py, line 1, in module | 1 / 0 | ZeroDivisionError: integer division or modulo by zero | HTH, John -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows command line not displaying print commands
I think I found the problem. I recently removed Python 2.5 and replaced it with 2.6. When I got in, I tried to run some django commands and even they weren't producing output. On a hunch, I tried to uninstall 2.6 and reinstall it, since now even django wasn't producing output. When I tried, it told me that I couldn't because it wasn't installed. I had to delete the folder and manually go through and delete every instance of python in my registry. However, when I reinstalled 2.6, it worked. Some of the registry entries were still pointing to the defunct Python25 path rather than Python26. Now both the simple hello.py script and the bigger script that I really wanted to get working are producing output. I apologize for the confusion caused by going the wrong direction with my troubleshooting (from the simplest possible script to the more complex script), next time I will be more sensible in my troubleshooting. -- http://mail.python.org/mailman/listinfo/python-list
Windows command line not displaying print commands
Ok, I'm sure this is really simple, but I cannot for the life of me get any print statements from any of my python scripts to actually print when I call them from the windows command line. What am I doing wrong? hello.py: print Hello World! command line: E:\Python\devpython hello.py E:\Python\dev I'm using Python 2.6.1 -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows command line not displaying print commands
JonathanB wrote: Ok, I'm sure this is really simple, but I cannot for the life of me get any print statements from any of my python scripts to actually print when I call them from the windows command line. What am I doing wrong? hello.py: print Hello World! command line: E:\Python\devpython hello.py E:\Python\dev Does just typing: python give you an interactive prompt at all? Or do you have a module in your E:\Python\dev directory called 'os', 'sys' or something else that may clobber one of the default library modules. -irmen -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows command line not displaying print commands
On Mar 31, 8:37 am, Irmen de Jong irmen.nos...@xs4all.nl wrote: JonathanB wrote: Ok, I'm sure this is really simple, but I cannot for the life of me get any print statements from any of my python scripts to actually print when I call them from the windows command line. What am I doing wrong? hello.py: print Hello World! command line: E:\Python\devpython hello.py E:\Python\dev Does just typing: python give you an interactive prompt at all? Or do you have a module in your E:\Python\dev directory called 'os', 'sys' or something else that may clobber one of the default library modules. or perhaps there's a file named python.bat that does nothing. What directory is Python installed in? What does your Windows PATH look like? Is this your very first attempt to do anything at all with Python or have you managed to get any output from a Python script before? If the latter, what have you changed in your environment? Does E: refer to a removable disk? -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows command line not displaying print commands
On Mar 30, 6:28 pm, John Machin sjmac...@lexicon.net wrote: On Mar 31, 8:37 am, Irmen de Jong irmen.nos...@xs4all.nl wrote: Does just typing: python Yes, just typing python takes me to my interactive prompt Or do you have a module in your E:\Python\dev directory called 'os', 'sys' or something else that may clobber one of the default library modules. The only module in the directory is called pyfind.py or perhaps there's a file named python.bat that does nothing. What directory is Python installed in? What does your Windows PATH look like? Is this your very first attempt to do anything at all with Python or have you managed to get any output from a Python script before? If the latter, what have you changed in your environment? Does E: refer to a removable disk? Unfortunately, this problem is on my work computer, so I'm not in front of it right now. I've done the development on this in PortablePython, but I have python installed in C:/Python25 and that should be in my path (I went though and added it). I've never run a script that output to the command line before, only django apps. Django will output stuff though, which makes me wonder if I've somehow borked my stdout in the script. Not sure how I could have done that, but I'll post the script I've written in the next post just in case I'm somehow messing up the calls (although print var seems fairly user-proof...). E: does refer to a removable disc. -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows command line not displaying print commands
#This is pyFind, a python replacement for find(1) import os, sys, re, fnmatch from os.path import join from optparse import OptionParser usage = usage: %prog --name filename [directory1 directory2] parser = OptionParser(usage=usage) parser.add_option(--regex, dest=regex, help=REGEX MATCHING DOES NOT WORK AT THIS TIME, ONLY USE THE --name OPTION!!!) parser.add_option(--name, dest=name, help=Unix style pattern matching search for a file by filename.) def set_directories(args, directories): initialize directory list to ensure that all subsequent loops will loop correctly. directories is a created list and args is the positional arguments from OptionParser. if args != []: for arg in args: #We have to use os.splitdrive() to support Windows. Otherwise you cannot search #different drive letters. (drive, tail) = os.path.splitdrive(arg) directories.append([drive, tail]) #For handling the default case, which is to search in current working directory else: directories.append(os.path.splitdrive(os.getcwd())) def regex_matcher(value, names): if value == None: return names else: regex = re.compile(value) return [name for name in names if regex.search(name)] def glob_matcher(value, names): if value == None: return names else: return [name for name in names if fnmatch.fnmatch(name, value)] if __name__ == __main__: (options, args) = parser.parse_args() directories = [] set_directories(args, directories) for directory in directories: #If we are in windows, directory[0] will be True. In that case we must switch #to the root of that drive letter before we can traverse to the requested #directory. if directory[0] == True: os.chdir(directory[0]) #Now that we know we are either in the right drive letter or in a Unix #environment, we can change to the proper directory. os.chdir(directory[1]) for root, dirs, files in os.walk(os.getcwd()): #results = regex_matcher(options.regex, files) #regex = re.compile(options.regex) #results = [name for name in files if regex.search(name)] results = glob_matcher(options.name, files) if results != []: print/n.join(results) -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows command line not displaying print commands
JonathanB wrote: Ok, I'm sure this is really simple, but I cannot for the life of me get any print statements from any of my python scripts to actually print when I call them from the windows command line. What am I doing wrong? hello.py: print Hello World! command line: E:\Python\devpython hello.py E:\Python\dev I'm using Python 2.6.1 I suspect that it opens the window, prints to it, and closes it in a blink of an eye. If so, adding an input prompt after the print will stop the window from closing until you respond to the prompt. a = input(hit return to close) tjr -- http://mail.python.org/mailman/listinfo/python-list
Capture Windows command line output - put in text file
I'm looking for a way to capture command line output from a cmd session. Is there a way to use python to launch the application from the beggining then stream all of the output to a text file ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Capture Windows command line output - put in text file
Ernesto wrote: I'm looking for a way to capture command line output from a cmd session. Is there a way to use python to launch the application from the beggining then stream all of the output to a text file ? Nevermind. This is a telnet question. I'm trying to get telnet localhost output to a text file. -- http://mail.python.org/mailman/listinfo/python-list
Problem: Windows Command line Pipe to stdin
Python 2.3 on Windows XP The following works when run from the command line. import sys text = sys.stdin.read() # do something on the text # ... sys.stdout.write(text) But if the above code is used as a filter program that gets another programs output as shown below, it fails as shown. C:\textGen.py | filter.py Traceback (most recent call last): File C:\filter.py, line 4, in ? text = sys.stdin.read() IOError: [Errno 9] Bad file descriptor Any ideas on what is happening and how to fix it? -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows command line problem
Here's an example...
BEGIN TEST.PY
import sys
print Original:, sys.argv
for arg in sys.argv:
arg = arg.strip('-\x93\x96') # add chars here you want to strip
print Stripped:, arg
END TEST.PY
--
http://mail.python.org/mailman/listinfo/python-list
Re: Windows command line problem
considering that all the command lines are in sys.argv, it's very simple. -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows command line problem
[EMAIL PROTECTED] wrote: I think the lesson there is 'dont depend on getopt, write your own command line parser'. I always write my own, as it's so easy to do. While I'll agree that getopt isn't ideal, I find optparse to be much better. -- Benji York -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows command line problem
[EMAIL PROTECTED] wrote: I think the lesson there is 'dont depend on getopt, write your own command line parser'. I always write my own, as it's so easy to do. I suppose you built your own car so you could get out a bit, too? After all, there's nothing tricky about a simple internal combustion engine, right? ;-) regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows command line problem
I'm using getopt. I doubt getopt recognises \x96 as a command line parameter prefix. I suppose I could iterate over sys.argv doing a replace but that seems messy. I'd rather understand the problem. That said, and me not understanding code pages that much, I chcp'd the machines it works on both coming back with 850, chcp'd the machine it wasn't working on which also came back with 850, but then again the machine where it wasn't working now works. So now it's an intermittent bug. Great. I'll try messing with code pages later and report back if I get anywhere. I need more coffee before I can do anything remotely clever. Damn you windows and your lack of a need for coffee -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows command line problem
This was discovered after consultation with a colleague who shall
remain nameless but, well, nailed it basically.
The answer appears to be:
An example command line for running the script was written in a word
document. The Autocorrect (sic) feature in word replaces a normal
dash at least as I know it with the character Jeff Epler showed above,
u'\N{en dash}' which is a nice big long dash in the Arial font.
If you cut and paste that onto the command line, bad things can happen
although when I do this on my machine I actually get a u with an ^
on top. For whatever reason it must have looked ok on my colleagues
machine (or possibly this isn't the answer but I seriously doubt that)
and when he ran the Python script things went awry.
Thanks Jeff (and nameless colleague). And beware Word autocorrection.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Windows command line problem
MarkE wrote: The answer appears to be: An example command line for running the script was written in a word document. The Autocorrect (sic) feature in word replaces a normal dash There is a lesson there I wish more people would learn: Word is not a text editor. :) -- Benji York -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows command line problem
I think the lesson there is 'dont depend on getopt, write your own command line parser'. I always write my own, as it's so easy to do. -- http://mail.python.org/mailman/listinfo/python-list
Windows command line problem
I'm sure someone else has posted a similar problem but I can't find it, nor the solution... I have a python script which accepts a command line argument. E.g. python.exe myscript.py -n Foo I build this as part of a package using distutils with the bdist_wininst option on a Windows 2K (SP4) machine. I have tested installing and running it fine on a Windows XP (SP2) machine. I build my package-installer with a Python.org 2.4.1 distribution which is source-compiled locally. I have installed my package-installer on a machine running ActiveState Python 2.4.1 installed from a .msi file. That all works fine. I have problems delivering it to the test team (of course). After some investigation, if I install the package on one of our test machines and butcher my installed file to dump the command line and exit (i.e. print 'hi', sys.argv) then I get the following: hi ['c:\\Python24\\Lib\\site-packages\\MyPackage\\myscript.py', '\x96n, 'Foo'] If I run it specifying --name instead of -n I get: hi ['c:\\Python24\\Lib\\site-packages\\MyPackage\\myscript.py', '\x96-name, 'Foo'] The machine in question is also running XP service pack 2 as far as I know, with Python.org's 2.4.1 distribution. Does anyone know why the first character on the command line (here '-') is getting adjusted (to '\x96') in this way ? Is it a Unicode/encodings kind of a problem ? I can make the problem go away by running with quotes like this: python.exe myscript.py -n Foo I'm hoping I can add an entry to my setup.py. Thanks for any and all help. Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows command line problem
does it matter? Have it key off both \x96 and -. -- http://mail.python.org/mailman/listinfo/python-list
