Bash script: Dealing with program input from a pipe

sleeper0110 · 04-27-2009, 04:19 PM

I have a script that would get run like this:

echo "This is a test" | ./testScript

I would like the script to take "This is a script" and output it to a file without screwing up standard input.

I've tried to "cat - > /tmp/somefile" but that screws up 'read' statements later on in the program.

Thoughts?

Thanks.

ilikejam · 04-27-2009, 05:42 PM

Hi.

I take it you need to do some interactive stuff later on in the script that gets 'read'? Unfortunately, you only get one std in stream to work with - anything else and you'll have to use files or FIFOs to shunt data about.

Can you elaborate a little on how the script works and what sort of data you're dealing with? e.g. if the 'This is a test' data is likely to be less than a few thousand characters, you could specify it as an argument to the script, rather than using std in, which would let you 'read' later on. If it's bigger, you could set up a FIFO and read from that rather than std in.

Tell us more, do.

Dave

sleeper0110 · 04-28-2009, 01:07 PM

Thanks for your reply.

You're correct about it being an interactive script.
Here is some more info on the script:

It will be a script that gets run every time a user commits to our CVS repo (a cvs hook). The script will get the CVS log message on standard in. This is how CVS hooks work so the log message must come from std in.

The point of the script is to determine the number of words in the CVS log message (again, it gets passed on std in). If the log message has more than 500 words the user will be presented with a menu to basically verify if they actually want to commit with such a large log message.

It's a long story, but I have users that accidentally enter a log message and then manage to repeat it 10,000 times because they aren't that great with vi.

So, my plan is to take the log message from std in and store it to a /tmp/file, so I can run wc on it as well as have the option of displaying it again to the user.

More thoughts?

Thanks!

ilikejam · 04-28-2009, 01:31 PM

Cool. I didn't actually think this was do-able, but then I had a vague memory of a script someone wrote long ago with a weird exec statement in it and...

Code:

#!/bin/bash

cat - > /tmp/somefile
exec 0< /dev/tty
<interactive stuff>

This will only work if there's a controlling terminal (i.e. not from cron or at), but since it's interactive, I don't think that'll be an issue for you.

Dave

sleeper0110 · 04-28-2009, 03:28 PM

Neat. That appears to do what I want.

I'm just curious, will /dev/tty always work on a very busy server with multiple people logged into it? I guess I don't understand tty devices that well. I'm concerned if multiple people are logged in and doing commits or whatever, will /dev/tty work for all of them at the same time?

Thanks. Your idea is very helpful.

ilikejam · 04-28-2009, 03:41 PM

/dev/tty isn't a normal device. Any process that does an open() on the device to read or write is actually diverted to the controlling tty of the process doing the open(), if that makes any sense. A bit of kernel (or libc maybe?) voodoo so that you don't have to run 'tty' to find out what the controlling tty is.

Open a couple of shells and do 'echo hello > /dev/tty' in each - the output will appear on the same terminal, but not anywhere else.

Basically, yes, it'll work fine, regardless of how many people are logged in and where.

Dave