-
Notifications
You must be signed in to change notification settings - Fork 297
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
Add a print function that prints to stderr #1777
Comments
(Elvish doesn't have I'm not sure about this. I agree with you that printing to stderr is common enough in shell scripts and it may warrant a bit of special treatment. But I feel that there's a bigger problem about providing feedback to the user and logging in general, and providing a parallel stderr version for Re naming, I'd go with the |
Ah, yes. I fixed the misspelling and switch-up. Maybe elvish could have a log module, similar to python's logging module? log:error some error by default these functions would have a default output file(descriptor), but they could also be configured to behave differently. About the other issues with these functions: Have you put them into words somewhere yet? |
A log module with a runtime-configurable destination and style is definitely a reasonable building block, and it does make the need for separate stderr-writing commands obsolete. The API is orthogonal to the echo/print/printf dimension though. Which one does There are some more high-level questions I'd like to have answered:
I think traditional logging libraries are fairly unopinionated in that they don't really answer these questions and just give you APIs to do whatever you prefer. Elvish should probably have an unopinionated logging library as a foundation but since shells are more in the business of "applications" I feel there needs to be either a more opinionated high-level library or at least a pattern. (Another question is when multiple libraries use the logging library, how would the logging library know the source of each log message. This is a more technical question though, so no need to delve on it too much for now.) |
These are some tough questions... Sometimes an application might just want to print an error/warning to stderr without failing, if e.g. some parsed file does not look like it should, but the application can handle that and just keep going. In this case log:error would be appropriate. I think the application user should probably be able to control the log level of an application (including its libraries). I think the best compromise might be that there's a variable I'm not sure what would be the most sensible way of doing this tough.
I think I would prefer the first approach, but the second one might also be preferable due to its simplicity. I'm not sure if there really is a need for a more opinionated high-level library. Oh, also: when talking about these variables I had environment variables in mind, but they could (and in the case of elvish probably should) of course also be variables in a module in which case the naming would obviously be a bit different. |
Note that there are a large number of commands that produce output on the byte stream; e.g., |
What new feature should Elvish have?
This is probably a question of taste, but I think builtin print-to-stderr functions would be useful.
I know that I can just pipe the output of print or echo to stderr and that I can just write such a function myself.
However, I think for scripting in particular this would be a great addition, as printing errors is something that is very commonly done and having a shortcut like this would make it a bit less tedious.
It would probably be sensible to add error versions for the three main printing functions.
Here are some proposals how these functions can be called. I personally like the err-suffix most.
These functions should maybe also automatically style the output in red (or maybe only in the case of echo, idk).
I would also be open to implement this my self, if there's interest in this. While I don't really have experience with go, I don't think this should be too hard.
Output of "elvish -version"
0.20.1+archlinux4
Code of Conduct
The text was updated successfully, but these errors were encountered: