[feature idea] allow users to create and use custom aliases

[meleu]

Sharing only the idea. Not really sure about how to implement this...

If not possible to implement as a native bashly thing (or a lib), any tip about how to achieve this would be appreciated.

---

UPDATE

Turns out this is already possible with current bashly features. I share how to implement such thing in this post here.

---

idea

Allow users easily create command specific aliases.

Example of ideal usage:

# very long command
my_cli cmd subcmd --many --other --options "and args"

# creating an alias
my_cli alias set \
  'my_alias' \
  'cmd subcmd --many --other --options "and args"'

# now I can run that long command like this
my_cli my_alias

existing example

The glab GitLab CLI has a quite handy subcommand called alias that allows the user to create glab-specific aliases.

Aliases are created like this:

# generic:
glab alias set 'my_alias' 'my custom glab command'

# real example:
glab alias set 'mrcreate'  'mr create --push --assignee meleu'

Now when I want to push the current commit and create a Merge Request assigned to me, I can simply run glab mrcreate (rather than that long command).

The alias subcommands are:

• set
• delete
• list

The aliases are usually persisted in ~/.config/glab-cli/aliases.yml that has only key-value pairs, like this:

ci: pipeline ci
co: mr checkout
mrcreate: mr create --push --assignee meleu
mrmine: mr list --assignee=@me
mrview: mr view --web
repov: repo view --web
mredit: 'mr update --description - '

[DannyBen]

Why should this be limited to just one CLI tool?
Why not use a general purpose aliasing / task runner tool?

I am using my own opcode, which has exactly the functionality you are describing (quickly adding aliases by a simple command) and the file format you are describing (code: command).

Although this can be implemented as a library, to add to your own bash script - I am not entirely sure it should be a built in library, as the functionality is quite specific.

[meleu]

@DannyBen, I'm brainstorming now...

About the before hook:

Execute code before calling any command, but after processing the command line input.

I can't use before for what I want because it's executed after processing the command line input. I'd like to have a hook before such processing.

Do you think that creating an before_all hook is something acceptable?

Something to be called inside the run, and before the parse_requirements call (maybe here)

[DannyBen]

I forgot to mention, that you have a way of doing what you want without fighting the framework.

I am doing something similar in rush.

The concept is simple:

1. You configure a command that is intended to run an alias - call it run_alias for example.
2. If you don't want it to be visible to users, just hide it with private: true.
3. Set it to default: true.
4. Now this command will be called whenever there is an "unknown command".

Here is a sample basic YAML:

name: cli
help: Sample application
version: 0.1.0

commands:
- name: download
  alias: d
  help: Download a file
- name: upload
  alias: u
  help: Upload a file
- name: run_alias
  help: Run an alias
  default: true
  private: true
  args:
  - name: alias
    help: Alias to run

and here is how it looks when you run an unknown command:

 $ ./cli myalias
# This file is located at 'src/run_alias_command.sh'.
# It contains the implementation for the 'cli run_alias' command.
# The code you write here will be wrapped by a function named 'cli_run_alias_command()'.
# Feel free to edit this file; your changes will persist when regenerating.
args:
- ${args[alias]} = myalias

This is what you want I think.

In my rush script, my default command is get so running rush get something and rush something is in the same.

[meleu]

Dude, with some adjustments, this strategy of a private default command (with catch-all) works quite nice! 👌

Here's what I did:

# bashly.yml
# ...

commands:
  - name: run_alias
    help: Internal command to run a user defined alias
    default: true
    private: true
    # catch_all because I want to be able to pass extra args
    catch_all: true

  # more stuff here...

Then in my run_alias_command.sh:

# run_alias_command.sh
# shellcheck disable=2206,2207

alias="${OTHER_ARGS[0]}"
extra_args=(${OTHER_ARGS[@]:1})

# NOTE: assumes you have the bashly config.ini lib available
# you can use other methods if you want (e.g.: yaml)
aliased_command=(
  CONFIG_FILE="${ALIASES_FILE}" config_get "$alias"
)

# this 'if' is important to check if:
# 1. the alias exists
# 2. this is the very first call of 'run_alias'
#    (as it's the default subcommand, we don't want to recall it infinitely)
if [[ -z "${aliased_command[*]}" ]] || [[ -n "${RUN_ALIAS_CALLED:-}" ]]; then
  echo "invalid command: $alias" >&2
  exit 1
fi

export RUN_ALIAS_CALLED=true
run "${aliased_command[@]}" "${extra_args[@]}"

This 👆 is enough to handle these edge cases:

• given alias doesn't exist
• aliased command is invalid
• prevent nasty infinite loops if alias1=alias2 and alias2=alias1

It also allows calling cli my_alias --with-extra arguments to be passed to the aliased command.

[DannyBen]

Good. Have you considered:

1. Making the alias as a required arg
2. Using the filters directive to check if the alias exists

In other words:

- name: run_alias
  help: Run an alias
  default: true
  private: true
  catch_all: params
  filters: [alias_exist]
  args:
  - name: alias
    help: Alias to run
    required: true

Then you implement the filter_alias_exist function in lib/filter_alias_exist.sh, and your actual run_alias command gets cleaner, and focuses on running the alias, since it knows it exists.

The usage pattern becomes this:

 $ ./cli run_alias -h
cli run_alias - Run an alias

Usage:
  cli [run_alias] ALIAS [--] [PARAMS...]
  cli run_alias --help | -h

Options:
  --help, -h
    Show this help

Arguments:
  ALIAS
    Alias to run

Clean and idiomatic, no?

[meleu]

I've tried such approach.

Making the alias as a required arg was indeed cleaner. 👍

Not sure if the filter leads to a cleaner solution though.

The thing is that I still need to prevent the case of alias1=alias2 and alias2=alias1, which can cause an infinite loop.

run_alias_command.sh:

alias="${ARGS[alias]}"
aliased_command=(
  $(get_aliased_command "${alias}")
)

# I still need this to prevent tricky infinite
# loops if alias1=alias2 and alias2=alias1
if [[ -n "${RUN_ALIAS_CALLED:-}" ]]; then
  echo "invalid command: $alias" >&2
  exit 1
fi
export RUN_ALIAS_CALLED=true

run "${aliased_command[@]}" "${OTHER_ARGS[@]}"

lib/alias_functions.sh:

filter_alias_exist() {
  local alias="${ARGS[alias]}"
  if [[ -z "$(get_aliased_command "$alias")" ]]; then
    echo "invalid command: $alias"
  fi
}

get_aliased_command() {
  CONFIG_FILE="${ALIASES_FILE}" config_get "$1"
}

[DannyBen]

This should also be in a filter

if [[ -n "${RUN_ALIAS_CALLED:-}" ]]; then
  echo "invalid command: $alias" >&2
  exit 1
fi

either in the same filter, or another filter_alias_not_called function.
everything that should halt the command, is intended to be in a filter function.

Of course, you can do the filtering in your command code as you did, but I would want to stick to the design principles of bashly that encourages you to only have the actual command code in the command file.

Your command code can be as simple as this:

alias="${ARGS[alias]}"
aliased_command=($(get_aliased_command "${alias}"))
export RUN_ALIAS_CALLED=true
run "${aliased_command[@]}" "${OTHER_ARGS[@]}"

[meleu]

this is beautiful! 👌

thanks!