Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running commands from Alfred #2638

Closed
bmikaili opened this issue Jul 10, 2019 · 16 comments

Comments

Projects
None yet
4 participants
@bmikaili
Copy link

commented Jul 10, 2019

Anyone have an Applescript to run commands from Alfred in Alacritty?

@chrisduerr

This comment has been minimized.

Copy link
Collaborator

commented Jul 10, 2019

What exactly are you trying to achieve? Do you want to execute arbitrary commands in Alacritty right at startup? You can do that with the -e option.

@bmikaili

This comment has been minimized.

Copy link
Author

commented Jul 10, 2019

No, Alfred has a function where you can enter a command and that command will be run in the terminal. So it works as if I would enter a command in spotlight and it gets run in the terminal.

The applescript would look something like this:

on alfred_script(q)
	tell application "Alacritty"
  		activate
 	 	do script {q} in front window
	end tell
end alfred_script
@chrisduerr

This comment has been minimized.

Copy link
Collaborator

commented Jul 10, 2019

I don't think that's possible. Alacritty does not have applescript support and I see little reason to add it personally.

@deanishe

This comment has been minimized.

Copy link

commented Jul 10, 2019

You might be able to get it to work with the AppleScript do shell script command. Something like:

on alfred_script(q)
    do shell script "/usr/local/bin/alacritty -e " & q
end alfred_script
@chrisduerr

This comment has been minimized.

Copy link
Collaborator

commented Jul 10, 2019

Yeah, that would be the recommended approach. If you want to try to run something inside of Alacritty from the get-go, that's exactly what the -e flag is made for. Of course you can also use the shell section of the config, but that would likely require a separate config file and the --config-file flag.

@deanishe

This comment has been minimized.

Copy link

commented Jul 10, 2019

If you want to try to run something inside of Alacritty from the get-go, that's exactly what the -e flag is made for.

It works great for things like top or ssh hostname, where it's okay—desirable even—for the terminal window to close as soon as the program exits.

The way the Alfred plugin is supposed to behave, however, is much as if you'd opened a terminal and pasted the command into it, i.e. the session isn't supposed to exit when the command does. That doesn't work with alacritty -e: if I try to run df -h, for example, I never get to see the output.

@chrisduerr

This comment has been minimized.

Copy link
Collaborator

commented Jul 10, 2019

@deanishe There's nothing stopping you from executing a shell with a command without keeping a shell session around. That's perfectly possible with the -e command.

@deanishe

This comment has been minimized.

Copy link

commented Jul 11, 2019

Im not sure I follow. The shell is not supposed to exit.

@chrisduerr

This comment has been minimized.

Copy link
Collaborator

commented Jul 11, 2019

The shell is not supposed to exit

I'm aware of that. Nothing is stopping you from keeping the shell around with the -e command though. All it does is execute a command, it's up to you what command that's going to be.

If the shell exits or not is completely unrelated to Alacritty, that's just up to the command you specify. If you don't want the shell to exit, just keep it around.

@deanishe

This comment has been minimized.

Copy link

commented Jul 11, 2019

Nothing is stopping you from keeping the shell around with the -e command though.

Yes, there is: the fact that other plugins do not work that way.

We're trying to make a plugin that lets people transparently use Alacritty instead of Terminal.app. That's not possible if Alacritty can't be made to behave the same way with the same command.

Do you see the problem?

@chrisduerr

This comment has been minimized.

Copy link
Collaborator

commented Jul 11, 2019

Do you see the problem?

I do not. Alacritty has no goal of ever working exactly the same way as Terminal.app or iTerm. As long as there's a reasonable way to get the same result, I don't see how that would be a problem. Especially if Alacritty's solution is cross-platform, while iTerm's/Terminal.app's only works on their specific target platform.

@deanishe

This comment has been minimized.

Copy link

commented Jul 11, 2019

As long as there's a reasonable way to get the same result

There isn't a reasonable way to get the same result. That's the point.

It is not possible for every Alfred workflow to work around this by special-casing Alacritty and sending a different command because they do not know which terminal emulator is being used.

In any case, I think you can close the issue. I believe @bmikaili has given up on getting Alacritty to work and is using a different terminal emulator instead.

@nixpulvis

This comment has been minimized.

Copy link
Collaborator

commented Jul 11, 2019

The fundamental "issue" here is not unique to this problem. Alacritty is not the default Terminal on any system I'm aware of, and as a result is generally not the target of tools like Alfred. Alfred makes a choice to work in a very specific way, which works with some macOS applications. If Alacrity was itself a macOS app (not a more general cross platform emulator) then there may be a case for adding this level of macOS specific support.

As things stand, we don't generally add features just to fit into specific workflows. We support many workflows, and as noted in this thread the actual functionality is possible, but just might require some additional configuration. I think we all understand that this friction might turn some users away, but I don't see how this is avoidable in general.

As for AppleScript support as this issue is requesting, unless I'm misreading the Apple documentation this would require us to sign our application with Apple. If this is the case I'll refer to #1896 for our stance on that.

@nixpulvis nixpulvis closed this Jul 11, 2019

@deanishe

This comment has been minimized.

Copy link

commented Jul 11, 2019

I completely understand your reasoning. I wouldn't consider adding AppleScript support, either.

as noted in this thread the actual functionality is possible, but just might require some additional configuration.

No, it really isn't. It's not possible to write an Alfred plugin for it that works the way it's supposed to. Alacritty simply does not support the features Alfred expects.

I'm not trying to assign any blame here. It's not Alacritty's fault for only having a broad cross-platform method for running commands, nor Alfred's for having an overly Mac-specific one. But they just ain't compatible, and only unreliable hackery could bring them together.

@nixpulvis

This comment has been minimized.

Copy link
Collaborator

commented Jul 11, 2019

@deanishe I must be misunderstanding the integration, sorry. It's a shame Alfred isn't more flexible.

@deanishe

This comment has been minimized.

Copy link

commented Jul 11, 2019

It's a shame Alfred isn't more flexible.

Yes, it is.

I'm gonna try and get it to work the hacky way by simulating typing the command into a new Alacritty window. With Alacritty's consistently fast startup time, I think that might work reliably enough to be useable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.