# Run without Debugging not working as intended

Trying to execute a script through the “Run without debugging” option (default keybind F7) and while the default arguments set for the project are passed on (as intended) the script fails on behalf of Komodo IDE also sending the debugger flags and arguments to the program.
I’m specifically trying to set up Komodo IDE to work with VapourSynth (video editing and frameserver library) and I want to use the vapoursynth-preview package to preview video output.

Expected output: Komodo IDE runs python -m vspreview {scriptname}
Actual result: Komodo IDE opens the Run config window and runs python -m vspreview -u -d 127.0.0.1:5036 -l DEBUG -n {scriptname}. Possibly more args get sent, but these are the ones breaking the Run without debugging feature in this case.

System: Windows 10
Komodo: IDE v12.0.1
I tried a clean env and a clean install, nothing seems to prevent Komodo from trying to attach a debugger to a non-debugging session

Hi RivenSkaye,

I’ll engage one of our Komodo developers to see if they can help here.

Cheers,

-JR

That’s expected behavior. Could you provide the error or brokenness that you’re getting? Those arguments shouldn’t break the application you’re running.

An alternative could be to use a Toolbox Run Command to run your script. You can hook that up to a keybinding to run it quickly.

• Carey
2 Likes

Okay, so the exact output I’m getting is

usage: __main__.py [-h] [-a EXTERNAL_ARGS] [script_path]
__main__.py: error: unrecognized arguments: -u -d 127.0.0.1:4980 -l DEBUG -n D:\truncated\path\to\BD\script.vpy
Press any key to continue . . .


Afterwards I get the usual expected behavior; Python exits. Now I might be able to solve this by sending in a PR to vspreview in order to ignore or only warn for any extra arguments, but the behavior of seems off to me seeing as I’m specifically telling Komodo not to debug the script.

I’ll also add in the project’s debug session interpreter arguments for completeness and I’ll try it with the trailing -a flag to see if that helps adding in -a just makes it error on not getting any external args instead and I have no clue if I can wrap the debug arguments in quotes or anything similar.

Final edit and closing note: the toolbox fix seems to work just fine for this, as it indeed allows me to control exact in- and output. Thanks!
Would you happen to know why those arguments are passed even when running without debugging though?

Hi @RivenSkaye,

Sorry for the delay. I’m apparently not getting notifications from our forums and I don’t actively monitor this forum, I’m usually over here: https://community.komodoide.com/

So just to clarify my thinking here, the implication of what you’re reporting is that ALL Python programs that get run in Komodo debugger are being passed extra arguments (the debugging ones) that the script needs to interpret. This is easy enough to check with a Python 3 script as follows:

import sys
print(sys.argv[1:])


then run that “Without debugging” or with debugging, either will work. I did that and I get this output:

[]


So no arguments are being passed to the script by Komodo in my case. The debugging args are passed the interpreter and are not passed along to the script.

But obviously something weird is going on in your case based on that error you shared. So I need to clarify some points from your response:

1. What dialog screenshot did you share and how did you get to it? It looks like it COULD be the debug dialog but that’s not what the debug dialog looks like. Here’s mine:
2. What did you mean by this statement:

I’ll also add in the project’s debug session interpreter arguments for completeness

Added what args where? You’re adding the Komodo debugging args somewhere or your program has debugging args? Please share screenshots of what you’re describing. It’s not easy to translate descriptions to the many fields and dialogs that you might be interacting with.

To answer your question, " Would you happen to know why those arguments are passed even when running without debugging though?":
Because it is “debugging”. It’s running the code through the debugger without hitting breakpoints if you’ve set them. It’s perhaps purely named. I don’t think that running it through the debugger is the issue though. Something else is going on.

1 Like