The contents of the file a.py are:
a = input()
print(a)
and fearless.txt contains the string : pink floyd.
Now, when I simply type in %a.py < fearless.txt at the command prompt (windows), it gives an error "lost.stdin".
However, when I type %python a.py < fearless.txt, no error occurs.
I don't understand this, given that .py is a recognized extension and is run by python. Shouldn't then, both be equivalent?
Note I'm using the symbol % in place of the actual directory.
( Python version : 3.4.3:9b73f1c3e601 and winXP-32 bit. )
It depends a bit on how the .py files are registered. It should work when the py.exe launcher is set up correctly. You can verify this by looking up the following key in the registry: HKEY_CLASSES_ROOT\Python.File\shell\open\command. The default value should be "C:\WINDOWS\py.exe" "%1" %*.
You can also try using the following instead:
type fearless.txt | a.py
I just noticed that you are using Windows XP. The problem you are seeing might be because of an old Windows bug with redirection. It was said to be fixed at some point, but maybe XP was still partially affected. I suggest you to update your system anyway because Windows XP is no longer supported by Microsoft.
If this is on a Unix system (as I'm guessing it is), you'll need to have a shebang line at the top of the file to tell the kernel that this is a file whose contents need to be executed by the specified interpreter. The .py extension is just a detail and is not used to decide "how to run" the given program.
When you try to run the file without the shebang, it's being executed by your current shell and that's what's giving you the errors. Python doesn't even come into the picture.
Related
I'm using pandas installed via Anaconda on Windows 10.
I run an IPython terminal inside an emacs inferior Python shell.
Every time I print a pandas.DataFrame to the terminal, I get an error message tput: unknown terminal "emacs".
The error message is then followed by the correct output so I wish I could just turn off the error message.
It seems similar to this question. For what it's worth, I do have Git/bin on my PATH environment variable but I don't know how this would affect anything.
Any advice would be much appreciated.
I ran into a similar problem while manipulating pandas.DataFrame in the debug perspective of Eclipse (Mars 2) under Windows 7.
When trying to examine the content of the DataFrame the console would output :
tput: unknown terminal "emacs"
while the value would display (pending), and the debug session would freeze forever.
I identified that the tput command was indeed a unix command shipped in by cygwing :
D:\smouton>where tput
d:\smouton\cygwin64\bin\tput.exe
The workaround I set up is to modify the PATH variable before launching Eclipse. This is conveniently done by launching the following batch file instead of Eclipse executable :
REM Remove reference to "unixy" stuff before calling eclipse
REM This avoids 'tput: unknown terminal "emacs"' error when manipulating pandas dataframe
SET PATH=%PATH:;C:\MinGW\bin;d:\smouton\cygwin64\bin;=;%
REM launch eclipse
START "" "C:\Program Files (x86)\Eclipse\eclipse.exe"
This file simply removes C:\MinGW\bin and d:\smouton\cygwin64\bin from PATH, then starts eclipse.
I suppose a similar workaround can solve the OP's issue with IPython as well.
The fix that "jurasource" suggested was to inspect the PATH to see if there are any elements of the path that would not be recognized by windows but would instead be recognized by a unix-like operating system. That is why /git/bin would be an issues, that path is recognizable by a unix-like operating system but not windows.
set environment variable TERM=xterm, then restart pycharm's python console can solve this problem.
to do this, first try this in cmd.exe:
tput -T xterm # see if xterm is accepted. if not, try another one.
So this is an unusual one, and perhaps I am simply missing the obvious, but I have the following python code that creates a powershell script and runs it.
# Create the PowerShell file
f = open("getKey.ps1", "w")
f.write('$c = Get-BitlockerVolume -MountPoint C:\n')
f.write('$c.KeyProtector[1].RecoveryPassword | Out-File C:\\Temp\\recovery.key\n')
# Invoke Script
startPS = subprocess.Popen([r'C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe',
'-ExecutionPolicy', 'Unrestricted', './getKey.ps1'], cwd=os.getcwd())
result = startPS.wait()
When this is run, it gives me the following error:
The term 'Get-BitlockerVolume' is not recognized as the name of a cmdlet, function, script file, or operable program.
However, if I then go and manually run the generated script, it works perfectly. To add to the oddity, if I run the same command exactly as above ie:
C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Unrestricted ./getKey.ps1
it also works exactly as expected.
Clearly, the above error is a powershell error, so it is successfully running the script. It almost seems like powershell somehow knows that this is being run from python and has some restricted library of commands when a script is run from a particular source. I grant that that idea makes no real sense, but it's certainly how things appear.
I don't think this is a permissions issue, because when you run the same command from an unelevated powershell prompt, you get an Access is denied type error, rather than a command doesn't exist kind of error.
Anyway, any help would be greatly appreciated!
Edits
Edit: New evidence to help figure this out:
It's definitely an issue of cmdlets being loaded properly. If I programmatically run a script to dump the list of all available commands to a text file, it is only about 2/3's as big as if I do so through a powershell prompt directly
I bet Python is running as a 32-bit process on 64-bit Windows. In this case, you'll end up running 32-bit PowerShell, which in practice is a Bad Thing since many PowerShell modules depend on native binaries that may not have 32-bit equivalents. I hit this with IIS Manager commandlets--the commandlets themselves are registered in 32-bit PowerShell, but the underlying COM objects they rely on are not.
If you need to run 64-bit PowerShell from a 32-bit process, specify the path as %SystemRoot%\SysNative\WindowsPowerShell\v1.0\PowerShell.exe instead of System32.
System32 is actually virtualized for 32-bit processes and refers to the 32-bit binaries in %SystemRoot%\SysWow64. This is why your paths (and PSMODULEPATH) will look the same, but aren't. (SysNative is also a virtualized path that only exists in virtualized 32-bit processes.)
Adding to what #jbsmith said in the comment, also check to make sure that the environment variable that PowerShell relies on to know where it's modules are is populated correctly when python starts the process.
%PSMODULEPATH% is the environment variable in question, and it works the same way the %PATH% variable does, multiple directories separated by ;. Based on what you say your observed behavior is, it seems that you are using PowerShell 3.0, and cmdlet autoloading is in effect.
The solution here: Run a powershell script from python that uses Web-Administration module got me the cmdlet I needed, however there are still missing cmdlets even when using this method. I'm still at a loss as to why some are loaded and others are not, but for the time being, my script does what I need it to and I can't spend any more time to figure it out.
For reference here is the code that worked for me
startPS = subprocess.Popen([r'C:\Windows\sysnative\cmd.exe', '/c', 'powershell',
'-ExecutionPolicy', 'Unrestricted', './getKey.ps1'], cwd=os.getcwd())
I had the same issue, and it was simply that the BitLocker feature was not installed, hence the module wasn't present.
I fixed it by installing the Bitlocker feature:
Windows Server:
Install-WindowsFeature BitLocker -IncludeAllSubFeature -IncludeManagementTools -Restart
Windows Desktop:
Enable-WindowsOptionalFeature -Online -FeatureName BitLocker -All
I have several python scripts which work just fine but one script has (as of this morning) started giving me this error if I try to run it from the bash:
: No such file or directory
I am able to run the 'broken' script by doing python script_name.py and after looking around a bit the general idea that I picked up was that maybe my line ending of the hashbang got changed (silently) so I looked at the line ending of a working script and a broken script via the :set list option in VI as indicated in this question -> View line-endings in a text file
Both files appear to end using the same character (a $) so I am kind of at a loss on how to proceed from here. Specifically, how to actually 'see' the line ending in case the set list was not the right method.
PS: The script is executable and the shebang is in there, I stated that it's just this 1 script that was working fine before the weekend but it started giving me this error as of this morning.
-- edit: --
Running the script through dos2unix does get it working again but I would like to know of any way to visualize the line ending somehow in VI(M) or why Geany somehow converted the line endings in the first place (as I never work on a dos/windows system anyhow).
From the comments above it looks like you have dos line endings, and so the hashbang line is not properly processed.
Line ending style are not shown with :set list in Vim because that option is only used when reading/writing the file. In memory line endings are always that, line-endings. The line ending style used for a file is kept in a Vim per-file option, weirdly called fileformat.
To see/change the line ending style from Vim, you can use the following commands:
:set fileformat
:set ff
It will show dos or unix. You want unix, of course ;-).
To change it quickly you can save the file with:
:w ++ff=unix
Or if you prefer:
:set ff=unix
And then save the file normally.
So see all the gory details just do :help fileformat, :help file-formats and :help fileformats
You can also use the dos2unix command to convert the file format
dos2unix
This helped me to run the python scripts
This normally happens when we open files in windows do changes and save it.
if you open the file locate the ^M characters at the end of every line
Thanks
Personally, I find it kinda wrong using direct path to python interpreter. As you dont use windows platform, you should have program env, usually in /usr/bin (/usr/bin/env). Try using following shebang:
#!/usr/bin/env python
Different distros store python binary in /bin or /usr/bin (or some weird locations), and this one makes your script config-independent (as far as possible, here we have possibility that env is stored elsewhere; still - it is less possible that env is not in /usr/bin than that python is mislocated).
I had similiar problem (if not exactly the same) and that worked for me.
Also, I have both python interpreters (2.7.x and 3.x) installed, so I need to use "python3" argument for env. AFAIR usually distros link different names to different binaries, so "env python" will run python2.7 on my system, "env python3" (also python33, or smth like that) will run p3k, and "env python2" (also python27, etc) will run python 2.7.x. Declaring which version of interpreter should be used seems like a good idea too.
I came across this problem editing my code on Windows, checking it in with git, and checking out and running it on Linux.
My solution was: tell git to Do The Right Thing. I issued this command on the Windows box:
git config --global core.autocrlf true
Modified the files and checked them in; voila, no such problem any more.
As discussed on the Git documentation.
I would like to add a breakpoint to a pydev project. I am using eclipse with the pydev plugin. I am running Windows 7. The file I want to debug is located at C:\cygwin\workspace\project\main.py .
When I attempt to add the breakpoint by double-clicking to the left of the line on which I want the breakpoint, the breakpoint appears to be visually present in the file, but then I get this error when I click debug:
pydev debugger: warning: trying to add breakpoint to file that does not exist: /workspace/project/C:\cygwin\workspace\project\main.py
Note that the file still appears to run fine both in debug and normal run modes. I can also run the file outside the ide by running python main.py.
I was actually able to get this working. I realize I'm using PyCharm, but the solution should be easily adapted since they both use PyDev. The basic problem is that the IDE is expecting windows paths while PyDev is expecting cygwin paths. I found the appropriate places in PyDev to do those conversions.
Here's my setup
configure your project to use a python for cygwin binary (this may not be necessary)
edit Program Files/JetBrains/PyCharm 2.5/helpers/pydev/pydevd.py. This converts the paths sent to the debugger to cygwin paths. Around line 597, where file = NormFileToServer(file) is located, make the following changes
orig_file = file
file = NormFileToServer(file)
if not os.path.exists(file):
file = orig_file.replace('c:/cygwin','')
file = file.replace('\\','/')
file = file.replace(' ','\ ')
file = NormFileToServer(file)
if not os.path.exists(file):
sys.stderr.write('pydev debugger: warning: trying to add breakpoint'\
' to file that does not exist: %s (will have no effect)\n' % (file,))
sys.stderr.flush()
do the same filename conversion a few lines later under the elif cmd_id == CMD_REMOVE_BREAK statement
edit Program Files/JetBrains/PyCharm 2.5/helpers/pydev/pydevd_comm.py. This converts paths sent back to pycharm into windows paths. Around line 549 alter the code to look like this:
myFile = pydevd_file_utils.NormFileToClient(curFrame.f_code.co_filename)
myFile = "C:\cygwin" + myFile
myFile = myFile.replace('/','\\')
Adjust the paths as needed. The big thing that helped me figure this out was to add PYCHARM_DEBUG=True in the environment variables of the PyCharm run/debug configurations.
Hope this saves someone else the 6 hours I spent figuring this out!
Cygwin is not really properly supported in PyDev, thus, you either must work on windows using a python windows distribution or you must work on Linux using a python for linux...
The real issue is that the paths must be translated back and forth at each step when inside cygwin (to make the communication with the IDE)... some initial work has been done on that front, but it didn't go forward...
One approach I didn't really attempt but which could work could be trying to use all within cygwin (i.e.: use PyDev running inside cygwin too: the linux version of java/eclipse/pydev -- not only the python interpreter, that way both would see paths in the same way), but I haven't really tested that setup, so, I'm not 100% certain it'll work.
pydev debugger: warning: trying to add breakpoint to file that does not exist: /vagrant/pytest/C:\Program Files\Git\vagrant\vagrant\pytest\remote.py (will have no effect)
The above error is keeping on occuring to me. I am using eclipse with pydev installed.
INitiualy I configured the PATHS_FROM_ECLIPSE_TO_PYTHON value wrongly but then updated it. But the updated value is not reflecting in the above error but shows old value only.
How to flush the old configurtion PATHS_FROM_ECLIPSE_TO_PYTHON and make the latest value used when executing the file
I have created a little pre-commit hook in python. This hook works like a charm under Linux, but in Windows it keeps telling me:
error: cannot spawn .git/hooks/pre-commit: No such file or directory
I know there have been similar questions here about the same issue and the conclusion seams to be the shebang. My script has this on the very first line:
#!F:\PortableApps\PortablePython3.2\App\python.exe
It's also interesting to note that executing the script simply by writing .git/hooks/pre-commit works wonderful, but as soon as I try to commit, git spits out the above message.
Another interesting thing is, when I convert the encoding from ANSI to UTF-8 (using Notepad++), I get the following error when trying to execute the script:
.git/hooks/pre-commit: Cannot execute binary file
I'm using the following tools:
PortablePython 3.2.1.1
msysgit 1.7.6 (Portable)
I used the proxy-approach to make the python script work under windows (with msysgit). The complete script (with description on how I did it) might be found here: https://gist.github.com/1839424
Here is the important part about making it work under Windows
If you're working with Windows (and "msysgit"), it's a little more complicated. Since "msysgit" seems to have a problem handling the SHEBANG, you'll have to use a little trick to make the script executable (further information on this problem can be found here).
In order to make the script work, you'll want to remove the SHEBANG from the Python script ("pre-commit.py") and use a wrapper bash-script to call the interpreter. This script should look something like this:
#!/bin/sh
python .git/hooks/pre-commit.py
Store this script as a file called "pre-commit" (no file-ending). This assumes that you have Python in your PATH. If you don't, you can also specify the full path to your interpreter-executable.
This script will be called by "git commit" and call the python-script to check for the huge files. The path after the SHEBANG should not be changed, as "msysgit" will remap it automatically. You must specify a path relative to the repo-root for the Python script to be executed (because thats from where the script is called).
Afterwards you'll want to copy both the wrapper-file ("pre-commit") and the Python-script ("pre-commit.py") to your repos ".git/hooks"-directory, personalize the Python-script ("max_file_size" and "git_binary_path") and mark the "pre-commit"-file executable.