Free working directory on Windows.

[melund]

This is a feature request/idea for PTK2.

Problem: On Windows Python locks the current working directory, and prevents other processes from deleting (or renaming) the folder or any parent folders. This behavior is quite annoying especially for shells (IPython or Xonsh). Cmd.exe does the same thing, but PowerShell is smart enough not to do this. (I don't think it is problem on Linux at all).

For Xonsh I made an extension (free_cwd) which temporarily resets the CWD to the users home directory while PTK shows the prompt. It also wraps the callbacks from PTK. Now, open consoles (IPython, xonsh) which are unused will not prevent folders from being renamed or deleted).

It is not really a fool proof implementation. If any other extensions hook PTK, they will not see the true working directory, but instead, the users home directory.

So I thought it would be better to implement such a feature in PTK directly. Would something like this be possible in PTK 2?

[jonathanslenders]

Hi @melund,

Excuse me for the late reply! This is not something of which I think it is prompt_toolkit's responsibility. This looks like a problem that all Python applications have, regardless of whether they use prompt_toolkit or not.

If hope you don't mind I close this issue. (Feel free to open again).

[melund]

Yes. You may be right. It may be even more fundamental than Python. Almost all Windows applications have the problem. I wonder what PowerShell does to prevent it.

That said. Does PTK2 have events (hooks) when entering and exiting idle state (i.e. waiting for user input)? With something like that I could probably make a much better implementation of the free_cwd 'hack' I made for Xonsh.

[jonathanslenders]

There are input hooks, which are used to run another event loop as long as prompt_toolkit is idle. There is an example here: https://github.com/jonathanslenders/python-prompt-toolkit/blob/master/examples/prompts/inputhook.py IPython is using this for integration with all the different event loops. It's basically a replacement for PyOS_InputHook of the Python API (when using readline.)

See also this file: https://github.com/jonathanslenders/python-prompt-toolkit/blob/master/prompt_toolkit/eventloop/inputhook.py

For Xonsh however, I think an alternative is to change the current working directory to / and keep it there, but then keep track of the working directory in a different variable and displaying that. Whenever you start a subprocess, you can pass that directory as the cwd. If the user does cd something, then join the new path and normalize it manually.

[asmeurer]

But xonsh itself is a Python interpreter, meaning if you run import os; print(os.getcwd()) it should print the same directory that you are cded into.

[melund]

But xonsh itself is a Python interpreter, meaning if you run import os; print(os.getcwd()) it should print the same directory that you are cded into.

Yes. We couldn't just keep CWD in shadow variable in xonsh as @asmeurer point out.

That is is no problem with the free_cwd xontrib. It restores the correct cwd every time xonsh resumes the program flow. Only when PTK is idle and waiting at the prompt is the cwd reset to /. The effect is that open terminal hanging around doesn't block folders on windows.

I only want cwd to be reset to / while PTK waits idly for user input.

Is this problem with locking folder only a problem on Windows?

[asmeurer]

What if another thread is doing something that requires the cwd?

[melund]

Yes. That is a problem. And why this is a xontrib :-/ I guess this shows why this can't be more than a hack.

There really ought to be a way to prevent processes on windows from locking directories.