I'm not really familiar with the Scala language at all, but it looks like the script is only built to take user input for the password, not arguments or stdin
, which is what's required for Automator to pass it data.
The shell that Automator runs scripts in is non-interactive, so your script can't directly prompt the user for a password. If you can rework your script to take a password via stdin
, you could use an AppleScript wrapper to get a password dialog, if that's what you're hoping for.
If you rework your pgpsign
script to take a password from stdin
, you can use an Applescript action (with some shell scripting embedded) to display a password dialog and get the results you desire.
Replace your Run Shell Script action in your current workflow with a Run AppleScript action, with the following code:
on run {input, parameters}
set thePath to quoted form of POSIX path of first item of input as string
tell application "System Events"
display dialog "Password:" default answer "" with hidden answer
end tell
set pass to text returned of result
do shell script "cd " & thePath & "; echo " & quoted form of pass & " | perl -ne 'chomp and print' | ~/scripts/pgpsign"
end run
It's not the most straightforward, so I'll run through line by line what it's doing.
on run {input, parameters}
set thePath to quoted form of POSIX path of first item of input as string
This gets the input from the service (the folder you selected) and turns it into a string that the shell script can make use of.
tell application "System Events"
display dialog "Password:" default answer "" with hidden answer
end tell
set pass to text returned of result
This pops up a password dialog and stores the result to the pass
variable. Ordinarily in AppleScript you don't need the System Events
tell portion, but because of some quirks with Automator, it's required here.
do shell script "cd " & thePath & "; echo " & quoted form of pass & " | perl -ne 'chomp and print' | ~/scripts/pgpsign"
This ties it all together and sends the required parameters to your script. First we change to the selected directory (to answer your question in the comments, as your script is written, it is necessary to first cd
to the directory you want). Then echo
is used to send the password to stdin
, and it's piped through the perl portion to strip the trailing newline (which is an annoying characteristic of AppleScript and would otherwise cause a valid password to fail), then piped to your script.
Sorry for giving you a lot to digest, but if you want to use Automator for this, it's probably the easiest way, unless you want to hardcode your password (which is obviously inadvisable for security reasons).
Your app does start the process and then quits itself straight away leaving the process running.
You could try and check in the Automator action to see if the process is running. if it is quit it, if it is not launch it.
isRunning=`ps aux | grep -i "Textedit.app"| grep -v grep`
if [ $isRunning -eq "" ]; then
echo "is Not Running"
/abspath/to/my-command
else
echo "is Running"
# terminate code here
fi;
So when you click the App in the Dock. to will either start the process or stop it.
Best Answer
Having read through the Services Implementation Guide I'm going to have to say no to using only a shell script. If you do not want to use Automator then you'll have to create a Service using Xcode and unless you can perform that level of programming, then Automator, as slow and clunky as it may be, is looking pretty good.
Just for the heck of it, I took what I learned from reading the Services Implementation Guide and was able to manually wrap the shell script in an application bundle with an appropriate Info.plist file that did make an entry on the Services menu in Finder as I coded in the .plist file. However, that's were things stopped as there was no mechanism within to pass what was selected in Finder to the shell script, masquerading as a Service in this case, like what the Automator Service takes care of automatically without one having to resort to Xcode.
In closing... Automator, as slow and clunky as it may be, is the easiest way to create a Service for the non-programmer average everyday user of OS X.