Since the windows 10 creator update, you can enable developer mode to circumvent administrator privileges when creating a symlink. Now, I was able to create a symlink using mklink like this:
os.system('mklink %s %s' %(dst, src))
Hopefully it's obvious that dst is the destination symlink path, and src is the source file for the symlink. While it seems to work ok, it doesn't error if it fails which makes it a little more difficult to ensure each symlink is successful. I can check if the path exists after each symlink, but that's less efficient than a try/except clause. There's also what looks like a command shell window(?) that pops up and closes quickly every time - and that's really annoying when you're symlinking a lot of files...
So, I've been trying other options I've found on stack overflow like this one: How to create symlinks in windows using Python? Unfortunately, the CreateSymbolicLinkW command doesn't seem to work for me... I also found this: OS.symlink support in windows where it appears you need to adjust the group policy editor; however, it apparently still requires users in the administrator group to run the process as an administrator even if you explicitly set that user with symlink privileges.
With the windows 10 creator update, there's mention of a new dwflag in the CreateSymbolicLink api (SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE) you can see the reference for that here: symlinks windows 10
Using the ctypes stuff is a bit over my head, so I'm wondering if anyone knows: Can I actually use that new dwflag? How do I use it? Will it work without running the process as administrator?
I use Autodesk Maya, so I'm stuck with python 2.7 options... I have not tried launching Maya as an administrator so I don't know if that will work, but it seems like a rather annoying hoop to jump through even if it does... I appreciate any assistance you can give
it doesn't error if it fails
os.system will return the exit status of the call. It does not raise an exception.
If you look at the docs for os.system, they recommend using the subprocess module. In fact, subprocess.check_call does what you describe (raise an exception on a non-zero exit status). Perhaps that would work better.
On the other hand, the command mklink will return a zero exit status even if the source does not exist (it will create a link to non-existent file and return 0). You might want to validate the actual link as you mentioned, depending on what errors you are trying to find.
As far as hiding the console window, see this.
os.symlink works out of the box since python 3.8 on windows, as long as Developer Mode is turned on.
Not sure whether this will help with Maya; they seem to have committed to Python 3 though.
Related
I have a bunch of python script that run on a scheduled basis in a windows 10 based system, sometimes after windows 10 automatic update, the OS will ask for a restart to finish the update and after some time it would restart automatically if not done manually which might mess with automated python script runs.
I am looking for a pythonic solution where I would query the OS if it needs a restart and upon getting the appropriate response I would trigger the appropriate solution
import necessary_libraries
isRestartRequired = check_if_restart_is_needed() // returns true or false
if isRestartRequired == True:
notifyUser()
Is this programmatically possible with python?
The following seems to work for me:
Install the PowerShell script Reboot pending:
Install-Module -Name PendingReboot
Check it works in Powershell:
Test-Pending Reboot
Call it from python using:
import subprocess
def restart_needed()->bool:
"""Uses Windows Powershell tool to figure out if a windows
reboot is pending. True indicates one is due."""
cmd:list[str]=["powershell","-Command","Test-PendingReboot"]
res:bytes=subprocess.run(cmd,capture_output=True)
output_text:str=res.stdout.decode("utf-8").strip()
restart:bool=output_text.endswith("True")
return restart
I personally don't think there is a dedicated library for that. I also don't think you should check that for updates individually, as that will likely require searching for the information about each and every update online (https://learn.microsoft.com/en-us/answers/questions/308547/how-to-know-if-a-windows-update-will-require-a-reb.html).
So you'll likely have to figure out a way how to determine whether Windows is going to reboot or not, and then manually perform that check (by running a system command or utility) in Python. Now your question sounds more like "Which mechanisms Windows use to reboot the machine during the update, and how to check whether any of them is invoked". Please note that there might be a bunch of such mechanisms, and they are most probably undocumented and may change in future. You can learn the basics on MS website, but they don't provide good amount of details there (https://learn.microsoft.com/en-us/windows/deployment/update/how-windows-update-works).
You can check the list of possible reboot status locations in How can I check for a pending reboot? (it looks quite promising), and implement these checks in Python afterwards using some function that allows you to check the output (Running shell command and capturing the output).
If you decide to use that approach, please capture a PC that requires a reboot and verify that one of the 4 sources mentioned in the answer indeed contains the reboot flag. I did it for my laptop yesterday - it was pending reboot, and some entries indeed contained that marker. Make sure you check that for your infrastructure as well.
P.S. If you have full control upon your entire infrastructure, you might look into PowerShell Gallery PendingReboot module mentioned in the referenced SO post (if it's installed on the machine, you can use just one command instead of four), or make yourself familiar with brilliant (and completely useless probably) opinion of MSDN guy https://devblogs.microsoft.com/oldnewthing/20151203-00/?p=92261 : In this specific case, the idea would be to change the design from “Install the update, and then postpone the reboot until a convenient time” to “Wait for a convenient time, then install the update and reboot immediately.”
So yeah, this isn't a question as such. Apologies if Stack has a better place for this kind of post. I just figured I might save some people a bit of future head scratching.
I was running Windows 10. Installed Geany with the standard 'geany-1.36_setup.exe' file for windows.
Opened a new file, 'test.py'. Typed in:
print('test')
(It's no 'hello world', but hey, I fancied a change.)
And I got the dreaded 'cannot execute' error:
09:05:16: Cannot execute build command "-e /bin/sh "C:\Program Files (x86)\Geany\libexec\geany\geany-run-helper" "C:\Users\donenmax\Desktop\python" 0 python "test.py"": The system cannot find the file specified. Check the Terminal setting in Preferences
So I did what any beginner would do: I googled.
Naturally, I started off searching for what to put in the Terminal Setting of preferences. Everyone seemed to have a different answer. What doesn't help is that:
1)A lot of people don't use the default terminal for various reasons, so their guidance won't work without a lot of mods. (To be fair, the default terminal ain't the best for certain work).
2)The default terminal setting, 'x-term-emulator' appears, from what my little brain can figure out, to be a linux command. Maybe other people have got it to work on Windows, I dunno. But the closest answers I got to changing this to something Windows could understand were along the lines of 'oh, you'll need cmd.exe, but I've no idea what switches you will need.'
Sorry, beginner here...what the heck is a switch?
Well, it turns out that the '-e /bin/sh' entry that follows the 'x-term-emulator' text is, guess what, a linux command (or not something Windows understands, anyhow.)
Note: the '%c' command that follows 'sh' should not be removed, as this is substituted with the run script name. Basically, %c tells Geany what script to execute.
So then, going into 'Preferences' and accessing the 'Terminal' setting, I replaced
x-terminal-emulator -e /bin/sh %c
with
cmd.exe /Q /C %c
That got me as far as a blank terminal. Wooo! So, how to actually get anything to be executed?
More googling.
You have to go into the 'Build' tab, then select 'Set Build Commands'.
You will (or should) find something like:
C:\Users\AppData\Local\Programs\Python\Python38-32\
python "%f"
You'll need to replace 'python' with wherever python.exe is stored on your machine. Just type 'python.exe' into the Windows search bar, then right click 'open file location'.
In my case, I replaced 'python "%f" with:
C:\Users\AppData\Local\Programs\Python\Python38-32\python
Boom! My terminal now works fine.
Apologies for making this a rather long post, but this was the result of about an hour's brow furrowing that is most likely shared with beginners in similar situations. Hopefully this will help some of you windows users out there. A lot of programming guidance I've come across seems to assume pretty hefty background knowledge :)
I'm receiving the message:
The program can't start because python34.dll is missing from your computer. Try reinstalling the program to fix this problem.
I want to use python27, so I uninstalled python34, but can't get the cmd prompt to redirect to the python27 .dlls.
In the prompt I typed setx PATH "c:\python27" and it says successful. I close out of the prompt, open it again, type Python, and I get the same message.
Here is a screenshots of the error:
And a screenshot of the response to the setx command:
How can I fix this?
I would suggest you manually edit your PATH (through Windows' GUI instead of CMD) and ensure two things:
a) That C:\python27 is in there and
b) That C:\python34 is not in there
Also, after doing that, make sure you close all open cmd.exe dialogs before opening a new one and testing again.
CMD is a bit weird in my experience, it seems like as long as one instance of it is running, Windows won't propagate environment variable changes to any instances of it (even new ones created after the change). I wasted a lot of time in the past troubleshooting issues similar to yours until I figured that out, so I think it's worth mentioning here.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I have installed Python 2.7 (Windwos 7). However, I am unable to load the GUI. I get no response when I try to open. I re-installed it but again the same problem. What might be the solution?
If you have python in the default installation path, try in the windows shell:
C:\Python27\pythonw C:\Python27\Lib\idlelib\idle.pyw
or change the path accordingly. This should work even if you have other conflicting pythons in your installation or paths are not set.
If idle comes, best solution is to modify idle.bat (in idlelib
folder) with the above explicit paths and create a desktop direct access to that new .bat.
If idle doesn't come, try
starting idle as administrator
starting idle after shutting down windows firewall
There can be lot of reasons and its difficult to diagnosis and recommend a solution without looking into the actual system and process. If you are really interested to resolve this I can suggest how you can debug these issues.
Download Process Monitor
Bring up process Monitor and filter all process except pythonw. PythonW is the process that runs when you start IDLE.
Now Start Monitoring in Process Monitor.
Bring up IDLE and wait until Process Monitor's Log becomes stable.
Now study the LOG to see what might have gone wrong.
If you need more help, just post the log here and we can try to see what is wrong with your system.
Just to simulate your problem, I renamed my idle.pyw so idle_1.pyw and tried to bring up IDLE. It failed without any message. I then brought up process Monitor, and filtered the pythonw process and tried to bring up IDLE again. I found a message in the log which was in coherence with the problem.
As you can see, I have highlighted the error which shows what the error yes. Try the process explorer and this would surely nail down the problem if nothing works for you :-)
Remember, just search for ThreadExit in the log, the Error should be just above the Operation. In case its difficult for your to figure out the problem, just post the screan shot near the ThreadExit, and we can help you out.
Update from the Image Provided
As you can see in the log, the FSECURE.DLL closed the thread abruptly. FSECURE (Antivirus/Firewall) didn't think this process to have legitimate rights to do some operation. If you need to know more details as to what operation was blocked you would get from Fsecure Log. In most cases as you have experienced, running as an Administrator would help the process gain the right to not being blocked by Fsecure.
I have no expericne with Fsecure, but most antivirus have a Whitelist entry where if you add a process would prevent it from blocking it.
I had the same problem after installing python 3.3.2 on my Windows 7 Professional x64.
During the setup I had to provide administrator privileges due to turned on UAC. Ever after when trying to start the IDLE nothing would happen - unless I started it as an administrator.
I checked the setup but couldn't make out an option for a non-admin install as described in http://bit.ly/15WBouF.
Inspired by the comment of Joaquin from above I deleted the entire folder named .idlerc located at my user directory. Et voila - IDLE runs as a charm!
Althought the root of the problem is still unknown to me this solved my issue.
I had similar problem, IDLE would stay silent and crash after couple more tries.
Then I tried to run the code from command line: >>python program.py
the command line said that I had problem with global variables. You have to declare a variable global in the beginning ot everyfunction before reaching it:
var1
def func():
global var1
...code..
##end of func()
IDLE would not show that problem. It's a handy tool, but sometimes leaves you speechless.
In keeping with simplicity, may I suggest removing Python 2.7, and download the stable version without known IDLE issues. That'd be Python 3.3.3. Click here --> Python 3.3.3 Python 3.4.1. is problematic.
Please select 'Start' > 'Computer' > Right Click on 'Computer' > Select 'Properties'.
Select 'Environmental Variables'.
Select 'New' or 'Edit' Variables. Path of the python.exe. C:\Python33.
Either Edit or input new Variables with naming conventions. This should remedy any issues with IDLE. However, regarding the GUI - may I suggest the following: 5) In the Command Prompt, type: cd C:\Python33. This should take care of it. Hope this helps.
I use IPython very frequently and happily. Somehow, cutting text from the shell using the keyboard shortcut, Ctrl + X, is broken. Actually, I have a few different installations of IPython. In some of the installations, the shortcut works; in the others, it doesn't work.
What might be the reason for this? Where should I look into?
You say you have multiple instances installed -- are these all on different machines? What operating system(s) are they running? If you access them remotely, what operating system are you running?
Do you get to them using ssh? Do you run something like screen, either locally or remotely, or both? There are lots of things that can interfere with your terminal settings, especially when you're working remotely.
I'm almost certain that iPython doesn't have anything to do with it -- though you might want to check the version numbers, to see if working and non-working environments are running different versions.
More likely, it is something in the terminal emulation layer, but you'll likely have to do some detective work of your own to find out what piece is causing it.
Take it one step at a time -- try to cut from a local shell, to make sure that works. Then connect to a remote machine, and cut from that shell. Start screen, if that's your normal way of doing things, and test from that shell. Then start ipython. If it stops there, then see if you can find another application on the same machine that's linked against gnu readline, and try that. You may find that none of the console apps cut proplerly on that machine, or you may find that they work, but not under screen. Or you may find that something in the terminal settings stops everything from working as soon as you ssh in.
You may also have some luck. if you can find out what terminal the remote machine thinks you are using ( echo $TERM ) by copying the termcap file from a working machine to one that doesn't. That's a bit more involved for these forums, though -- I'd repost at that point on serverfault.com or superuser.com
I hope that at least gives you a starting place -- terminals are finicky, and difficult to get right. Most people seem to not bother, as long as everything mostly works.