First time here? Check out the FAQ!
1

External console error (mac)

Hi,

Trying to run a small sample curses python program on my iMac using a virtual env. It needs the "external console" so I checked that box in the DEBUG I/O options. My default shell is zsh (per macOS 10.15).

Getting this error in the newly-opened output console: -u: command not found

The program runs OK when I run it directly from the terminal.

Console Output:

Last login: Wed Jul 1 15:16:19 on ttys001 cd '/Users/kpw/dev/python/mac_main'; '/Applications/WingPro.app/Contents/Resources/bootstrap/launch-env.sh' '-u' '/Applications/WingPro.app/Contents/Resources/bootstrap/wingdb.py' '127.0.0.1:49842' '0' '--no-first-stop' 'r'\'''\''+chr(60)+r'\''none'\''+chr(62)+r'\'''\''' '--nowait-on-exit' '--exec-in-env=/Users/kpw/Library/Application Support/Wing Pro/v7/env-vars-127.0.0.1-49842' 'r'\''/Users/kpw/dev/python/mac_main/test_curses'\''+chr(46)+r'\''py'\''' √ ~ % cd '/Users/kpw/dev/python/mac_main'; '/Applications/WingPro.app/Contents/Resources/bootstrap/launch-env.sh' '-u' '/Applications/WingPro.app/Contents/Resources/bootstrap/wingdb.py' '127.0.0.1:49842' '0' '--no-first-stop' 'r'\'''\''+chr(60)+r'\''none'\''+chr(62)+r'\'''\''' '--nowait-on-exit' '--exec-in-env=/Users/kpw/Library/Application Support/Wing Pro/v7/env-vars-127.0.0.1-49842' 'r'\''/Users/kpw/dev/python/mac_main/test_curses'\''+chr(46)+r'\''py'\''' /Applications/WingPro.app/Contents/Resources/bootstrap/launch-env.sh: line 8: .: filename argument required .: usage: . filename [arguments] /Applications/WingPro.app/Contents/Resources/bootstrap/launch-env.sh: line 10: -u: command not found

kpw's avatar
11
kpw
asked 2020-07-01 18:40:06 -0500
Wingware Support's avatar
4k
Wingware Support
updated 2020-07-02 08:16:49 -0500
edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

1 Answer

0

It looks like using a virtualenv with the "Activated Env" option of Python Executable does not work right with external consoles, at least on macOS because the env we set up is not passed in through the applescript that sets up the console. I was able to get it working by changing Python Executable instead to Command Line and entering the full path of the virtualenv's Python executable, which should be in the same directory as the 'activate' that you've get it configured to now. We'll try to fix this.

Wingware Support's avatar
4k
Wingware Support
answered 2020-07-02 08:16:44 -0500
edit flag offensive 0 remove flag delete link

Comments

Thanks for your quick reply. I will try your suggestion and will be looking forward to the update.

kpw's avatar kpw (2020-07-02 09:27:13 -0500) edit

Just a follow-up. By using your suggestion I was able to get this to work. I also had to add an environment variable (TERM=xterm-256color) in the Environment settings box via "Add to inherited environment" option. This entry was needed because of my use of the python "curses" library.

kpw's avatar kpw (2020-07-02 10:17:47 -0500) edit

Thanks. I looked at this in a bit more detail and the issue we load the env after the virtualenv launcher helper is run. I'm not sure how hard this will be to fix, but using Command Line instead is functionally identical for virtualenvs.

Not relevant to you but maybe useful for others: I think using Command Line won't work for conda envs without further manual setup of the environment. This problem is mentioned under About Anaconda Environments in https://wingware.com/doc/howtos/anaconda and a possible work-around for that case would be to activate the conda env on the command line and that start Wing from that env. Or the PATH can be modified to add Anaconda's library directories so the DLLs can be loaded (that could be done in Environment in Project Properties so Wing doesn't have to be launched in the activated env).

Wingware Support's avatar Wingware Support (2020-07-02 11:41:01 -0500) edit

This is still an issue right now. Any sight on a fix?

jrobijns's avatar jrobijns (2023-02-03 06:02:23 -0500) edit

Did you try setting the Python Executable to Command Line and entering the full path to the virtualenv's 'python' instead? That's functionally identical to using Activated Env with the full path to the 'activate' script, and it should work around the problem. The only possible exception to that might be some versions of Anaconda, as noted above.

Wingware Support's avatar Wingware Support (2023-02-03 11:19:57 -0500) edit
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer