Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Double-click on .py file results in wrong CWD assigned #3499

Open
ToboterXP opened this issue Dec 12, 2024 · 3 comments
Open

Double-click on .py file results in wrong CWD assigned #3499

ToboterXP opened this issue Dec 12, 2024 · 3 comments

Comments

@ToboterXP
Copy link

Distribution

Mint 22 Cinnamon

Package version

6.2.9

Frequency

Always

Bug description

When double-clicking a Python file, it is run with the Home directory as its CWD, regardless of the location of the file. This causes issues when the file is bundled with several other assets

Steps to reproduce

Create a Python file that prints the current working directory, or opens a file relative to itself. Run it.

Expected behavior

The current working directory of a file explorer should be the currently open directory.

Additional information

No response

@Jeremy7701
Copy link
Contributor

A GUI file manager doesn't have a CWD. Perhaps by "file explorer" you are thinking of a Microsoft creation?

You could easily arrange for the file manager to pass the directory as a parameter to a nemo action or script that executes your program.
Or just run your program from the CLI.

@ToboterXP
Copy link
Author

A GUI file manager totally has a CWD though? It's the current working directory. The directory you currently work in, aka have open. So it should be passed to programs you start accordingly. What else would the CWD be set to, reasonably?

@ToboterXP
Copy link
Author

Sure, there's cli workarounds. But the point of having a file manager is kinda that you don't need to use CLI to interact with your files. If it's okay, I can absolutely add this myself, I'm fairly proficient in C. It just seems like a behavior that would be fundamentally expected of a file manager.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants