Python error with network drive.

[link]

I have an odd error when I open a Python file that starts with a '#!/usr/bin/python3' on a network mapped drive using sshfs-win:

Code: [Select]

Bad return code from /usr/bin/python3: -2024 See Output window for details.
The output window spams the same line every few seconds (during which time SE is unresponsive):

Code: [Select]

EXEC /usr/bin/python3 --version
I'm using SlickEdit v26.0.3.1 64-bit for Windows.  It stops spamming the error and freezing once I close the file.  If I open the same file copied to the local C: drive, there's no problem.  There's also no problem if the file starts with: '#!/usr/bin/python', but if I change it to e.g. '#!/usr/bin/env python', it starts trying to run /usr/bin/env --version instead.  Very strange.  Any idea what is causing this and how to stop it?

[patrick]

It looks like it's the version check for Python Live errors failing.  It's odd, because it almost looks like it fails only when the current directory is the network directory hosted by sshfs-win.   What happens if you cd to the network directory that holds that python file, and run "/usr/bin/python3 --version" from there?  Do you get any errors or any output?

As a temporary workaround, go to the Options dialog, and go to Languages -> Scripting Languages -> Python -> Live Errors, and change the profile from <Auto Detect> to Pylint3.  That should make it so it doesn't have to do the version checks.

I'll take a closer look at the code for this.  Probably need to make sure to run the "python --version" in a known local directory, to avoid any unecessary network accesses for network drives.

[link]

Setting pylint3 as the default stopped the error from occurring.  Running Since the host is running Windows, I wouldn't expect '/usr/bin/python3 --version' to work from any directory.  FWIW, Python 3.10.5 is installed as python.exe, and it is in the system PATH, but there's no python3.exe.

[patrick]

It should recognize that a *nix path isn't going to work on Windows.   

I'll be putting in a fixes for this in the next hotfix.  It will also fix the bug where it was retrying the command - it's supposed to only try once, but for that particular error branch, it wasn't updating the state for that file.