docksal / addons

Community driven, submit your addon! Docksal addons that can be installed via `fin addon install` command.
MIT License
16 stars 34 forks source link

add ability for addon command aliases #33

Open shelane opened 5 years ago

shelane commented 5 years ago

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 commented 5 years ago

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

shelane commented 5 years ago

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

achekulaev commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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.