On 04/12/2016 07:41 PM, Xen wrote:
Carlos E. R. schreef op 12-04-16 13:32:
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).
Many CLIs - zypper is a good example - are libraries with wrappers. The issue is the functionality, not whether it is a library or a CLI wrapper for that library. Its this kind of fuzzy thinking, last of a precise REQUIREMENT and specification that has taken this into a rambling and unhelpful discourse. If you can't see that very basic aspect of programming, that even the CLIs are made up on top of libraries that can be used elsewhere, then its "abandon hope and discard this thread".
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.
You must be, as Whitman observed, vast, vaster than the rest of us here, since you contradict yourself. What functions you do describe can be carried out by the logger libraries and configuration files. A visit to Perl's CPAN will give some edification in this area too.
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.
I don't know why you want to make things so complicated. The already existing rsyslog mechanism not only supports programmability and templates, but listens on sockets. All that is specified in config file. You can have up to 50 concurrent sockets, and thanks to the programmability of rsyslog, your custom config file can turn these on and off according to your own programatically defined needs. At this point 'facility' and 'priority' loose their classical meaning and are just additional parameters for your custom tool. They can be used to trigger specific 'templates'. The important thing here is that a "daemon' listens on a specified socket. Which one? well that's what the config file is for.
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.
My point is that you can 'tweak' it; you should know that if you'd actually RTFM, and if you had a clearer idea of what you were trying to achieve, rather than just denouncing Linux as you seem to keep doing. The people who designed many of these components had a good vision, and all you are doing with this argumentative approach and dodging around is showing that you have (a) failed to do proper research into the matter and (b) are committing the error of fuzzy thinking by not clarifying what you actually want and playing stupid "yes-but" games. There is no malice, just an emergent property of the fuzzy thinking.
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 you had RTFM and experimented a bit based on what is documented you'd know that is possible.
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.
I don't see an objection or problem here. There are many database services that don't need a "daemon" beyond the lifetime of the user running the application. Back in the days of email carried by UUCP there was no continuously running "email daemon". We accept the continuously running email daemon today becuase it need to carry a lot of traffic, but there is no reason wht it *has* to be continually running. A low volume site could have a "sender" that is only triggered by a user pressing "send" causing another program to execl. The XinetD could have a configuration for a receiver that is only spawned when someone comes knocking on port 25. In the days before we had CUPS (or even is SVR4 predecessor) there was no line printer daemon, just a driver programme for a printer hanging off a tty port :-) It lived only as long as it took to drive the line printer.
You could also consider that some system administrator might not like you running something like that :p.
I can't see why. What's wrong with creating your own named pipes? (aka sockets). Why do you think 'mknod' is in '/usr/bin/ and not /sbin/? Its so ordinary users cam run mknod -p <filename> In fact FIFO mode is the only truly portable and user available mode of mknod. See the various man pages for the reason for that. Of course you may prefer 'mkfifo'
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.
The boundary between what is a script and what is 'just' a program when it come to interpretive languages is fuzzy. Java and Python you can clearly save the intermediate code. Perl and Ruby are a bit ambiguous in this regard. The Bash shell is very unambiguously what is termed a 'throw-away compiler-interpreter' (nomenclature due to P. J. Brown of Oxford and Canterbury) in that it build the parse tree but doesn't retail the source, but the parse tree is inaccessible. (Of course there are hacked versions where that's available for debugging purposes, but such are outside the scope of this.) Yes, you can view Java/Python as a 'throw-away' where the source is thrown away but the parse tree has been complied to a reloadable module, where as the similar module doesn't exist for Bash. They are still both interpreters and are still both scriptable.
I cannot imagine requiring async logging for something that is nothing more than a (big) shell script.
Right now you can't :-) But after you've used the setup for a year and published it you, or someone else, will end up with that as a requirement. Maybe you're doing a client/server thing like SSH and need to log both ends.
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.
*sigh* I can't see why its any more "not nice" than any other form of non-trivial shell scripting (or scripting in Perl or Python or Ruby).
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.
I use Perl and Ruby and there is for both; I can't imagine Python is crippled and doesn't have one.
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.
Ahm, I can do that already. I can unpack RPMs into ${HOME|/bin and ${HOME}/lib. I do this at one of my ISPs where I need a later version of Ruby and its libraries for a RubyOnRails application I have. I know it can be done, so please don't tell me it can't be done. I just have to have my own version in the $PATH and ${LD_LIBRARY_PATH} ahead of the system defined values.
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.
I do. BTDT. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org