Bash: Passing Output to another programs Input?
 

Hello,

I am not sure if that Subject really explains it, basically I have a script that executes a CLI java-applet that requires a passphrase from the user. I can easily execute this by issuing the -p argument followed by the passphrase however that shows up on possible logs or at least on the results of the ' ps ' command. If you do not supply this -p argument it provides a new line with the echo " Enter Passphrase: " and asks for input.

My question is how can I provide a result/input for the Passphrase request and is it still possible to throw this application in the background with the ' & ' following the command?

I have seen a few examples that show a /bin/expect that expects a result and sends a command however I would like to refrain from any extra dependencies.

Example of Regular Execution of application:
Thank you for any suggestions/comments.

Something like this might work:

/usr/local/***/**** -u USERNAME -r Default-Realm -f certificate.der <<EOF
password
EOF

Note that here you type the actual password instead of "password". This is a common way of passing passwords but has a couple of downsides:
1) You have to store the password in your script so anyone who can read the script can find out what the password is.
2) If there is a timing issue (e.g. the "password:" prompt doesn't appear before you pass in the password) then it fails. You can try adding a sleep statement before the password.

The expect command you don't want to use gets around the latter because you can tell it to explicitly wait until it sees the "password:" prompt before it tries to pass in the password.

This does seem to work, however I have ran into a few problems with this solution unfortunately.

One being the fact that it does not seem to allow variables to be inserted it takes it as a string itself, is there some sort of a break-command or way to issue the multi-line insert with variables?.

The other being that it doesn't appear there's an easy way to push the process into the background while still pass this information to it.

The reason for refraining from adding any extra dependencies is due to the fact that this will be a widely distributed script for ease of obtaining an SSL Certificate and connecting to an SSL-VPN connection. I imagine a more power language can handle all of this such as Perl but I figured a light-weight script would be easier and smaller to pass to a wide variety of boxes.

you cannot easily guarantee what you are trying to achieve.

if a program uses isatty(3) it can tell it's not a terminal.
you can't fool it so easily.

this sort of thing is poor practise anyway.
there is probably a correct way of doing whatever it is.

If it allows you to specify "-u" for username does it allow you to specify "-p" for password? You might not need to do all the rest of this.

Also it might even have something like "-u username:password" that allows you to pass in the password at same time as username.

That's the problem, as described in the first post if I do include this -p argument if someone views the running processes they can view this persons passphrase in plain-text which is the problem itself.

I am not sure what you're exactly indicating is poor-practice, I assume the Multi-Line <<EOF method of passing the information. If this is not correct, I am curious what is poor-practice so I can change this to a better method.

I am not familiar with this ' isatty ' however I will try to look into that to see what you're describing.

Thanks for the input so far.

He is saying it is poor practice for the downside reasons I'd indicated. He is saying it would be best if the utility you're using had a way to do automated logins (e.g. something like the way ssh trusts work) so that you're not ever exposing the password at all.

Given the issue with the tty it seems you're going to end up having to use expect.