Even though I’m using the Discourse Docker setup for almost half a year now, it still happens to me that I swap the launcher parameters and I write
./launcher app enter
instead of
./launcher enter app
To make a long story short and end this frustration, I suggest making the launcher forgive swapped parameters…
…and provide a PR for this:
This is a little weird it basically means all launcher commands are now disallowed as container names? Not that matching names isn’t confusing anyway, I grant you that…
No, I don’t see why this would mean that launcher command names are disallowed as container names: If the first parameter is a valid command, behavior will be the same as it is now. And if the first parameter is not a valid command, the current behavior is to exit 1 with an error message.
My PR only addresses the case where the first command is not a valid command name and the second command is a valid command name. In this case, it is probable that the user confused the parameter order.
For the sake of safety, we could prompt the user:
$ launcher app build
'app' is not a valid command name.
Did you mean 'launcher build app'? [Y/n]
Yes I like that much better! If you can make that change I vote we accept your PR.
There you go:
PS: Interesting: The first line (GitHub - discourse/discourse_docker: A Docker image for Discourse · GitHub) links to the commit (= url that i posted here), whereas the subject line (FEATURE: Make launcher forgive swapped parameters) links to the PR. I’m sure that’s intended, but that just surprised me.
Ok can you review that @falco?
Nothing against making things more user friendly, but most of the few CLIs I’ve used simply output a type of > enter --help when I’ve used the wrong syntax.
“Nothing against” and “but” don’t work well together, so let me say this: Most of the few forum softwares I’ve used weren’t very usable, so why making Discourse a usable forum software?
The answer is: because we can do better.
I don’t know what you mean by that other than you must have misinterpreted what I meant it to say.
I did not mean that the code should not correct user error.
Simply that most CLIs detect user error and “point them in the right direction” instead of trying to correct it for them.
If it is easy enough to accept command arguments and options in different sequences, different grammar (eg. ./launcher -r -a), then yes, it should be done.
죄송합니다. 이 PR을 3년 동안 방치해 두었네요… 그리고 3년 만에 이를 거절하게 되었습니다.
거절하는 이유는 다음과 같습니다. 우리의 거대한 bash 코드는 이미 매우 취약하고 복잡하기 때문에, 여기에 새로운 것을 추가하는 것에 대해 매우 신중해야 합니다. 이는 우리가 신경 써야 할 또 다른 취약점이 되며, 명령을 추가할 때마다 이 부분을 업데이트해야 합니다.