Language:
switch to room list switch to menu My folders
Go to page: First ... 13 14 15 16 [17] 18 19 20 21 ... Last
[#] Thu Dec 02 2004 21:52:13 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Ahh... I think I've got it.

tail -f /path/to/log/file &
cat <`tty` >/path/to/named/pipe

It has the peculiar side effect of requiring an extra return for input, but it seems to mostly work.

[#] Thu Dec 02 2004 21:55:06 EST from Peter Pulse @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

What are you trying to do that the arrangement you have now doesn't do?
More details would be helpful.

[#] Thu Dec 02 2004 22:01:20 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


I have a named pipe.

I have a log file.

Anything entered into the named pipe acts as input for a program, who spits out information to a log file.

Now, this isn't the normal way you run a program like this... normally, you run it on a command line, and it'll act kind of like a shell (except it's doing stuff in the background). Anything you type is considered commands to the server, who will spit out responses.

I want it to *look* like that's what you're doing, but I want it to route input from a named pipe, because I'd like to occasionally have a cron job pass commands to the server (because the server really needs to be reset on a regular basis.. I'd like to accomplish this cleanly, and I'd like to provide a countdown to those using the server before ripping it out from under them... which I can do via commands to the server).

[#] Thu Dec 02 2004 22:08:20 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Put another way...

You know how tee branches output to two sources?

It would be nice to converge input from two sources into one.

[#] Thu Dec 02 2004 22:35:20 EST from Peter Pulse @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Ok, got ya. So what's the problem? Sounds like it's doing exactly what you want?

[#] Thu Dec 02 2004 22:39:47 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


It is now, with that last bit I posted..

tail -f /path/to/log/file &
cat <`tty` >/path/to/named/pipe

It was the cat command I couldn't think of earlier.

[#] Thu Dec 02 2004 23:12:52 EST from Peter Pulse @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

You don't have to do that whole tty thing, you can just do
cat - >/path/to/named/pipe

[#] Fri Dec 03 2004 08:14:02 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


I'll give that a look-see.

It'd be even nicer if one could do something like:

merge - /path/to/named/pipe | service_executable | tee >/path/to/logfile

[#] Fri Dec 03 2004 08:16:38 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Ohhhh... wait a tic.. maybe I've been really stupid.

tee /path/to/named/pipe <`tty` | service_executable | tee >/path/to/logfile

[#] Fri Dec 03 2004 08:45:30 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Ugh.. no..

'merge' is already a common unix command (one I didn't know of) that merges two text files into one.

And 'tee' takes one input and generates two outputs. I need two inputs to one output, if I'm going to create a composite command to do what I'm thinking.

[#] Fri Dec 03 2004 10:17:42 EST from georbit @ Haven BBS

[Reply] [ReplyQuoted] [Headers] [Print]

Dec 2 2004 10:08pm from fleeb @uncnsrd (Uncensored)

Put another way...

You know how tee branches output to two sources?

It would be nice to converge input from two sources into one.


Sounds like somebody should write a funnel command :-)

[#] Fri Dec 03 2004 11:38:24 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


I've almost finished this.

A tool named 'vee', to complement 'tee', which draws from multiple inputs and route them to one output.

I just need to get the streams synchronized (using ::tie, just have to remember how it works), and it should be nearly ready.

The thing that sucks, though, is that folks have an inconsistent way of providing a means by which you can check to see if there's any input before drawing on any input.. or at least, it seems inconsistent to me (I'm speaking of STL).

But, that discussion more properly belongs in the Programming room.

It's kind of neat, though. I might advance it a little more, so if one of the files you specified goes EOF, I could simply remove it from the list.
This way, you could do cool things like:

vee /to/named/pipe /to/initial/set/of/commands | my_server | tee /some/logfile/somewhere

I also need to actually process the argument list to see if someone wants to use stdin, or if they don't.

Kind of a cool tool, really.

[#] Fri Dec 03 2004 13:24:40 EST from Peter Pulse @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

You can do most of what you want with "cat", that is, you can cat an initial set of commands, then your named pipe.

nohup cat initial_commands.txt my_named_pipe | my_server

Will start server, feel contents on initial_commands.txt, then start taking input from named pipe. I still don't get why your named pipe solution *(that you already figured out) is not working. What does this program that you are writing make possible that you can't do now? But for multiplexing inputs you need to use select(), I don't know if it's possible to do it with C++ streams very elegantly. In some of my code I needed to read from a socket in C++ and I wanted a timeout. I couldn't find any way to do it elegantly.
I ended up with some ugly code that checked to see what was in the buffer and UI don't remember what else, but I got it to work. You can write it in C much more simply. I would suggest just writing it in C. Taking two inputs simultaneously to one output would just be like 10 lines of C, if that.

[#] Fri Dec 03 2004 12:47:09 EST from Hue Jr. @ Anansi-Del

[Reply] [ReplyQuoted] [Headers] [Print]


How do you know which input to use first?

[#] Fri Dec 03 2004 13:34:40 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Part of it is my perverse desire to see if C++ (via STL) can do what I'm thinking. I've learned that it can't, for one glaring ommission.

Or, rather, it *could*, but I'd have to extend the istream class, which is more effort that I want to get into for something like this.

The 'cat' works, but isn't as elegant a solution as it could be. I'll confess, some of this is sheer pedantry on my part. It just seems like unix ought to have a tool like 'vee' to combine input to one output.

[#] Fri Dec 03 2004 14:08:36 EST from Peter Pulse @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

(no text)

[#] Fri Dec 03 2004 14:16:12 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


I can understand the potential for madness. The way I'm designing this 'vee' utility, it would work line-by-line, which would help reduce some of the madness.

And, maybe, it's kind of a specific purpose.

I suppose I just look at unix with this whole sense of streaming that it has, and figure that something within the system ought to combine input to one output. There's something elegant, to me, in this approach.

I might need to think about this some more, anyway. One of the problems with pushing stuff into the background (or whatever) is that you can't easily close it when you're done. You make it easy to leave something running in the background that should be shut down.

Perhaps I'm quibbling, but it's kind of fun. And this isn't something that needs to get done quickly, so I can afford to think and work towards an elegant, reusable solution.

[#] Fri Dec 03 2004 14:19:21 EST from Mr.T @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Unless you explicitly nohup it and it isn't a daemon, it'll terminate when
your shell exits.

[#] Fri Dec 03 2004 14:27:31 EST from Peter Pulse @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I think that if you send your server a command telling it to shut down then that would take everything with it. But yea that is why a lot of programs write pid files out when they start, so that you can find them later and (automatically or manually) kill them. There's no magic bullet because there are so many differences between programs. If you were to use a sysv init script to start your server (and associated input crap eg the named pipe and cat process) then you can find another program that uses a pid file for control and use their script as a template for writing yours. Then you casn use the existing commands service stop, service start, service restart to control your server.

[#] Fri Dec 03 2004 14:38:04 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Heh... which brings us back to being able to type in commands and see the results of these commands as if you were running the server in a normal terminal session.

But, yeah, I'm working out how an elegant solution to do this. I've got weirdness to consider.. such as the cron process shutting down the server, then bringing it back up again in some way that still allows it to be monitored and commandable from the screen session running for it.

Go to page: First ... 13 14 15 16 [17] 18 19 20 21 ... Last