Jump to content

Search the Community

Showing results for tags 'cli'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Alfred 3
  • Make the Most of Alfred
    • Discussion & Help
    • Bug Reports
    • Alfred Feature Suggestions
    • Themes
  • Alfred Workflows
    • Share your Workflows
    • Workflow Help & Questions
  • Alfred v2 Themes
  • Alfred Remote for iOS
    • Alfred Remote Discussion & Help
    • Remote Connection Troubleshooting

Categories

  • Articles
    • Forum Integration
    • Frontpage
  • Pages
  • Miscellaneous
    • Databases
    • Templates
    • Media

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Twitter


Website URL


Jabber


Location


Interests

Found 7 results

  1. Alfred - Terminal and iTerm2 Control Workflow Works with Alfred 3 Quick Start: Download Here (Alfred 2 users, the last compatible version was Terminal Control 2.2, still available here) An Alfred workflow for controlling aspects of Apple's Terminal Utility and iTerm2. Designed specifically for developers and admins who spend a lot of time in terminals at the command line. Particularly useful for those who manage multiple tabs and use varied Profiles (color themes) for Terminal/iTerm2 windows. New Terminals The keyword trigger term (or iterm) will bring up a list of Profiles (themes/skins) based on Terminal preferences. Continue typing to select one. Modifier keys: Shift: launch this Profile in a new tab Command: change the active Terminal tab to this Profile Merge and Split Terminal only: Keyword trigger term move will separate the current tab into its own window. Terminal only: Keyword trigger term merge will merge all open Terminal windows into one tabbed set. iTerm Only: Keyword trigger *iterm arrange* will call iTerm's "arrange all windows horizontally" window helper. Terminal to a Directory Keyword trigger term dir (or iterm dir), followed by a directory search phrase will launch the default Terminal profile, and automatically change to the selected directory. Why Do I Want This? I spend a lot of time connected to various processes, machines, networks, running screen/tmux sessions, etc. From my personal experience (read: typing the wrong command into an ssh session of a production machine and taking down large consumer web properties in the process), I've built a habit of always color-coding my terminal windows. White on black for local OSX terminal. Green on black for local virtual machines, green background for testing networks, and RED background for production machines (a constant reminder to be careful what I type). This alfred workflow allows me to launch terminal themes, and also change a terminal tab quickly to a new theme if I repurpose it for a new task. Install Notes Download the compiled workflow directly, or visit the repository for the full source code This is my very first workflow, so I'd appreciated feedback on the installation process. In theory, I've bundled all the necessary ruby gems in the workflow package proper, so it should be a simple double-click install. If you do need to install manually, please let me know. Hints are in the developer notes. You will need to allow accessibility support for Alfred. This should be prompted automatically. But since Mavericks, this happens in a new place, in the security and privacy system preferences area. Enable it as shown here if you get stuck: Thanks to Bryan McKelvey for the simple Alfredo Ruby Gem Thanks to phyllisstein for Alleyoop Thanks to Quentin Stafford-Fraser for inspiration and approach in his dedicated iTerm2 Profiles workflow Release Notes v1.0 (May 6, 2013) - Initial release v1.1 (May 10, 2013) - Support for Alleyoop workflow updater v2.0 (May 12, 2013) - Added control for popular alternative iTerm2 terminal emulator v2.1 (Nov 7, 2013) - Included bundled gems for ruby 2.0.0 for Mavericks OS X 10.9 Support v2.2 (Nov 21, 2014) - Improved UI scripting dialog to conform with 10.9+ privacy behaviors v2.3 (Jun 23, 2016) - Support for iTerm2 version 3.0.0+ to accommodate their new AppleScript dictionaries, dropped support for Alfred 2.x v2.4 (Oct 15, 2017) - Included bundled gems for ruby 2.3.0 for macOS High Sierra 10.13 Support v2.5 (Sep 29, 2018) - Support for macOS Mojave 10.14 Feedback Wanted: I'd love to hear feedback. Are you using this workflow? How? What improvements would you like?
  2. Introduction Alfred workflows are simply zipped directories with an altered extension. Those are great news if you want to automate packaging your workflows for distribution, as you can simply (using ditto in this example, but zip would work just as well): ditto -ck "{{/path/to/your/workflow_directory}}" "{{/path/to/your/output_file}}.alfredworkflow" And that’s it. A zipped directory of your workflow with the custom .alfredworkflow extension. Names enclosed in double curly brackets are examples (they dependend on your situation and must be edited accordingly). Problem The trouble with that solution is that it packages your workflow as it is. Most of the time that won’t be a problem, but it becomes one when you have Workflow Environment Variables with “Don't Export” activated. Alfred knows not to save the value of those variables when exporting your workflow, but your zipping utility does not. Because of that, if you want to package your workflow yourself you need to set those variables (and only those) to empty values. Solution # You need only set these two variables, and the rest will work as is readonly workflow_dir="{{/path/to/your/workflow_directory}}" readonly output_file="{{/path/to/your/output_file}}.alfredworkflow" if /usr/libexec/PlistBuddy -c 'Print variablesdontexport' "${workflow_dir}/info.plist" &> /dev/null; then readonly workflow_dir_to_package="$(mktemp -d)" cp -R "${workflow_dir}/"* "${workflow_dir_to_package}" readonly tmp_info_plist="${workflow_dir_to_package}/info.plist" /usr/libexec/PlistBuddy -c 'print variablesdontexport' "${tmp_info_plist}" | grep ' ' | sed -E 's/ {4}//' | xargs -I {} /usr/libexec/PlistBuddy -c "set variables:'{}' ''" "${tmp_info_plist}" else readonly workflow_dir_to_package="${workflow_dir}" fi ditto -ck "${workflow_dir_to_package}" "${workflow_file}" So, what does this do? Check the info.plist in your workflow directory for the variablesdontexport property. If the property does not exist, package your workflow directory without any modifications. Our work is done. If the property exists, copy your entire workflow to a temporary directory (we’ll make changes to the info.plist and don’t want to do them on our current one). Check every variable in variablesdontexport and set them to empty values in the info.plist of the copied directory (we don’t want to outright delete the variables as the reference would be lost as well). Package the copied directory. Our work is done. Solution as a script #!/bin/bash readonly workflow_dir="${1}" readonly info_plist="${workflow_dir}/info.plist" if [[ "$#" -ne 1 ]] || [[ ! -f "${info_plist}" ]]; then echo 'You need to give this script a single argument: the path to a valid workflow directory.' exit 1 fi readonly workflow_name="$(/usr/libexec/PlistBuddy -c 'print name' "${info_plist}")" readonly workflow_file="${HOME}/Desktop/${workflow_name}.alfredworkflow" if /usr/libexec/PlistBuddy -c 'print variablesdontexport' "${info_plist}" &> /dev/null; then readonly workflow_dir_to_package="$(mktemp -d)" cp -R "${workflow_dir}/"* "${workflow_dir_to_package}" readonly tmp_info_plist="${workflow_dir_to_package}/info.plist" /usr/libexec/PlistBuddy -c 'Print variablesdontexport' "${tmp_info_plist}" | grep ' ' | sed -E 's/ {4}//' | xargs -I {} /usr/libexec/PlistBuddy -c "Set variables:'{}' ''" "${tmp_info_plist}" else readonly workflow_dir_to_package="${workflow_dir}" fi ditto -ck "${workflow_dir_to_package}" "${workflow_file}" echo "Exported worflow to ${workflow_file}." To use that script, give it a single argument: the path to the workflow you want to package. It’ll save it to the Desktop with the name automatically determined.
  3. I love Packal, and I’ve grown to like awm, the CLI tool by Jonathan Wiesel. The response was not exactly overwhelming when Jonathan pushed awm out three years ago. But that was 2014, and since then CLI tools have gotten some traction, and today they are considered sexier than ever (I think). Anyway, I can’t stop dreaming of a version of awm that is ready for the year 2017. As a humble first step, I’ve just finished up three tiny PRs. They do absolutely nothing but remove the gunk from the `npm install` process. But hey, it’s a start! Regards, Claudia
  4. Terminal Green 1.0 Terminal White 1.0 Terminal Orange 1.0
  5. Hi! I have been a user of Alfred (+ Powerpack) for years, but only recently decided to invest more time into customizing it with the workflows I thought were helpful. As I am a software developer, I generally setup any new Mac OSX environment using a completely automated installer: https://github.com/kigster/pullulant I wanted to add to Pullulant a simple bash script for installing Alfred. I can install the software itself using Homebrew, and then I was hoping to download and install my favorite workflows. I have now spent over an hour searching online, and I am absolutely stunned to find out that Alfred, the supposedly tool for automating your OS-X life, is itself so difficult to automate!!! What I want is a single line command I can run in Terminal (or iTerm, i.e. bash), that tells Alfred to import the given workflow. Since Alfred insists on choosing a category for a workflow (which is completely useless in my opinion), I would imagine that this command would need to tell Alfred what category to assign it. Right now I am able to do this: open $(curl -s -L -O -w %{filename_effective} \ https://github.com/packal/repository/raw/master/com.alfredapp.mdeboer.atom/atom.alfredworkflow) And as you would expect, curl downloads the file, OSX then opens Alfred, which then stays open like a village fool waiting for me to choose a category for it, and I can't, for the love of life, my laptop or the universe, find a way to make this entire process non-interactive, so that I can run it in a goddamn loop and be done with it. Why!? Why is it so hard? LOL. Cry. LOL. Cry. Sorry, it's very late, and I am getting a bit delirious. I do not mean to offend anyone, I just hoped that I could find a solution without having to post a new question in the forum, because even after searching this entire forum for "install", "command line", "bash", "terminal", "non-interactive" I found nada. Your truly, Konstantin https://github.com/kigster
  6. Note: This is not a workflow, but a helper CLI (command-line utility) geared toward Alfred users who manage development of multiple workflows intended for sharing. I suggest installing via the npm registry, if you have Node.js installed - if not, consider installing it just to benefit from its great package manager, npm; try curl -L http://git.io/n-install | bash ): [sudo] npm install -g awf Alternatively, here are instructions for manual installation. Note, however, that the npm-based installation makes updating to a newer version much easier. Below is a high-level overview; you can find the full manual in the repo's Usage chapter, or, once installed, you can execute awf help (concise overview), awf help all (full manual), or awf help <sub-command>. ------ awf (Alfred Workflow) is an OS X CLI for managing and assisting in the development of workflows for command-line launcher Alfred 2. It comes with a broad range of features: Note: Some features related to Alfred Preferences.app involve GUI scripting and therefore require that the application running awf - typically, Terminal.app - be granted access to accessibility features - you will be prompted for authorization on first use; for more information, see Apple’s support article on the subject. Retrieving information about workflows List all workflows or workflows matching a filter, optionally with selectable output fields.awf list -s i net.same2u. # list matching workflows by bundle ID substring Print information about a given workflow.awf info net.same2u.speak.awf Locating workflows Locate a workflow’s installation folder by its bundle ID.awf which net.same2u.speak.awf # prints installation folder path Reveal a workflow’s folder in Finder.awf reveal net.same2u.speak.awf Trigger a keyword search for workflows in Alfred Preferences.awf search speak Editing workflows Change to a workflow’s folder in Terminal.awf cd net.same2u.speak.awf # opens a tab in a new window Open a workflow in Alfred Preferences for editing.awf edit net.same2u.speak.awf awf edit # from a workflow source folder Installing and exporting workflows Install a (copy of a) workflow from a source folder.awf install . Export a *.alfredworkflow archive from a source folder.awf export . # exports to '*.alfredworkflow' in same folder by default Developing workflows Note: The purpose of the following features is to allow you to store workflows being developed in a separate location instead of directly among the installed workflows. A symlink to the dev location placed among the installed folders ensures that you can still use and develop the workflow from within Alfred and Alfred Preferences. These features move directories, create symlinks, and delete files. Care is taken not to accidentally overwrite or delete files, but use these features with caution and always create backups. Symlink a dev folder (source folder) into the folder of installed worklows or remove a dev folder’s symlink.awf link . # effective installation without moving the directory awf unlink . # remove a symlink - effective uninstallation Move an existing, regular workflow to a dev folder in a different location and replace the original workflow folder with a symlink to the dev folder.awf todev net.same2u.speak . # move to current folder and perform 'awf link' Conversely, move a dev folder back to the folder of installed workflows as a regularly installed workflow.awf fromdev . # -k keeps the source folder Manage workflow version numbers via file version.awf version patch # bumps the patch component of the workflow's version number
  7. This was now consolidated into RunCommand, so you should download that instead.
×
×
  • Create New...