-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
✨ Use the first argument as a module name #145
Conversation
The first CLI argument with a module name enables the writing of runnable modules. A future Parser module only needs a main method taking the root path as an argument.
I've got an error:
I invoked these commands to prepare escript
|
Tried to find something about :nxdomain on official doc, unfortunately without success.
|
From https://itigic.com/nxdomain-error-how-can-we-avoid-it/ What is the When we try to enter a web page and we get an error message indicating NXDOMAIN, it means that the domain name could not be resolved. This logically means that we cannot navigate through that site we are trying to access. |
I've tried to debug Unfortunately I've got an error:
I feel helplessly... Oh no my baby woke up seize |
If you want run you have to run iex as: |
nxdomain error is something what is expected because we use as input urls with domain |
We should consider to make special parser to parse arguments from cli to get module. See https://elixirschool.com/en/lessons/intermediate/escripts |
I agree that using OptionParser is the correct way to process the arguments. I chose to use plain pattern matching only to keep the changeset to the lowest level possible and switch to the smarter approach in the follow-up pull request. Also the argument is rudimentary in its nature. It is a raw module name. Passing an invalid one raises an exception. That too is a sign of a temporary simplistic solution. |
Thanks for your review! 🙌🏻 Merging. |
Thanks for mentioning |
The first CLI argument with a module name enables the writing of runnable modules. A future Parser module (#89) only needs a main method taking the root path as an argument.
The dynamic approach also allows testing of the CLI entry point.
The approach is naïve. It does check neither the parameter count nor whether a module exists. A missing argument or an incorrect module name, including a different case, causes an uncaught error.
With the new code in place, the escript has a new invocation syntax: