LSOpenURLsWithRole() failed with error -600 for the URL http://localhost:9000/.
This is the error I get when I try to launch my SimpleHTTPServer while in a tmux session. I'm a front-end web developer and I spend most of my time working with a SimpleHTTPServer, rather than Apache. The issue is that it errors out at the open command, because I have the habit of opening files and directories from the terminal directly (open dirname/, or open .) , and when i use this in tmux it gives me the same error.
I want to mention that I'm on a Macbook Air, running OSX 10.9 Mavericks.
This is the code of the function I use in my terminal to start the server:
# Start an HTTP server from a directory, optionally specifying the port
function server() {
local port="${1:-8000}"
open "http://localhost:${port}/"
# Set the default Content-Type to `text/plain` instead of `application/octet-stream`
# And serve everything as UTF-8 (although not technically correct, this doesn’t break anything for binary files)
python -c $'import SimpleHTTPServer;\nmap = SimpleHTTPServer.SimpleHTTPRequestHandler.extensions_map;\nmap[""] = "text/plain";\nfor key, value in map.items():\n\tmap[key] = value + ";charset=UTF-8";\nSimpleHTTPServer.test();' "$port"
}
Edit
The issue doesn't appear anymore so I have 3 possible solutions for this:
Highly unlikely:
changing from Python3 to Python 2.7.5 (OS X Default)
Most likely:
Apple released an update to Mavericks that fixes this issue
installing Command-Line tools in order to use Homebrew to build & install the latest version of VIM
Not sure if this is the same case for you, since you mentioned you restarted a few times ...
However for me, I noticed that I had stray 2 tmux sessions after an iterm failure, which I had forgotten about. They were running a bunch of services started by grunt, so i'm assuming that one of these services was conflicting when trying to start again. Killing them made the bug not occur anymore and I was able to run my node app in tmux.
Like #Cosmin said, check if there is another tmux running, kill all tmux.
Then open a new tmux, it will work like before.
Related
Wish You all beautiful sunny day! :D,
I have a question for You guys. I have following python "script":
import os
os.system('ubuntu.exe')
Which opens Ubuntu running on my WSL. And now, when the Ubuntu terminal appears:
I would like to execute following commands: sudo /etc/init.d/dbus start and sudo /etc/init.d/xrdp start using my python script (just do them automatically). However, when I run one of the commands above, terminal requests my password:
So the script should be also able to enter the password.
Is there any way, how to do it?
Kind regards,
D.
While the question/answers linked in the comments is a good read (sudoers in particular), there's a better method for WSL. Instead of using ubuntu.exe, use the newer wsl.exe replacement. The wsl command offers more control over the startup, including being able to change the user:
import os
os.system('wsl ~ -u root -e sh -c "nohup service xrdp start"')
os.system('wsl -u root service dbus start')
The nohup is needed because of what seems to be a timing issue. When starting up via the WSL command, the shell (owning process) will terminate before xrdp gets a chance to fork. nohup just makes sure that the full xrdp init script gets a chance to run before that happens. This really isn't a WSL issue, per se. It can also be replicated if you were do something similar with exec sh -c "sudo service xrdp start".
A couple of other notes. First, this does not require a password, since WSL doesn't have the concept of "login." The /init process (WSL's PID1 and initialization) is responsible for setting the owning user for each session. This is not considered a security risk since even the root WSL user runs with no greater than the permissions of the Windows user.
Also note that, in my experience, it's not necessary to start dbus for xrdp access, even though I've seen instructions that say it is. Ultimately it will depend on what you want to run within the xrdp session, of course.
I have a python game that is being run on wl2 and I would like the display to be in windows. I have tried to use the code below in my python program but it just gets stuck because it is not the correct display. I have also checked out this question but it did not seem to be an answer I could apply to this project. I could just run this program in windows but that causes a whole lot of other problems and will probably have to be in another question. Any help would be greatly appreciated!
I wish I could share the program but unfortunately it's for a ctf and should not be posted :(
I used this question for reference to the code below:
import os
os.environ["SDL_VIDEODRIVER"] = "dummy"
Without the above code:
With the above code (seems to be working but nothing shows up):
Audio
You can not redirect audio (ALSA) with WSL2. You could still try something streaming with ffmpeg from linux to windows.
Graphics
Setup an X server on your windows host and provide a DISPLAY environment variable on WSL to it, e.g.
DISPLAY=172.24.144.1:0
On WSL2 localhost or 127.0.0.1 unfortunately does not work, so you have to check your machine adapter addresses on Windows side.
There are plenty of them. I used very simple (and handy) Xming X Server for Windows aka XLaunch.
This one is compatible with opengl X11 drivers.
UPDATE
You can nicely automate setting properly DISPLAY variable by adding this line to the ~/.bashrc file in your WSL2 machine:
export DISPLAY=`grep -oP "(?<=nameserver ).+" /etc/resolv.conf`:0.0
I am new to Python and recently installed Python 3.6 on Windows 10. When I try to open IDLE, Python's IDE, I keep getting a message saying that it can not establish a subprocess. I have tried uninstalling and installing several times. I have seen several forums which say that there could be a .py file that is in the directory that is messing up IDLE. This is not my case, as I have not even been able to start using Python and I do not have a firewall either. Can someone tell me how I can get IDLE to work?
In this answer I collected together 9 possible reasons for the message, as reported in various SO answers.
If you try to start IDLE from a command line (Command Prompt or PowerShell)
> python -m idlelib # idlelib.idle for 2.x
one might get a helpful error message.
I work with over 30 Python developers and without fail when this happens they were behind a proxy / vpn. Turn off your proxy / vpn and it will work. Must have had this happen hundreds of times and this solution always worked.
I have tried uninstalling it and have searched other answers. None of them have worked; IDLE opens, but I can't run anything I write.
In Windows 10
1. Type in "Controlled folder Access"
2. Select "Allow an app through Controlled folder access" Select yes to "UAC"
3. Click on "+ Add an allowed app"
4. Select "recently blocked apps"
5. Find the executable for the C:\Python27
6. Click the + to add it.
7. Select Close
Then try running the Python Shell again. This worked for me 100%
Also, add exception through Windows Firewall Python27 select Private and Public.
This question has been asked before. Based on previous answers, I compiled a list of possible causes and solution on CPython tracker issue 25514, post of 2016-01-18.
SO question 1 Causes people have found or think they have found.
Antivirus/firewall (4 people, linux iptables, Windows firewall, antivisus , so not a myth ;-)
Shadow files, as described [in the issue], and in the python directory (about as common; example user file names: tkinter,py, subprocess.py).
Registry problem (some people can fix, but most should re-install after complete removal).
Zombie pythonw process (kill with Windows Task manager).
Permissions (run as admin, though should not be needed with proper install)
?Multiple installed versions clash due to misconfiguration?
SO question 2 Add:
Running after stopping run with ^C (temporary, I believe Restart Shell will fix) Call this a timing issue. I have experienced temporary connection failures myself.
Modem reboot (rather obsolete answer for most of us).
?example program that reads and writes (test)
Someone somewhere reported that his problem was with network misconfiguration that affected the operation of the socket module that IDLE uses.
Last resort: start IDLE with -n command line option, as described in IDLE doc.
If you at the network environment then check on the secure Group (SG), to see if the user is listed under that group.
else as other had been suggested you have to have the (right click on the program the login as Admin right to enable the IDLE to run.
IDLE's subprocess didn't make a connection. Either IDLE can't start or a personal firewall software is blocking the connection.
Having had this problem myself I did an uninstall and created a new directory in the C drive and reinstalled in that folder, which worked for me.
First uninstall the application.Then reinstall it BUT at the time of reinstallation try -n at the end of location adress. It worked for me, you can copy the below text and paste it at the location while installing it.
“C:\Program Files\Python32\pythonw.exe” lib\idlelib\idle.py -n
I need to run python script and be sure that it will restart after it terminates. I know that there is UNIX solution called supervisord. But unfortunately server where my script has to be run is on Windows. Do you know what tool can be useful?
Thanks
Despite the big fat disclaimer here, you can run Supervisor with Cygwin in Windows; it turns out that Cygwin goes a long way to simulate a Posix environment, so well that in fact supervisord runs unchanged. There is no need to learn a new tool, and you will even save quite a bit of work if you need to deploy a complicated project across multiple platforms.
Here's my recipe:
If you have not done it yet, install Cygwin. During the installation process, select Python.
From the Cygwin terminal, install virtualenv as usual.
Create a virtualenv for supervisord, and then install as usual:
pip install supervisord
Configure supervisord in the usual way. Keep in mind that supervisord will be running with Cygwin, so you better use paths the Cygwin way (C:\myservers\project1 translates to /cygdrive/c/myservers/project1 in Cygwin).
Now you probably want to install supervisord as a service. Here's how I do it:
cygrunsrv --install supervisord --path /home/Administrator/supervisor/venv/bin/python --args "/home/Administrator/supervisor/venv/bin/supervisord -n -c /home/Administrator/supervisor/supervisord.conf"
Go to the Windows service manager and start the service supervisord that you just installed.
Point 5 installs supervisord as a Windows service, so that you can control it (start/stop/restart) from the Windows service manager. But the things that you can do with supervisorctl work as usual, meaning that you can simply deploy your old configuration file.
You likely want to run your script as a Windows Service. To do so you'll need the python-win32 library. This question has a good description of how you go about doing this, as well as a bunch of links to other related resources. This question may also be of use.
A Windows Service is how you want to wrap up any script that needs to run continuously on Windows. They can be configured to automatically start on boot, and handle failures. Nothing is going to stop anyone from killing the process itself, but to handle that potential situation, you can just create a bat file and use the sc command to poll the service to see if it is running and if not restart the service. Just schedule the bat file to run every 60 seconds (or whatever is reasonable for your script to potentially be down).
If you want a supervisord-like process manager that runs on most posix OS and is Python-based like supervisord, then you should look at honcho which is a Python port of foreman (Ruby-based):
http://pypi.python.org/pypi/honcho/
It works great on mac, linux but (actually) not yet windows... (editing my initial answer where I had said optimistically it was already working on Windows based on a pull request that has been discarded since)
There is a fork that provides Windows support here https://github.com/redpie/honcho
and some work in progress to support Windows here https://github.com/nickstenning/honcho/issues/28 ... at least it could become a possible solution in a near future.
There is also a foreman fork to support Windows here: https://github.com/ddollar/foreman-windows that may be working for you, though I never tried it.
So for now, a Windows service might be your best short term option.
supervisor for windows worked for us on python27 - 32 bit. I had to install pypiwin32 and pywin32==223.
As it is an old question with old answers I will update it with latest news:
There is a supervisor-win project that claims to support supervisor on Windows.
No, supervisord is not supported under Windows.
BUT what you can do is, to restart it automatically from a wrapper script:
#!/usr/bin/python
from subprocess import Popen
file_path = " script_to_be_restarted.py"
args_as_str = " --arg1=woop --arg2=woop"
while True:
print("(Re-)Start script %s %s" % (file_path, args_as_str))
p = Popen("python " + file_path + args_as_str, shell=True)
p.wait()