Bash script: Dealing with program input from a pipe
Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
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...
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
Last edited by ilikejam; 04-28-2009 at 01:34 PM.
Reason: Use cat instead of read - echo in script
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?
/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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.