Carlos E. R. schreef op 12-04-16 13:32:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday, 2016-04-11 at 21:06 +0200, Xen wrote:
Anton Aylward schreef op 11-04-16 01:15:
On 04/10/2016 06:55 PM, Xen wrote:
For instance "logger" is clearly not a complex tool. If it had a little more functionality, the same interface would be very easy to use in a script (or program).
And what 'extra' functionality do you think it SHOULD have? And how would that make it easier to use?
Can you be specific, please.
I already explained at the beginning:
In short:
a logging library or program (for a shell script, you could not use a library, you need to have a command line tool).
That could do what logrotate and syslog do,
without requiring logrotate and syslog.
Wait. The specific question here is what do you find missing in "logger". Remember that logger requires a syslog daemon (can be systemd journal), with all the wistles, including rotating.
You are talking about a tool that does not exist or that we have not found, to log to file by users, not "logger".
So, the question: what do you find missing in the existing logger, aimed at syslog?
I have no interest in a logger that can only log to syslog. Although, of course, you could run your own user-created syslog daemon that you configure and specify as a user, and then you could log to it using -n and -P tags/flags. As to Anton, you are trying to derail the discussion. I never had any interest in logger as a real solution unless I can tweak it to my usage. I have stated numerous times: * Functionality akin to logger/syslog/logrotate/cron that I can control completely as a general non-privileged user on any system. If I can just fire up my own syslog daemon instance, call logrotate on its output, use logger to send data to it, and have a way to automate some of that (either by using cron or as an activation check in the script/program) then in a general sense that is problem solved. It does require starting the daemon as your program (script) starts, and shutting it down when you finish, which is a bit weird for scripts, but perhaps doable for real programs. It is really only necessary (theoretically) if you require asynchronous logging though. You could also consider that some system administrator might not like you running something like that :p. I don't even know what system I have in mind. If I just use java, and maybe some java-python plugin (jPython?) I won't even be dealing with scripts. I cannot imagine requiring async logging for something that is nothing more than a (big) shell script. What remains is real Linux programs (I mean C/C++) and I have no intent really of writing any yet. Also firing up daemons of your own might not be very nice. It can be a thread or child of your program though. If I wrote anything for Linux myself it would probably be Python at first. I'm sure there is some logging library for it that I could use. So I'm not sure what the real practical issue is. Anything requiring real complex logging is going to be something more than a script. Regardless, I'm interested in this because it relates to the "your program as its own package" concept in which a program install doesn't impact the rest of the system as much. In OS X most programs are entirely self-contained. I like that concept. The package format contains information on what the main process (executable file) of the package is, much like a Jar perhaps (not sure). These programs, you just double-click them (or whatever) or just drag them to your dock, and all this time they are still just that package. The package is not even unpacked in some sense. I don't like that completely, but I would like to be able to provide "own tree" solutions where a program is just in its own subdirectory while still being accessible. For instance, you could imagine a "user" set of programs where all executables are just symlinks. Say what would amount to a /usr/local/bin but all files are symlinks to the real programs. Then you could have a user-local package installation system that does not require total root access in order to install programs. Then you could scope the rest of the system to hide much from the user and only show what she wants to see. Something like that, I don't know. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org