Jump to content

deanishe

Member
 View Profile  See their activity

  • Posts

    8,759

  • Joined

  • Last visited

  • Days Won

    522

 Content Type 

Everything posted by deanishe

  1. deanishe
    Or read the password from STDIN instead of ARGV. That's how it's usually done in command-line programs. Keychain is definitely the best way, though, if there can be a "best way" of messing with an application's private data while it's running.
  2. deanishe
    You aren't escaping the input. Any password with ' in it will cause the script to die in flames. I also have to question the wisdom of saving a password in a script. That's a great way to accidentally upload sensitive data to GitHub. Finally, if you pass it a password on the command line, you're just swapping a password in your clipboard history for one in your shell history. The proper solution would be to file a feature request for an alternate Hotkey that copies text without remembering it or the ability to delete entries from the history via Alfred.
  3. deanishe
    Which password program are you using? Properly written ones mark copied passwords as sensitive and Alfred doesn't remember them in the first place. Editing Alfred's (or any app's) internal data is not a particularly smart thing to do.
  4. deanishe
    It's the Python/Sierra issue. Run the bugfix workflow.
  5. deanishe
    Yeah, definitely. I gave it a try, too, and it's very helpful getting stuff lined up properly.
  6. deanishe
    Looking at the docs for the bear:// URL scheme, the search endpoint doesn't actually provide a way to get search results from the app (i.e. there's no x-success parameter to return anything). All it does it show the search results in the app itself. If the app doesn't have an AppleScript dictionary, your only realistic option is to access its datastore directly. If it's based on CoreData, which is likely, it's using sqlite3 under the hood, which means you can pull data straight out of its datastore, like this OmniFocus workflow does. The advantages of that method are that it doesn't activate the application and it's stupendously fast compared to AppleScript. Like, insanely fast. The disadvantages are that it's fairly complicated to do (compared to using AppleScript) and the database layout may change at any time, breaking your workflow.
  7. deanishe
    No, you can't use Alfred's URI scheme. As it says in that thread, it's for importing/exporting web searches. It's not connected to workflows in any way. In theory, @Andrew could add the ability to call workflows' External Triggers via the URL scheme, but as @vitor said, it's a sucky way to do automation on macOS. It's a nasty hack for iOS, where there is no real system for inter-app communication. macOS does have one. Unfortunately, an awful lot of iOS developers don't bother to implement an AppleScript dictionary in their macOS versions (it is a lot of work, to be fair), leaving you with the ghetto IPC that is x-callback-url. You can use the xcall program to get a response from an x-callback-url call, but it probably won't work very well in many cases: calling an x-callback-url tends to activate the associated application, which will also hide Alfred. If you're after showing search results in Alfred, you'll probably have to re-open Alfred yourself by calling an External Trigger in your own workflow.
  8. deanishe
    I think you may have misunderstood how x-callback-url works. It isn't HTTP. It is implemented by iOS/macOS, and the system handles the calls. An app registers a URI scheme, e.g. bear://, and when you call such a URI via macOS, it directs the call to the registered application. As I understand it, you also do not get a response from the application. What you do instead is pass an x-callback-url for the application to call with the result, i.e. it calls your app back with the result. As such, you need to create your own app that registers your own URI scheme.
  9. deanishe
    I'd be a bit more explicit, tbh. Mention that the command is thus completely outside of Alfred and can't pass anything to subsequent elements. Perhaps link to a proper explanation on alfredapp.com.
  10. deanishe
    Not really. The general problem with using the titles of menu items is that it's automatically broken on every system not using the same language as yours. As such, it's fine for customising your own machine, but a bad idea for something like Alfred workflows, which are designed to be shared.
  11. deanishe
    Use a File Action. I do something similar if I want to start an application using a German locale.
  12. deanishe
    Ah right. I misread the log. I thought "Script response with argument …" meant "script responded with argument …"
  13. deanishe
    So that's Alfred removing the Script Filter output? I did wonder how you were getting an arg out of a Script Filter with no items…
  14. deanishe
    Awesome! If I had one wish for the debugger, it would be a "show everything but the JSON" option. It's important to be able to see the JSON when you need to, but if that's not what you're interested in, the sheer volume of output from some Script Filters overwhelms the rest.
  15. deanishe
    Pipes work fine. Any script output to STDOUT will be passed as input to any downstream Post Notification output. You're probably doing something wrong, like printing an empty line that's causing your actual message to disappear.
  16. deanishe
    I was trying to figure out where the trailing whitespace in my Script Filter query was being stripped (Alfred, my library, the CLI-argument-handling library). I hadn't realised that Alfred only logs output (seeing as Script Filters are about the only element that don't necessarily accept the output of another element). It would be helpful if Alfred also logged the input to elements that aren't consuming the output of other elements, especially now Alfred has different modes for handling whitespace in input. Not that it's a particular chore to add echo "query='$1'" >&2 manually. (In this case, I'd failed to fully recompile the program after removing my own trim command.)
  17. deanishe
    No, that's how version 1 worked.
  18. deanishe
    It's almost impossible to say with so little information. Please provide a detailed description of your problem, otherwise it's unlikely that anyone can help you.
  19. deanishe
    Don't know. Certainly, you don't need to with HFS-formatted drives, but I don't know much about NTFS-formatted ones. In any case, macOS does have a habit of indexing non-native volumes differently.
  20. deanishe
    Alfred v3.4 [843] Selecting "All information" in the debugger doesn't show the input passed to Script Filters.
  21. deanishe
    If you try to change the network settings via a script, macOS will require your password. It's a basic security feature. If you don't want to be asked for your password, you need to create a privileged helper program, which will require you to enter your password to install it. It might also be possible to enable your script to work by editing the sudoers file.
  22. deanishe
    Nope, sorry. The iTunes script works for me.
  23. deanishe
    Don't use Run NSAppleScript. Use a normal Run Script action instead, with Language set to /usr/bin/osascript (AS).
  24. deanishe
    https://discussions.apple.com/thread/3236464?start=0&tstart=0
  25. deanishe
    Yeah. In the first version mailto was the keyword for sending. And then I realised that it should be @.
×
×
  • Create New...