Troubleshoot CompStart.ps1 using JSON file from issue #11

[dEhiN]

As mentioned in issue #11:

While testing out the functionality of the json_adder function, 2 new and valid startup items were added to the startup data file.

However, when the CompStart.bat script was run, there were some issues with starting all the programs. The new test JSON file contains all 5 programs so the script can be troubleshot at a later time.

The new test JSON file mentioned is called startup_data--issue11.json and is found at /devenv/data/old_data/python-tool-testing/. The JSON data it contains is the following:

{
    "TotalItems": 5,
    "Items": [
        {
            "ItemNumber": 1,
            "Name": "Calculator",
            "FilePath": "calc",
            "Description": "A simple calculator",
            "Browser": false,
            "ArgumentCount": 0,
            "ArgumentList": []
        },
        {
            "ItemNumber": 2,
            "Name": "Google",
            "FilePath": "C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe",
            "Description": "The Google Homepage",
            "Browser": true,
            "ArgumentCount": 3,
            "ArgumentList": [
                "--profile-directory=Default",
                "--new-window",
                "https://www.google.com/"
            ]
        },
        {
            "ItemNumber": 3,
            "Name": "Notepad",
            "FilePath": "%windir%\\system32\\notepad.exe",
            "Description": "A text editor",
            "Browser": false,
            "ArgumentCount": 0,
            "ArgumentList": []
        },
        {
            "ItemNumber": 4,
            "Name": "PowerShell Admin",
            "FilePath": "powershell",
            "Description": "PowerShell run as admin",
            "Browser": false,
            "ArgumentCount": 1,
            "ArgumentList": [
                "--RunAs"
            ]
        },
        {
            "ItemNumber": 5,
            "Name": "Dir of C",
            "FilePath": "dir",
            "Description": "Showing the directory listing for C:\\",
            "Browser": false,
            "ArgumentCount": 1,
            "ArgumentList": [
                "C:"
            ]
        }
    ]
}

When CompStart.ps1 ran, there were problems with startup items 3-5. Specifically:

• Startup item 3 resulted in the Windows program chooser window for opening a file that's not associated with an existing program. In this case, selecting Notepad or another text editor (like Notepad++) showed a bash script.

• Startup item 4 opened a PowerShell window but then showed an error with the argument "--RunAs". Will need to recall the argument to pass to run a PS session as admin.

• Startup item 5 didn't seem to run at all.

Will probably need to debug the script using this JSON file to see what's going on, since the script works fine using the default startup file. Additionally, startup items 1-2 opened correctly during this testing.

[dEhiN]

Starting to work on this issue. The JSON file referenced was zipped up with all the Python tool test data. Will need to extract it and see what's happening.

[dEhiN]

Ran a test and figured out the most likely reason startup items 3-5 failed:

1. For startup item 3 - PowerShell couldn't find the path %windir%\system32\notepad.exe.
2. For startup item 4 - A new PowerShell window was started but the -RunAs argument didn't work.
3. For startup item 5 - PowerShell couldn't find the file dir.

To elaborate further:

For startup item 3, further testing needs to be done to make sure the Python CLI tool uses the full path to a program. While PowerShell does have a way to evaluate Windows shell or explorer shorthand, such as %localappdata% or %windir%, it will be hard to code in logic to evaluate shorthand on the fly. That is, it's easier to make sure the path-to-program that's saved in the startup data is the full path.

For startup item 4, the fix is easy - the argument is incorrect and needs to be fixed. One possibility is to future-proof this in the Python CLI tool by checking the arguments. Alternatively, error handling could be added to the CompStart Powershell script to display a message to the user if a startup item fails to run due to an argument. A third alternative is to have the Python CLI tool use a safer method for adding arguments, such as some sort of non-manual method.

For startup item 5, the Python CLI tool needs to be tested to make sure it doesn't allow for manual input of the program name and path. This ties in with the problem facing startup item 3. For both items, the error arose from manually entering a program name and path, which turned out to be incorrect or something that couldn't be easily parsed. As long as the Python CLI tool doesn't allow for manual input, or if it does, has some way to verify the input, these errors shouldn't arise.

[dEhiN]

So, to summarize the last comment, the Python CLI tool needs to be checked for manual input of program names and paths, as well as handling of program arguments.

[dEhiN]

Adding this to Back-Burner status because it may not be relevant anymore. If the Python CLI tool isn't going to be worked on or developed more, and if a graphical tool is going to be created as a replacement, then this issue may not matter.