rice.shawn

You can give your regular account sudo access either with or without a password to specific commands.

I really wish that Apple would have just installed wget by default. Anyway, here is the adapted gist to use cURL rather than wget. #!/bin/sh #login using sessions/token # ** Replace YOUR_USERNAME and YOUR_PASSWORD below with your Tado credentials ** curl --header="Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" --data="j_username=YOUR_USERNAME&j_password=YOUR_PASSWORD" https://my.tado.com/j_spring_security_check --cookie-jar /tmp/tadocookie.txt -o /tmp/tadologin.out > /dev/null 2>&1 #Get the thermostat settings xml (inc temperatures) curl --header="Content-Type: application/x-www-form-urlencoded; charset=UTF-8" --header="X-Requested-With: XMLHttpRequest" --cookie /tmp/tadocookie.txt https://my.tado.com/mobile/1.4/getThermostatSettings -o /tmp/tadotemps.xml > /dev/null 2>&1 #Get out the temps from the xml THERMOSTAT_TEMP=$(cat /tmp/tadotemps.xml | jq -r '.temperatures.externalTempSensor') CONTROL_BOX_TEMP=$(cat /tmp/tadotemps.xml | jq -r '.temperatures.box') #Print out temps to 1 decimal place printf "Kitchen: %0.1f°C\n" $CONTROL_BOX_TEMP printf "Living Room: %0.1f°C\n" $THERMOSTAT_TEMP It **should** work, but it's not tested. I just redid the options to change them from wget to curl. But it also looks like you need jq installed. jq is a great utility to let you work with structured data (xml, json) from a shell. If you want to make this workflow available for distribution, then you should probably use some other sort of scripting language that supports structured data with minimal headache but use the same approach via storing cookies and setting headers.

You can also check to see if the code is still running. (Use ps and some identifier as to the language or script names that you're using and see if it's still there). As Dean mentioned, code is best in helping debug this stuff.

Okay, so I just uploaded a new version (1.3.2) that implements the two new options: (1) Press cmd + enter on a translation to open the Google Translate page in the browser. (2) Press opt + enter on a translation to listen to the audio of the translation. Note: audio translations are supported to about 100 characters according to what I found on the net, so it probably won't work well if you try to listen to more than that. Also, you can't change voices for the translations (they're just audio files that are downloaded from Google).

Actually, I just figured out how to grab the sound files, so "listen" should be possible.

By "Cyrillic > latin" do you mean just transliterating the text? That should be easy to do without touching the Google API. As for speak, I'm not sure if that is possible. If you could help me figure out an API endpoint where I could get the sound file from, then it would be possible.

Oh. Dammit. I used the wrong syntax for the user agent. Instead of useragent, it should be user_agent. I just posted a new version (1.3.1) that has the bug fix in it.

Did you have problems with it? What were the errors? The Alphred model is nice because it will also cache the translations.

Hm. The workflow needs to be redesigned (not necessarily completely rewritten) to accommodate this. I'll think of a way to make it happen and get back to you.

You can still call APIs and get the data and all that jazz, but you just have to do it synchronously rather than asynchronously. So, make sure that you get the data before you render any XML for a script filter.

For server, I'm not thinking a long running process, but something that acts more like a web-server but without the actual server. So that might not actually affect the way that Alfred is run. By tokens, I mean more like chunked text in that the text isn't really a set of characters but a unit as a whole (this is a bad analogy and explanation). I'm pretty sure that you can fake decorators in PHP. Ruby has decorators. The URL routing mechanism that I'm now thinking of this in is Rails' router. The last time I tried to write this class in PHP, I basically tried to make the entire multi-level menu be represented as a large associative array and that each endpoint ended up being a function that would be called. But that wasn't quite the right approach. I do heart Ruby, but PHP still has a lovely place in my heart. Also, since a lot of people seem to write workflows in PHP, having a solid PHP library for them to use and abuse seems productive. I have it somewhere on a todo list to, basically, port Alphred into Ruby as well as Bash.

It sounds almost like we're talking about creating a full local server for each workflow (which is a cool idea) where Alfred's search query is basically an address bar and one that has an internal history. Currently, we seem to use "autocomplete" and string matching to define the state, but this would add in something closer to tokens. I've toyed around with creating a class for Alphred that would dynamically generate multi-level menus, but the problem I ran into each time via conceptualization was the routing in that it always created more complexity than it was worth. Revisiting it with this thinking might be productive.

I'd say that it never will. Andrew tries to keep the size of Alfred small so that it keeps performing quickly. In order to do something like AJAX, he'd have to compile in all or part of a JS rendering engine (95% of which wouldn't apply to Alfred). What would you use the Ajax for with Alfred, anyway? Updating script filter results?

The hotkey is a neat idea. I just added it to the workflow and push an update (1.3) to Packal. Also, I rewrote getting / fetching mechanisms that should work with all versions. The configs did change a little bit, so you might have to reset them.

You can still access the keychain in Yosemite (and El Capitan), and this workflow seems to be doing just that in the second line of the AppleScript as it uses the `security` command from the terminal, which is the command to interact with the keychain.

Javascript is somewhat built into 10.10's and 10.11's AppleScript, which is why Alfred can support Javascript only for those versions.

But PHP's built-in date functionality is pretty damn elegant.

Is there something in the workflow that would be making that happen? Does it happen with other workflows in front of the terminal?

After you install the workflow, just open it up and look at the `script-filter.php`. You'll see that I've included a library called "Alphred" that I wrote that makes writing workflows in PHP much, much easier, and so that is what controls the output for the script filter. Here, the library just easily creates the XML that Alfred reads. The text to date functionality (for things like "now" or "tomorrow" or "+1 year") are built into PHP's date functionality. More specifically, they're built into the function `strtotime`, and so that does a lot of the heavy lifting. The actual conversion from Arabic to Roman numerals is done by breaking the date string (31/3/1999) into an array and then using an `array_filter` (which just applies the same function to each part). So, all we needed was a single function to convert an Arabic number to a Roman numeral. The function that does that is here: function toRoman( $integer ) { $output = ''; $conversion = [ 'M' => 1000, 'CM'=> 900, 'D'=>500, 'CD'=>400, 'C'=>100, 'XC'=>90, 'L'=>50, 'XL'=>40, 'X'=>10, 'IX'=>9, 'V'=>5, 'IV'=>4, 'I'=>1 ]; while ( $integer > 0 ) : foreach ( $conversion as $roman => $arabic ) : if ( $integer >= $arabic ) { $integer -= $arabic; $output .= $roman; break; } endforeach; endwhile; return $output; } So, basically it takes an associative array that defines the translations between Arabic and Roman and then just uses two loops to modify the input value while constructing an output string. Each time it adds onto the string, it removes the equivalent value from the input integer and just keeps going until the integer reaches 0 and then returns the string. Hopefully the explanation helps. I did decide to make it a script filter rather than using an Applescript input box because it makes it easier to manipulate the values quickly and see the results.

No. Alfred doesn't respond to gestures, only to keystrokes. Theoretically you could find something that would run an applescript based on gesture that would then trigger alfred, but that would add way more cruft to your system than what you're already using.

Yes it is. You can just use osascript from the command line: osascript -e "activate application \"Pages\"" -e "delay 1" -e "tell application \"System Events\" to keystroke \"n\" using command down" That script will open Pages, wait one second, and then send the keystrokes. You can change out "Pages" with the other app names, but make sure that you get them perfect because AppleScript is sensitive. You can remove the delay, but then keystrokes might be sent before the application is open.

I re-coded it in PHP and dropped it in a simple workflow that you can download here: https://www.dropbox.com/s/hihr5zl054wdq5u/Roman%20Date.alfredworkflow?dl=0. It works as a script filter and uses PHP's date parser, so you can do things like "rd now" and "rd tomorrow" and "rd next friday" and "rd -1000 years" as well as "Oct 29 1993" or "10/29/1993". Currently, if you press enter, it just displays it as large text.

Sorry for the delay, Walter. If Caffeinate is not running, then it will only show you ways to enable caffeinate (you can't disable it if it isn't running). If it is running, then you can "re-enable it" by entering a different argument, or you can disable it. Try typing `caff e` and pressing enter and then typing `caff d`, and you should see the difference. The prompts will always be the same regardless of the options you set. If you want to verify exactly what arguments are being sent then change the options and enable caffeinate via the workflow, then open a terminal and type ps aux|grep caffeinate|grep -v grep and you should see the command line argument sent in order to enable caffeinate. The different options are just more about what caffeinate doesn't allow to go to sleep. My assumption is that users would want to set this once and never worry about it again because it's more of a general preference in how you want to keep your computer awake. Adding those options to the prompt would have added a lot more complexity to the code as well as the user interaction.

It's been working just fine for me as well for the last week since I upgrade.

Nope. That turns out not to be just on your end but on everyone's end. I had overlooked that part. Anyway, I just put in a fix. v3.03. Is available to fix that.