As you know, most platform servers run on Linux or MAC OS.
But there are still cases where windowSU is used as a server. So HERE I put together a note on how to move the Django platform from MAC to Windows.
First of all, we should be familiar with the common DOS commands of Windows.
That is, a shell command on a benchmarked MAC/Linux.
[Note that all screenshots in this section are original and measured, not copied and pasted.]
1. Check all the running ports: netstat -ano press enter we need to confirm that the common ports are not in use such as 80 or 8000 8080 etc, so that we can control the process kill etc
2. Check the specified port: netstat – ano | findstr searches “8000”
And that’s the last pid column.
3. Check the specified pid process: tasklist | findstr searches “11776”
You can clearly see that it is a Python process.
Can also according to the process command to query the pid you just need to transform the back of the string: tasklist | findstr searches “python”
4. Kill processes: taskkill /T /F /PID 11776
5. Go to CD
6. Switch drive letter: drive letter:
7. View the content in the directory dir
Wmic process where Caption =”python.exe” get processid,commandline
Note that ProcessId is what we call PID, but the full command name must be entered in the keyword, such as python.exe
Then check the complete content according to the process PID:
wmic process where ProcessId=”10848″ get processid,commandline
This means that when we use Python to manipulate Windows commands, we can execute this command directly to obtain process details for control without the help of a powerful third-party library.
Okay, now, let’s move on to part two
Some of python’s built-in libraries and differences for controlling OS commands
In the test platform we did, it was inevitable to greet system commands. Controlling a process, executing a script, etc.
At this point, I usually have two thoughts.
One is to use Python’s built-in process library subprocess to interact with the system shell.
The second is to use some third-party library to control, such as Psutil.
So what’s the difference? Obviously, third-party libraries are easier to encapsulate and built-in libraries are more flexible.
It’s been true since ancient times that encapsulation means less process and less flexibility.
If you choose the built-in library, then we need to learn the above shell commands for different systems, such as Windows DOS commands.
Choosing a third-party library can save you a lot of trouble.
Here’s a taste of how I started a Python process using two libraries.
The script to launch is simple, just a loop of output numbers:
subproess :
Note that call is blocked, meaning that the process causes the main process to never terminate. Popen is non-blocking, meaning that the main process starts and returns immediately without waiting for the child process to finish. I’m going to show you that with blocking.
After execution, the console has been stably output ttt.py output.
If we go to the console, we can see the subprocess command.
You can see two Python processes, with the main at the top and children at the bottom.
Then I’m using another way, the third-party Pustil library, to start the child process.
The process is as follows:
The two are used similarly to start a process, but are vastly different in how we manage the process.
The former library requires us to execute the check command ourselves, get the output and extract the regular, and then kill the process. Not only is this cumbersome, but shell commands are completely different on different systems.
Psutil is normally used to control processes because it encapsulates multiple methods that are secure and reliable.
But? If we use these packages well, we will often be asked the underlying principle in the interview, and our partners will also be very headache, so we should develop a good habit of learning, that is, we should learn both old and new technologies, and follow the healthy growth way, learn the old ones at the bottom first, and then learn the new ones. We can do away with old technology, but we can’t do away with it. This is also one of the reasons why my training content is JS first, JQ last, VUE.
Let’s finally look at two ways to kill a Windows process. **
Let’s take a look at the first way, through the traditional DOS command to kill. 】
Create a non-blocking process with subprocess, then find the PID and kill it.
Check the pid with check_output and then kill it with the taskkill command. But it looks like a lot of trouble.
Ok, then we use the second way, the built-in psutil library for control.
For the same process, look at the code:
As you can see, the script is much simpler, and much safer, and less likely to cause crashes caused by bugs or liu Chen phenomena (which refer to strange problems that we can’t understand at the current level of technology and cost, or code paranormal phenomena that happen in front of us).
Well, that’s the end of this lesson. Welcome to enjoy the series.
[Measurement series] is the blogger spent a lot of energy to sort out things that can be used as notes, reliable and rigorous. Please save it as a bookmark
Do you know how to transfer the test platform made by the teacher with MAC to Windows?
This article uses the article synchronization assistant to synchronize