robotspacer Posted February 6, 2014 Share Posted February 6, 2014 I'm trying to keep my workflow self contained, if possible, by including a shell script inside the workflow's folder. If I use the "Run Script" action this works fine, because the working path is already set to the workflow's folder. But "Run Script" doesn't work well. If something fails there's no good way to see the output—a notification shows the first line or two instead of the last—and in some cases my script needs to prompt for a password.If I use the "Terminal Command" action it solves those problems—it runs in a Terminal window so I can see all the output and enter my password if necessary. The only problem is I can't figure out how to call my script—unless I hard code the path to the workflow's folder of course. Currently my script is: ~/Library/Application\ Support/Alfred\ 2/Alfred.alfredpreferences/workflows/user.workflow.406901EC-104D-1B51-5C20-1E588DB2D207/archive.sh {query} I've tried: ./archive.sh {query} But that fails because the script isn't in my home folder. So I guess I need something like: {workflow-folder}/archive.sh {query} Is there some way to do this, or is it just not possible? Link to comment
rice.shawn Posted February 6, 2014 Share Posted February 6, 2014 I think the bash command that you're looking for is pwd. If you want to get it as a variable: dir=`pwd` Then : "$dir/archive.sh {query}" should run the command. Just play around with the syntax. Link to comment
robotspacer Posted February 6, 2014 Author Share Posted February 6, 2014 The problem is the working directory isn't what I want. The Terminal Command action doesn't set the working directory—it basically just opens a Terminal window and enters the command you gave it. That means the working directory is just /Users/name rather than the workflow's folder. That said, I can use your suggestion to piece together the entire command in my Script Filter, and pass the whole thing as the argument. It's messy though, and I'm worried some characters may not get escaped correctly. It'd be a lot nicer if I could just reference the workflow folder path from my Terminal Command action. Link to comment
jdfwarrior Posted February 7, 2014 Share Posted February 7, 2014 The problem is the working directory isn't what I want. The Terminal Command action doesn't set the working directory—it basically just opens a Terminal window and enters the command you gave it. That means the working directory is just /Users/name rather than the workflow's folder. That said, I can use your suggestion to piece together the entire command in my Script Filter, and pass the whole thing as the argument. It's messy though, and I'm worried some characters may not get escaped correctly. It'd be a lot nicer if I could just reference the workflow folder path from my Terminal Command action. Is the terminal command what you are really looking for in this situation or would a Run Script be more appropriate? The Run Script item will allow you to run the command in the background with the workflow directory being the context/directory that the script is run in. Link to comment
robotspacer Posted February 7, 2014 Author Share Posted February 7, 2014 Is the terminal command what you are really looking for in this situation or would a Run Script be more appropriate? The Run Script item will allow you to run the command in the background with the workflow directory being the context/directory that the script is run in. As mentioned, Run Script doesn't seem to work well in this case. Basically what I'm doing is running a script that uses xcodebuild and a few other commands to archive and export an app using Xcode. There are a few different issues: xcodebuild generates a LOT of output. I can't find anyway to use Run Script and display the output in a useful way. "Large Text" gives a screen full of tiny text, and a notification gives the first couple of lines. (If it were the last couple, that might work, but still not great.) It takes a while, so I'd rather see the output as it runs than at the end—otherwise I'm just waiting a while and assuming it's actually working. There's one case where I need to prompt for a password—though I actually wouldn't mind changing this if I could find a solution for the output problem. Link to comment
rice.shawn Posted February 7, 2014 Share Posted February 7, 2014 There are a few options for this. If you want to see the output in the terminal, then you should go ahead and do the script filter approach because the script filter executes in the workflow directory; whereas the run terminal command opens to the default place, which is, usually, the user's home directory. Hence, you'd have to get the directory from the script filter. Another option, if you want, is you could save the path in a text file somewhere, and then you could get the contents of the file as a variable (just use var=`cat /path/to/file`). Look for the "open finder window in terminal/iterm" workflow here. What it does is grab the path of the finder window, then open terminal, and then pipe a change directory command to the terminal. You could always go with that if you want to see it in the terminal. Another option would be to run it as a regular bash script and to capture the output as a log file somewhere, and, then, after the process is done running, it could just open the text file in whatever viewer you want. If you just want to see the text quickly, you could just use the quicklook debug mode (if you can't find that on the net, then grab my workflows help workflow and take a peek into the code). You could output it as an html file that has an embedded javascript to refresh the file every few seconds or so. Or you could write it similarly, but to reload the contents of a div from the text file itself. If you need the password, the easiest way to get around the password is to modify your sudoers file to allow your user account to execute the command with sudo but no password. If you want a safer way to do this, then grab my "sudoers" workflow, which will make sure that you don't break the sudoers file. So, here you have options. One nice thing, however, about sending the output to a file is that you will have a record of each build that you can look back on for debugging purposes. Also, if you want to execute it in a terminal but then be able to close the terminal without killing the process, look into disowning the process. robotspacer 1 Link to comment
robotspacer Posted February 7, 2014 Author Share Posted February 7, 2014 Awesome, thanks for all the suggestions. I like the idea of outputting to a text file. qlmanage didn't work too well for me, but that gave me a great idea. I put together this AppleScript: on run argv if argv is not null then set errorTitle to item 1 of argv if the number of items in argv is 1 then display notification with title errorTitle else set errorMessage to item 2 of argv display notification errorMessage with title errorTitle end if end if return end run So I can call that at various points in my script: osascript notification.scpt "Archiving $SCHEME" "See output at $OUTPUT_FILE" That way I know everything is working and I can see when it's done. If it fails I can check the output file for details. I've also put together an AppleScript I can call with osascript to show an error message and then "do shell script theScript with administrator privileges" as needed. That makes for a much nicer workflow than opening Terminal. Thanks again for the help! Link to comment
rice.shawn Posted February 7, 2014 Share Posted February 7, 2014 Nice. I think I might be able to reference some common saying about cats and skinning them, but that might be a bit too vulgar. What you put together sounds like a great way to proceed. Link to comment
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now