I wrote a script for resizing windows, which require orientation and value in form of fraction, like so:
resize.sh -h 1/2
and it works as expected.
I also added -k flag, which means that script require user input, like so:
resize.sh -k -h
and in the script:
read -rsn 2 fraction
which I parse to get values for numerator and denominator.
This works great from command line, but idea behind this is to bind resize.sh -k -h to some key combination, and pass following two keys as input. But when I run script from keyboard, it run as a background process which is not associated with any tty, so read could not get its input. Is there any way to redirect global input to background process, after running it from keyboard.
What I tried so far:
Redirection to /proc/$$/fd/0, which didn't work.
Redirectiong currently active tty stdin to read, like so:
read -rsn 2 fraction < /dev/pts/0
which actually worked, but problem is that not all windows are terminal, e.g. web browser.
If my question is unclear, please feel free to ask for additional clarifications or details, and thanks in advance :)
You can use a named pipe for the process communication.
I made am example script where the background proces is a function.
#!/bin/bash
pipe_name=/tmp/mypipe$$
mkfifo "${pipe_name}"
resize()
{
read fraction < "${pipe_name}"
echo "Resize window to fraction=${fraction}"
}
resize &
read -p "Enter your fraction: "
echo "${REPLY}" > "${pipe_name}"
rm "${pipe_name}"
thank you both for providing very useful information. The solution is combination of both, actually.
First I modified read command in resize.sh to get input from named pipe, as Walter suggested, than I wrote a new, kinda "wrapper" script, which executes resize.sh in background, and than, since Barmar pointed I need a gui window, it starts very small terminal window running read and passing input to named pipe. Further more, using wmctrl I manage to place small terminal window right where currently active window begins, and hide it below (thanks to openbox per-application properties), so it's technically not visible at all :)
It's really too hacky for my liking, but it was really the only option I could think of at this moment, so until I find the better way, this gets the job done.
Once again, thank you both for directing me toward solution, I really appreciate it, cheers :)
Related
I have a Bourne-Again shell script text executable named engine.bin that I want to install.
If I install the executable manually ./engine.bin I get a screen with the EULA I have to accept (by pushing space), then accept it by writing yes and then enter the installation path by typing /usr/local/engine.
Now I want to do the installation automatically through provisioning scripts without manual interaction. Is there a way to do this? I do not know if the installer accepts any parameters, unfortunately the thing is undocumented.
Based on the suggestion of bill-agee and jgr208 I wrote the following which is working for me:
#!/usr/bin/expect -f
set timeout -1
spawn /tmp/engine.bin
expect {
-gl "*Press SPACE or PAGE DOWN key to continue, U or PAGE UP key to scroll back*" { send -- " "; exp_continue }
-gl "*yes/no*"
}
send -- "yes\r"
expect -gl "*press ENTER to accept the default*"
send -- "/tmp/tce\r"
expect eof
If the executable allows you to spam input at it without waiting for each separate prompt to appear, you might be able to accomplish this with bash.
For example, this script will run program_that_takes_several_lines_of_input.py and send it four lines of input - three with text and one blank line:
#!/bin/bash -eux
./program_that_takes_several_lines_of_input.py <<EOD
first line
one enter keypress later
yet another line of input after the empty line above
EOD
If you need to stop and wait for each prompt to appear, the cram Python package may be a good fit for this scenario - I find it useful for tasks like this where you only need to send a few lines of input, but each line of input is different.
See:
https://bitheap.org/cram/
https://pypi.python.org/pypi/cram
Expect would also work, but I find that I reach working solutions a bit faster when using cram than with Expect.
pexpect is a great choice as well! See:
https://pexpect.readthedocs.org/en/stable/
EDIT: I'm re-writing this because the first time was a bit unclear.
Let's say I have a program (an executable) such that when I run it, it prompts me to enter an input.
For example, I execute ./myProgram
and the program prompts: Please enter your username:
Here, I would type in my username.
Now, how would I write a bash script so that after I start the above program, I can enter inputs to it?
Something along the lines of this:
#!/bin/bash
path/to/myProgram
# And here I would enter the commands, such as providing my username
Thanks
reading values interactively is rather uncommon in *nix scripts, and is frowned upon by those who want to do exactly what you're trying to do. The standard way of doing this would be changing myProgram to accept arguments. At that point it's trivial to do this.
If you really need to use this pattern you need to use some tool like expect, as pointed out by #EricRenouf.
If myProgram reads from standard input, you can use a here-document:
path/to/myProgram <<\END
username
more input if needed
END
I'm teaching an introductory Linux course and have abandoned the paper-based multiple-choice quizzes and have created interactive quizzes in Bash. My quiz script is functional, but kind of quick-and-dirty, and now I'm in the improvement phase and looking for suggestions.
First off, I'm not looking to automate the grading, which certainly simplifies things.
Currently, I have a different script file for each quiz, and the questions are hard-coded. That's obviously terrible, so I created a .txt file holding the questions, delimited by lines with "question 01" etc. I can loop through and use sed -n "/^quest.*$i\$/,/^quest.*$(($i+1))\$/p", but this prints the delimiter lines. I can pipe through sed "/^q/d" or head -n-1|tail -n+2 to get rid of them, but is there a better way?
Second issue: For questions where the answer is an actual command, I'm printing a [user]$ prompt, but for short-answer, I'm using a >. In my text file, for each question, the last line is the prompt to use. Initially, I was thinking I could store the question in a variable and |tail -1 it to get the prompt, but duh, when you store it it strips newlines. I want the cursor to immediately follow the prompt, so I either need to pass it to read -p or strip the final newline from the output. (Or create some marker in the file to differentiate between the $ and > prompt.) One thought I had was to store each question in a separate file and just cat it to display it, making sure there was no newline at the end. That might be kind of a pain to maintain, but it would solve both problems. Thoughts?
Now to how I'm actually running the quiz. This is a Fedora 20 box, and I tried copying bash and setuid-ing it to me so that it would be able to read the quiz script that the students couldn't normally read, but I couldn't get that to work. After some trial and error, I ended up copying touch and setuid-ing it to me, then using that to create their answer file in a "submit" directory with an ACL so new files have o=w so they can write to their answer file (in the quiz with >> echo) but not read it back or access the directory. The only major loophole I see with this is that they can delete their file by name and start the quiz over with no record of having done so. Since I'm not doing any automatic grading, I'm not terribly concerned with the students being able to read the script file, although if I'm storing the questions separately, I suppose I could make a copy of cat and setuid it to read in files that they can't access.
Also, I realize that Bash is not the best choice for this, and learning the required simple input/output for Python or something better would not take much effort. Perhaps that's my next step.
1) You could use
sed -n "/^quest.*$i\$/,/^quest.*$(($i+1))\$/ { //!p }"
Here // repeats the last attempted pattern, which is the opening pattern in the first line of the range and the closing pattern for the rest.
...by the way, if you really want to do this with sed, you better be damn sure that i is a number, or you'll run into code injection problems.
2) You can store multiline command output in a variable without problems. You just have to make sure you quote the variable everafter to avoid shell expansion on it. For example,
QUESTION=$(sed -n "/^quest.*$i\$/,/^quest.*$(($i+1))\$/ { //!p }" questions.txt)
echo -n "$QUESTION" # <-- the double quotes are important here.
The -n option to echo tells echo to not append a newline at the end, which should take care of your prompt problem.
3) Yes, well, hackery breeds more hackery. If you want to lock this down, the first order of business would be to not give students a shell on the test machine. You could put your script behind inetd and have the students fill it out with telnet or something, I suppose, but...really, why bash? If it were me, I'd knock something together with a web server and one of the several gazillion php web quiz frameworks. Although I also have to wonder why it's a problem if students can see the questions and the answers they gave. It's not like all students use the same account and can see each other's answers, is it? (is it?) Don't store an answer key on the same machine and you shouldn't have a problem.
I've written a script (that doesn't work) that looks something like this:
#!/bin/sh
screen -dmS "somename" $HOME/somescript.sh
j=13
for i in {0..5}; do
screen -dmS "name$i" $HOME/anotherscript.sh $i $j
j=10
done
If I copy and paste this into a terminal, it creates 7 detached screen sessions, as I expect. If I run it from within a script, however, I get only the first session, "somename," when I run screen -ls.
I realize screen can be used to create multiple windows within one session. It doesn't really matter to me how these scripts get run. I just want to get to the bottom of why this doesn't work as a script.
Note: I've asked this question on SuperUser without any suitable responses. I figured maybe that's the wrong place to ask what could be considered a programming question.
One thing you might be getting bitten on is which specific version of which specific shell you're running. /bin/sh could actually be bash, or it could be bourne, and that can make a difference on how your loop syntax is interpreted. The {0..5} construct isn't understood in older versions of bash (v2.x), for instance, nor in bourne (at least it wasn't when I finally managed to track down a /bin/sh that was a real, live bourne shell :-).
My suggestion is to change your shebang line to /bin/bash if you need its syntax, and check that your bash is version 3.x or later. Since you say it works from the commandline, my bet is on the shebang line, though.
Let say, I access to a server using ssh. In the same time, there is another person accessing that server.
Is it possible to watch what is going on in that person's terminal. Meaning, Can I just watch what he is typing?
If the other person is using the Linux console, you can use conspy.
If you mean that the other person wants you to see his console, you two can use screen to share a terminal. See http://www.gnu.org/software/screen/manual/html_node/Multiuser-Session.html for a full description of how to do it.
I also use an approach similar to what Maze said. This is a unidirectional sharing with read-only for the guest. This is how it works:
1) The host starts the script command writing somewhere where the guest has read access and set the permits as required, for example:
$ script -f /tmp/shared_screen
Script was started....
$ chmod 640 /tmp/shared_screen
$ chgrp shared_group /tmp/shared_screen
The -f flushes the contents permanently so you'll have a very low delay
2) The guest starts dumping the content of the file:
$ tail -f /tmp/shared_screen
In this case -f causes tail to wait on more output from the file. Use ctrl-C to stop displaying the file contents.
You can use the small tool script for logging the terminal into a file. The observing party can simply tail -f that file to follow.
This is a much simpler approach, but it works very nicely for most cases
To capture what Alice types in a terminal,
and then the next day let Bob see what was typed --
without any risk of Bob accidentally typing anything into that terminal --
Alice can type "showterm" ( http://showterm.io ) in her terminal window to start the recording.
To share a terminal so Alice and Bob both see "the same" terminal window and can both type commands into that window,
there seems to be three popular methods:
Byobu, tmux, or screen.
(tmate is a fork of tmux that works just as well, perhaps better).
"How to Share a Terminal Session with Friends" (with Byobu)
"Sharing Terminal Sessions With Tmux And Screen"
"ask Ubuntu: Share SSH Session at login"
"Remotely Working Together on a Terminal Session in Linux" (with screen)
Ubuntu: "HOWTO: Connect to another user's console terminal using 'screen'"
"HowTo Share A Terminal Session Using Screen"
Something nice and easy:
watch -n 1 cat /dev/vcsa1
watch -n 1 refers for the time to refresh.
You can also try "cat /dev/vcsa1"
Well depending on whether its for 'live' or 'ondemand' purposes, you could replay it online with a service like www.playterm.org.
If you want to share a session on a machine behind a firewall or NAT, you can use the open-source terminal sharing program Termbeamer.