Execution - Any plans to standarized with normal cmdlet and function call format?

[sheldonhull]

I love this project, but I had serious issues getting it running due to the relative paths and argument completion. I was wondering if any plans to standardize with a normal cmdlet parameter/function structure, and not dynamically based on dot sourcing?

My work around to get the import command to finally run was to create a bat file in the project directly that called the command with this syntax

echo Must Run This as Administrator
cd %~dp0
powershell.exe -File "%~dp0bin\concfg.ps1" import solarized
pause

Not that any alteration caused issues for me. Very sensitive to any quotes, parameter changes. Let me know if I can help. This is a great project and I'm thankful for your contributions to removing annoying black cmd windows from the universe :-)

[Luke Sampson]

had serious issues getting it running due to the relative paths and argument completion. I was wondering if any plans to standardize with a normal cmdlet parameter/function structure, and not dynamically based on dot sourcing?

Not sure what you mean. Can you give some examples?

[Luke Sampson]

Do you mean the use of aliases by concfg causes problems if you've overridden them?

I'm deliberately trying to use a Git-style interface for concfg rather than the standard PowerShell Verb-Noun naming. I think it's more widely understood, familiar, and just works much better to be honest.

I wasn't aware that this would cause problems, and have used a similar dot-sourced structure with Scoop for years. Although I did have to locally reset the standard PowerShell aliases to keep it working when people had redefined them. Possibly it's just a matter of doing the same thing for concfg.

[sheldonhull]

Thank you for the clarification. I was very confused as that is not standard for PowerShell and that's my experience. Anything with relative paths in windows can become a headache to troubleshoot. I'd expect a PowerShell solution to use normal function format with cmdletbinding, and parameter validation. Not a criticism, just why I was confused on the dynamic command loading format chosen. I can appreciate your coming from a different approach. Maybe the simplest solution is to provide a simple console entry file that handles ensuring options are chosen easily. Trying to get the commands to be recognized from cmd, bat, and PowerShell was a challenge for me. What I provided was the result of quite a few different tests to get it to run. Maybe a simple selection of bat files or something to allow easily running would be sufficient.

…

On Sat, Jun 24, 2017, 2:06 AM Luke Sampson ***@***.***> wrote: Do you mean the use of aliases by concfg causes problems if you've overridden them? I'm deliberately trying to use a Git-style interface for concfg rather than the standard PowerShell Verb-Noun naming. I think it's more widely understood, familiar, and just works much better to be honest. I wasn't aware that this would cause problems, and have used a similar dot-sourced structure with Scoop <https://scoop.sh> for years. Although I did have to locally reset the standard PowerShell aliases <https://github.com/lukesampson/scoop/blob/master/lib/core.ps1#L326> to keep it working when people had redefined them. Possibly it's just a matter of doing the same thing for concfg. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#30 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADXOsHK4LSmlU6NdGAY_l4iTrqFqcWEnks5sHLWQgaJpZM4ODv29> .

[Chawye Hsu]

I'll close this since concfg has changed a lot. Please try the latest version if you are still using concfg. And you can open a new issue if you are still encountering the problem.