I'm currently working with Spring Shell. My problem is that whenever I print something to stdout, the program doesn't go back to the prompt unless the user presses the Enter button. Are there possible ways to invoke the prompt?
Max,
Since you have not provided any code, let me give you a couple of things to try. Instead of printing to stdout, you can return a string. There are disadvantages to this approach. You can try flushing stdout - System.out.flush(). Please see if either of these approaches work for you.
Sualeh.
Related
I need to run a shell script that should interact with couple of servers / routers in daily schedule. The script will simply login to the remote end, run a command. Up to here i hear that you are saying it is easy. The real problem here is that i need to analyze the output of the first command and based on the output i need to organize the second command. This is also doable, but the situation here is that i do not want to login and logout from the box for every command.
What i need is to login once, stay alive ,run the command take the output, analyze it and then run the second command later on logout and close connection.
Correct me if i am wrong but expect is not an option here. I want to ask for your suggestions.
Which language / module of this language i can use to complete this requirement.
Environment is not pure ssh, so i should have something general that can be used for both ssh/telnet.
Thanks in advance
Since you mentioned python, pexpect should do the job pretty well:
https://pexpect.readthedocs.org/en/latest/overview.html
I have a BASH script that runs on bg and print messages to the user when according to system events.
My problem is that after the echo of these messages, the user need to press on the ENTER key in order to get back to the prompt line.
Adding new line to the printed messages didn't help since it still comes from the bg and not from the user shell.
Does anyone have an elegant & simple solution to get the user back to the prompt line?
I will appreciate any help here..
You don't need to press enter to get to a prompt. You are still at the prompt that was there before the output was printed. Try just entering a command and hitting enter. (You can also hit ctrl-l to clear the screen instead of hitting enter to input an empty command.)
The problem here is that the background/alternative process has no relationship to the running shell session and so it is simply writing output to wherever the terminal sticks it. The process might be able to use control sequences to control the output location (but I don't know if this actually works).
Other than that there isn't much to be done about this that I'm aware of. And it isn't a problem in any real way.
I am using node.js to write a command line interface that generates unit test files. I have been using inquirer to get user input, however there is one field in which the user will very likely want to copy-paste and/or edit, large multi-line chunks of JSON data. Therefore, my goal is to:
open vim # certain point in CLI -> allow input-> close vim -> write out to tmp file -> process the result.
The problem is that input to vim is also going to the parent stdin, and when the return key is hit, the program continues on top of vim (mayhem). I'm fairly certain that stdio/in/out/err are not set up properly, but i cant seem to find the exact solution anywhere. Every iteration of my manipulating the streams seems closer, but i know that there is a small missing link.
i have tried a lot of things along the lines of:
var vim = child_process.spawn('vim', [path], {stdin: 'pipe', stdout: 'pipe', stderr: 'pipe'});
var vim = child_process.spawn('vim', [path], {stdio: 'inherit'}); //{stdio: ['pipe','pipe','pipe']}
Finally, i have followed a lot of the stdio manipulation from this example, How do I open a terminal application from node.js?, but there still remains some small missing link that i need help with
Notes:
I am 99% certain that my async promises are in order.
it doesn't necessarily have to be vim, as I am checking the ENV for
an editor first
I liken this to git commit, where an editor pops up and allows input
before closing
in a small test program, i can get perfect functionality, but when
trying to do this over another process, it doesnt go well
tl;dr : i want to ignore the parent process while input goes only to vim (child_process), but i cannot keep them separated, and because of this, the program goes haywire
If there is anything i can clarify, please let me know.
Thanks!
I know this is old, but anyway 6 days ago they released a function with 2015.02.06 Version 0.12.0 (Stable) that makes this very easy.
var spawnSync=require("child_process").spawnSync;
spawnSync("vim",[__filename],{stdio:"inherit"});
It will of course block the event loop, but in such a situation you likely want to wait for the user. Otherwise, you may end up with node writing to stdout and reading stdin while you are editing, which is obviously very confusing, and is the issue you were running into.
If you really still need asynchronous stuff while you are editing, it's probably easier to require("child_process").fork so you don't confuse the stdin/stdout. I imagine you could do some fancy stuff to remove all the listeners and add them back later, but it's probably not worth the effort.
It's common to use the command more. more is usually used with pipe. so I think more has the ability to read from stdin. every command separated by pipe is a process, and the one before more just create pipe and dup2 the write pipe to more's stdin. but I found that if I type "more" in the console, just some usages appear. so what is the matter?
Why do you think that anything is wrong? More pages output for the terminal so what would be the point in waiting for enough typed stdin input to page?
If you type more and one or more filenames it will page that input. So the behavior is something like:
am I attached to a terminal? ("isatty")
are there filenames in argv
page files
else
display help
else
page pipe input
It's a feature. It detects that its standard input is connected to a terminal, and displays a help message instead of proceeding. There is hardly a situation where it makes sense to run a pager on input while you are typing it in by hand. If you really actually want to, try cat | more for example.
For what's worth, I looked at the source package provided by the repositories in my linux distribution and found this:
if (!no_intty && nfiles == 0) {
usage(argv[0]);
exit(1);
}
So indeed the behaviour is to display the usage message if no input is detected.
We have a shell script that expects multiple user inputs to be entered when prompted. e.g
At first it may ask for the operation to be performed. When that answer is given, it may ask for username then password etc. We want to automate this task by providing the inputs using file redirection i.e.
script < input.
The input file will have all the answers for different questions that the script may ask. However it is not working and the shell script is reading only the first line of the input file. What do I need to change or use to make this work?
What you can use is the program expect. You create a script for it that tells it when to give what input to some command it executes. This way you can automate exactly the kind of thing you're struggling with.
More info on Google and here:
http://www.linuxjournal.com/article/3065
man page: http://linux.die.net/man/1/expect
You say 'it only reads the first line of input.'
So you have to kill the script?
Is there any output? (error messages especially)?
Are you redirecting STDERR to /dev/null or else where? If so, remove that.
Here is the hightest probability helper ... Modify the top-level script and add set -vx at the 2nd line. Then you'll be able to see what was processed, where it has stopped and possibly formulate theories about why it is not processing data.
Any chance that the input file was created in a Windows environment and the cr\lf pair is messing up the expected input?
I hope this helps.
Thanks all for commenting and answering. I tried except and that did not work. So I am going to mention what worked for us. Here was our workflow - 1. At the linux prompt, type the command, it was connect() in our case. 2. Once that command is given, the script would ask for parameters for the command like port number, server etc. we had to provide that manually 3. Then we again are presented with a shell prompt with another input. In our case, we were able to provide the first command connect() at the prompt using file redirection, but the parameter passing was an issue. The solution we found was provide the parameters inside the parentheses of connect only i.e. our input file for redirection would contain - connect(). This worked for us.