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

Error when using interactive mode in windows: '...\Programs\Microsoft' is not recognized as an internal or external command, ... #430

Closed
saltball opened this issue Mar 28, 2021 · 7 comments · Fixed by #431
Labels
bug Something isn't working
Milestone

Comments

@saltball
Copy link

Description of your problem

It happens when i use the interactive mode. I got error message as below:

'C:\Users\***\AppData\Local\Programs\Microsoft' is not recognized as an internal or external command,
operable program or batch file.
ERROR:

(I omit my account info using ***.)
Same error happens on both powershell and cmd.
Please provide a minimal, self-contained, and reproducible example.
I try to locate the error, so i make a py script. It's part of the open file with editor. I got a familiar error.

from pyscaffold.shell import *
from pyscaffold import file_system

with file_system.tmpfile(prefix="pyscaffold-", suffix=".args.sh") as file:
    content = edit(file).read_text("utf-8")

It seems the space in vscode path ruin the function get_executable() in shell.py.

Please provide any additional information below.
I'm not sure whether it's my computer's problem. But when i change line 157 in shell.py from

        return executable

to

        return name

There is no error.

And I wonder if the function get_excutable() could deal with any space in path of env, editor or any other commands.

Versions and main components

  • PyScaffold Version: 4.0.1
  • Python Version: not specified
  • Operating system: Win10
  • How did you install PyScaffold: conda
@abravalheri
Copy link
Collaborator

Hi @saltball thank you very much for reporting this... I have been investigating the issue but the required changes need some discussing. Hopefully we can fix it soon.

Since you were already doing some investigation yourself and editing the installed file, would it be possible for you to try the 2 solutions I have proposed?

If you can replace pyscaffold/shell.py by the following 2 updated versions and try with putup -i, that would be very helpful...

@saltball
Copy link
Author

saltball commented Apr 1, 2021

Hi @abravalheri, thank you very much. I have tested both solutions and there is no more console errors.

But I found a new problem. I can open the .args.sh file with vscode after run putup -i, however, I couldn't edit the file becasue the file will be deleted very fast. It seems python considers the vscode process ends as soon as command putup -i runs but before I could edit the file.

Moreover, I test notepad (by delete code from list EDITORS in shell.py ), then the interactive function works perfectly. So I suggest vscode is running a different way from notepad which subprocess module couldn't catch the process status as we expect.

When I use argument -w(or --wait) for vscode(check https://code.visualstudio.com/docs/editor/command-line for details.), it works well.

I do that by just changing line 124 in interactive.py from

            content = shell.edit(file).read_text("utf-8")

to

            content = shell.edit(file,"-w").read_text("utf-8")

But it is not work for notepad. I'm not sure how to fix it. It seems a wrapper is needed in function get_editor() of shell.py to determine whether a editor is code.

@abravalheri
Copy link
Collaborator

Hi @saltball, thank you very much for the very useful information. That helps a lot!

After reading your comment, I was curious to see if other people had problems using vscode elsewhere and I found this post in dev.to. Apparently vscode always needs to have the -w option to be used as EDITOR (environment variable)...

I wonder if we should try to automatically guess that, or leave it to the user to set the EDITOR environment variable accordingly... (In that case, if the path for the editor contains spaces, the user will also have to quote it properly when assigning EDITOR).

@abravalheri
Copy link
Collaborator

@saltball
Copy link
Author

saltball commented Apr 2, 2021

@abravalheri Thank you for quick reply. And yes, I notice many editors requrie flags. And there is also some realizations of using editors by python. One of them: https://github.com/fmoo/python-editor/blob/master/editor.py . It seems a nice way we automatically guess that.

By the way, I think maybe tips of editor choice in the document and a putup argument for editor chioce is needed (for someone who has mutliple editors). It depends on the project plan.

@abravalheri
Copy link
Collaborator

abravalheri commented Apr 2, 2021

Hi @saltball, thanks for pointing it out.
Indeed we should document that it is possible to choose the editor by setting the environment variable EDITOR (or VISUAL).

I had a look on python-editor, it seems that their default list of editors don't include any options for vanilla windows, and they are a bit unmaintained :(

Meanwhile I am testing some default options out in #431 and #433.

@abravalheri abravalheri added the bug Something isn't working label Apr 2, 2021
@FlorianWilhelm
Copy link
Member

Sorry, @saltball and @abravalheri for the long wait. For me, it seems that PR #431 would be the easiest fix. Thanks, @abravalheri for the great work.

@FlorianWilhelm FlorianWilhelm added this to the 4.0.2 milestone May 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants