Hi, Am 21.10.2022 um 14:36 schrieb ignatios%cs.uni-bonn.de@localhost:
On Thu, Oct 20, 2022 at 10:30:12PM +0100, Mr Roooster wrote:On Fri, 7 Oct 2022 at 14:19, Matthias Petermann <mp%petermann-it.de@localhost> wrote:- Can what I have in mind already be solved (differently or more elegantly) with existing tools from the base system?It's not elegent, but depending on your shell you can abuse tee to do something like: $ echo -e "alert|alert thing\ninfo|less important\n" | tee >(grep "^info|" | cut -c6- | logger -puser.notice) | grep "^alert|" | cut -c7- | logger -plocal0.noticeUh... much easier than that, just using the standard shell's builtin capabilities (and /usr/bin/logger): $ printf "alert alert thing\ninfo less important\n" | (while read typeofmsg rest; do case $typeofmsg in alert) prio="user.notice";; info) prio="local0.notice";; esac logger -p $prio $rest done) You can save the case...esac when you put the raw prio value as first word of the line (whitespace separated from the rest of it): $ printf "user.notice alert thing\nlocal0.notice less important\n" | (while read typeofmsg rest; do logger -p $typeofmsg $rest done) (Btw: If you insist to use cut, use ...|cut -d\| -f2-|... instead, it's more robust when you haven't to count the characters on each reedit of the code.) Regards -is
thank you all very much for the suggestions and impulses for reflection. I'm coming to the realization piece by piece that I need to divide the use cases more precisely after all. I have the thoughts of a 12F app[1] in the back of my mind all the time and am trying to line them up with the requirements of command line tools / scripts. Part of the motivation behind this comes from the fact that I've written a number of server apps that have multiple modes of operation - such as a built-in web server (logging via stderr) and a CLI (user input via stdin, payload output via stdout, logging/error messages via stderr). Since the scenarios that can be triggered via the web server are exactly the same as those that can be triggered via the CLI, I try to treat all diagnostic output (including error messages and warnings as well as all non-payload confirmations and information) as similar as possible for both operating modes. Furthermore I don't want to implement any specialities of the logging framework of the respective runtime environment in my applications (implemented in Golang, deployment on different platforms including Windows). Long story short... I should reconsider my motivation ;-) I realize that the kind of change to the logger tool I prototyped is based on very specific assumptions that don't belong on the generic level of the base system.
I'm currently thinking about a standalone tool, a kind of "logger-shell" that starts an arbitrary binary (12f app) with popen. Stdin/stdout of the binary would be passed through directly to the stdin/stdout of the "logger-shell". In contrast, stderr would be logged via (configurable) rules to the respective logger (e.g. syslog()) with the appropriate log levels. This would allow me to wrap the above kind of server applications in web server mode while using them directly in CLI mode. I'll keep thinking about it though ;-)
For my example - the backup shell script - in the meantime I think that the approach with the "standard shell's builtin capabilities" is the one I like best.
Kind regards Matthias [1] https://12factor.net/logs