Fcntl Substitute on Windows

fcntl substitute on Windows

The substitute of fcntl on windows are win32api calls. The usage is completely different. It is not some switch you can just flip.

In other words, porting a fcntl-heavy-user module to windows is not trivial. It requires you to analyze what exactly each fcntl call does and then find the equivalent win32api code, if any.

There's also the possibility that some code using fcntl has no windows equivalent, which would require you to change the module api and maybe the structure/paradigm of the program using the module you're porting.

If you provide more details about the fcntl calls people can find windows equivalents.

how to import within windows fcntl module

The substitute of fcntl on windows are win32api calls. The usage is completely different.

Changing mp4ize.py to work on Windows

This command sets the NONBLOCK option of the standard error file descriptor. This lets it pass data through before the entirety of the data has been written to it.

The patch at http://pastebin.com/Zr5LN8Ui will work, with progress indicators, on Windows. However, it will sometimes report a bad encode even when the encode was good.

It uses the solution from Non-blocking read on a subprocess.PIPE in python to allow non blocking IO, and fixes the pad option (your version didn't work for my test file) and progress bar for a modern FFMpeg.

Note that it is hardcoded to use the linked method when FFMpeg gets passed 3 or more command line options, as it messes up the first call to FFMpeg which gets the resolution of the input file.

No module named fcntl

I think by far your easiest solution would be to switch to CPython. I don't think it would be any less integrated than your existing solution and you'd avoid all the headaches with missing modules.

How do you I add a module into my PYTHONPATH?

First, this is probably not going to work for you.

You can't turn Windows to Linux just by adding modules to your Python library. The reason you don't have the fcntl module on your path is that fcntl isn't included on Windows. And the reason it isn't included on Windows is that the Windows OS doesn't support the syscalls that module wraps, or anything close enough to reasonably emulate those syscalls.

If you have code that requires fcntl, that code cannot run on Windows (unless you do some significant work to port it to not require fcntl in the first place).

If you have code that doesn't require fcntl but uses it anyway, or if you just need something for temporary development purposes so you can catch and fix file sharing errors while porting the code to not require fcntl, then you can use msoliman's dummy code, which I'll explain how to do below. But you seem to be expecting it to do magic, and it won't do that.

You may not be sure. Maybe you're using code that uses other code that uses other code that uses fcntl in some scenarios but not others, it may not actually need fcntl to do any of the things you're actually trying to do with it.

If you want to test that, you can take msoliman's dummy code, and change each function body to this:

raise RuntimeError('Oops, using fcntl!')

Then run the program and see if it fails with that error. If not, you don't actually need fcntl after all. (Or at least you don't need it for any of the things you tested—it's always possible that some other thing you need to do with the app that you didn't think to test will need it.)

If your code actually needs fcntl, and you don't want to/can't port that code to Windows code that uses Win32 API calls (or a cross-platform library like portalocker), then what you probably need to do is install Linux and run the program there.

There are multiple ways to run Linux on top of Windows, rather than instead of Windows. For example, you could install Docker for Windows and then build a linux docker container with the app. Or you could use VMWare Player to, in effect, run a Linux image as an application under Windows, and then do your work inside that image. And so on.

Finally, msoliman's "Place this module in your PYTHONPATH" is a little misleading.

What you actually need to do is get it into your sys.path. PYTHONPATH is just one way of doing that, and probably not the one you want here.

The options are:

Just put it in the same directory as your script. As the docs say, "As initialized upon program startup, the first item of this list, path[0], is the directory containing the script that was used to invoke the Python interpreter."
Put it in your user or system site packages, or some other directory that's already on your default sys.path. You can import sys; print(sys.path) to get a list of these directories. If you see something inside your home directory, that's a good place to put it; if not, look for something with site-packages in the name.
Put it in some other directory somewhere else, and set the PYTHONPATH environment variable to be the full path to directory. You can set an environment variable in the Windows cmd command prompt by writing SET PYTHONPATH C:\Path\To\Directory. This will only persist as long as the current command prompt window. If you want to set it permanently, there's a setting somewhere in Control Panel (it changes with each Windows version; Super User should have good up-to-date answers for each version) where you can set System and User environment variables. Any User environment variable will take effect in every new command prompt window you open from now on.

Fcntl Substitute on Windows