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

add ability for addon command aliases #33

Open
shelane opened this issue Dec 19, 2018 · 5 comments
Open

add ability for addon command aliases #33

shelane opened this issue Dec 19, 2018 · 5 comments
Assignees

Comments

@shelane
Copy link
Member

shelane commented Dec 19, 2018

Some command names are giving longer names for recognition purposes but are terrible for typing often. I like to shorten whenever I can. So, if we can add the ability to create an "alias" command name. For instance, sequelpro can be sqlp. I'm working on an addon that will generate release notes in various formats (from Drupal's grn module). While fin release-notes would be recognizable, fin grn would be faster to type.

@achekulaev
Copy link
Member

I don't have good ideas how to implement it without overcomplicating the commands system.

@shelane
Copy link
Member Author

shelane commented Dec 19, 2018

It is just an idea. I'm sure you have different means with aliases for commands defined within fin.

@achekulaev
Copy link
Member

achekulaev commented Dec 20, 2018

I understand, but I had this idea already. If I knew how to implement it, I would probably have already implemented it.

First I should say, that you already can create an alias yourself by creating a command-that-laucnhes-another-command.

.docksal/commands/grn

#!/bin/bash

## An alias for release-notes

fin release-notes "$@"

But I would assume that's now what you mean. You'd probably expect to somehow define an alias inside the command, correct?

If so, then while it is possible for fin to find it there, it would open 2 cans of worms:

  1. fin would have to parse all the command files on every launch. The more commands you have, the slower every fin command would get
  2. fin would have to resolve collisions, e.g. release-notes defines alias grn but there is also a real command grn, or another command that defines the same alias.

Now the problems are solvable, but they would increase complexity of handling and launching custom commands three-fold. What is the benefit? The benefit is minimal. Mere seconds saved on typing the command name. And if someone does launch some command very often, then there is already a way to have it, command-that-laucnhes-another-command might feel patchy but it is actually not.

So if there are other ideas how do define aliases for custom commands that would not open these cans of worms, we could discuss possibilities, but if there are no other good ideas, then I am not sure if this ticket has any perspectives.

cc @lmakarov, @sean-e-dietrich

@frederickjh
Copy link
Contributor

@achekulaev I think that the command to launch another command is a very sensible idea. Once a list of short versions of the command was agreed upon the commands could be added and the documentation for the long versions updated to include the shorcut command.

The only downside I see is commands would get listed twice unless there was a way to say do not list the shortcut commands.

@achekulaev
Copy link
Member

achekulaev commented Jan 22, 2019

@frederickjh nice.

While thinking on your last message I realized that now I actually have an idea how to implement aliasing.

Limitation: this would only be applicable to addons, only 1 alias per addon.
Gist: Addon folder can have $addonname.alias.$alias file, defining a short alias.

Example:

Main file: .docksal/addons/release-notes/release-notes
Alias file: .docksal/addons/release-notes/release-notes.alias.grn (an empty file)

How it addresses the issues described above:

  1. fin would not need to parse any files on launch, only check for existence of $addonname.alias.* files

  2. In case when alias has a collision with existing file, i.e. if commands/grn or addons/grn/grn physically exists on a drive, then existing file will take precedence despite that help text would say that alias grn exists for release-notes. If 2 addons were to define the same alias, then fin would error out urging user to remove one of them first.

@achekulaev achekulaev self-assigned this Jan 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants