ron.stewart

@Vero Thanks; spot on. The apps showing in that manner definitely have the ".app" in the metadata display name. What's odd is that there doesn't seem to be much rhyme or reason as to which apps have it or why. They are all apps I've used for years (e.g., iTerm, Firefox, Google Chrome Canary, Atom, two different versions of Opera, three versions of Komodo) and it definitely isn't everything (e.g., Google Chrome doesn't have it, nor does Firefox Developer Edition). And it seems to be just one of my several Mac's (all running Sierra, all with Alfred) behaving in this manner. Reindexing doesn't seem to have addressed it, but this doesn't seem to be an Alfred issue. I'm sort of baffled by the sudden appearance of the results from deep inside the VMware Fusion VM's, as well. Where those folders live within my home folder, the only way I've found for them to not show is to uncheck "Include Folders in Home", but that has other obvious downfalls. It would be nice if I could exclude specific folders and their descendants from where Alfred provides results, but I don't see a way to do that; perhaps I'm just missing it? Thanks for your help, though Top notch, as always.

@GuiB Thanks for the response; on the first one, I've checked several of them that appear in that manner (with the .app) showing, and each does in fact have the "Hide Extension" checked. I can't find any applications that don't have it checked... so it seems like it has to be something else. On the second, I have "Include Folders in Home" checked (and I believe I have always have it checked) but today is the first time I've seen those results start showing up. I could uncheck that, but then I lose access to lots of stuff that I'd like to keep. They are both minor annoyances more than anything...

For some reason, Alfred has recently started showing a couple of things in its visible results that I would like to better understand how to control: 1. Some applications show with .app (see screenshot "a") but others don't. I don't remember /any/ of them showing that way until recently. Is there a way to control that? 2. Alfred has also started showing stuff from inside VMware Fusion VMs (see screenshot "b"). I definitely don't want that; can I exclude them somehow?

@deanishe: OK, now I think I get the idea of having the scripts in the workflow directory; @dfay touched on it in his response, above, too, but it didn't mean enough to me to pull that thread. I'm definitely still figuring this out, but I now have the bash scripts saved as separate files in the workflow directory and the "Run Script" action for each keyword just "dots" those scripts with {query} (e.g., something like . ./vm {query} to run my "vm" script to start and stop VMs with whatever other stuff I have included when I invoked it). Is that the approach the two of you were referring to? -- /ron

@deanishe: Thanks for the follow-up. I did decide to go with just bash, rather than either of the other two. I'm using "read -a" to explode {query} into an array of the arguments for use within the script, which makes migrating my scripts from use on a command-line into Alfred workflows really simple.

@dfay: Thanks for the follow-up, all good points. I'm definitely leaning toward the approach of having the scripts included within the workflow, just for my own sanity across my different systems. I don't envision distributing them publicly; these are likely so specific to how I configure and use my development systems that I can't imagine even co-workers finding them particularly valuable. There's an aspect of simplicity, too, to just running them via bash -- as opposed to using AppleScript to run bash scripts -- that appeals to me, as well. Fewer layers...

Caveat: I'm completely new to Alfred Workflows, so this is probably a really basic set of questions... Historically, I've created bash scripts to start and stop a variety of servers on my Macs which I use, in part, for Web application development. These servers might include virtual machines, different Tomcat instances, mail servers, etc. None of them run by default, and none run on low port numbers so none have to be started/stopped using elevated privileges. When I want to start or stop one or more of these servers, I open a terminal window and invoke my various bash scripts with needed arguments, etc. I would now like to set up Alfred Workflows for this same sort of activity, so that I can eliminate the step of having to open the terminal window. I've poked at the Alfred Workflows capability enough over the past couple days to figure out that I can get what I want in a variety of ways: 1. keyword/with space/argument required + Run NSAppleScript, where the AppleScript just invokes my existing bash scripts with the keyword arguments 2. keyword/with space/argument required + Run Script (/usr/bin/osascript), where the AppleScript again just invokes my existing bash scripts with the keyword arguments 3. keyword/with space/argument required + Run Script (/bin/bash), where I basically embed my existing bash script within the workflow and explode {query} to get the keyword argument available like the arguments I would provide to my existing bash scripts on the terminal command-line. I've convinced myself all of these approaches would work. My question is primarily related to the benefits and/or drawbacks of these different approaches: Are there performance differences or system impacts (speed, memory, other?) between these three approaches that I should consider in choosing one approach over the others? I understand, for instance, that the difference between 1 and 2 is that 1 runs on the Alfred thread, while 2 does not... but what does that mean in real terms for me and my system if the script takes a few seconds to complete? Does just embedding the bash script directly in the workflows help with efficiency/impact, as AppleScript is no longer in the picture? Does any of this really matter? Any insight and recommendations about the implications of the different approaches would be great. Thanks in advance. -- /ron