2

I have tried this a few ways and while I cannot share specifics of my project I can boil it down to its essence.

I have something like below

import argparse,sys
parser = argparse.ArgumentParser()
parser.add_argument('password', help='The password')
parser.add_argument('--optionalArg', help='Just an optional arg')
args=parser.parse_args()
print(sys.argv[1])

When running this from a Windows 10 PC with Python 3.6.x installed I get output like below:

test.py test --optionalArg myArg
test --optionalArg myArg

I have even tried with Argparse examples from Python directly and get similar behavior.

Now, coincidentally on another machine, also running Windows 10, and Python 3.6.x it works. Now they are two minor versions off.

I also saw another question on SO (Though having issues finding it) suggesting that in HKLR/Applications/python to ensure there is a "%*" which made the first argument show up at all on the machine where it does not work. This stated I am noticing this entry does not exist at all on the machine it is working on.

I understand this is likely a registry problem or something else regarding the installation. I am further investigating to see if I can pinpoint the problem.

I will update here with any additional questions.

EDIT:

I have trimmed example code to three lines only:

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

still outputs the following:

>argtest.py 1 2 3
1 2 3
['1 2 3']

on the machine with the issue.

shwm19
  • 33
  • 6
  • I'd suggest removing the `argparse` step for now, and focus on what's in `sys.argv`. Normally `sys.argv[0]` is the name of the script being called, and `sys.argv[1:]` is the list the `argparse` parses. – hpaulj Sep 22 '18 at 18:23
  • A similar case: https://stackoverflow.com/questions/50440889/why-does-argparse-only-work-if-the-python-interpreter-is-called-explicitly – hpaulj Sep 22 '18 at 19:54
  • Python scripts are only associated with "Applications\python.exe" if the system is misconfigured. Fix the association to use the correct "Python.File" program identifier. This needs to be done in the GUI, *not* via CMD's `assoc` command. `assoc` and `ftype` predate many changes made starting with Windows XP. – Eryk Sun Sep 23 '18 at 00:42
  • hjpaulj, Perhaps my above question was not made well enough to express my issue. sys.argv[1] seems to contain everything after the application name. I understand the concept and that sys.argv[:1] should contain all after the program but the core problem here is that sys.argv[1] seems to contain the entire string after the program name thuse the print out of just sys.argv[1] being the test --optionalArg myArg Updating question with new information. – shwm19 Sep 23 '18 at 20:22
  • @eryksun See, I thought that may be the case because the machine that does work does not have this. Would you be able to provide some reference material in an answer possibly? I am very open that this is a misconfiguration, namely due to this being a second installation of python on the issue machine, and on the machine that does work it is the only instance of python installed. – shwm19 Sep 23 '18 at 20:27

1 Answers1

0

Alright, so I figured this one out.

As Eryksun pointed out in my questions, and others, the .py in your registry should be pointing to Python.File. (Specifically Computer\HKEY_CLASSES_ROOT.py registry)

Now that is fine and dandy... if it is set up right. So while mine is pointed there (From everything I could see) on the problem machine, I found an issue in the registry where I had "%" instead of just %

If I learned anything, it is never add what is not explicitly in an answer lest it may not work.

shwm19
  • 33
  • 6