Cross-shell aliases

[Ernest0-Production]

I would like to be able to specify aliases for built-in scripts in the mise configuration, so as not to specify the full path to them or parameters for launching:

# define
alias myTool='path/to/my_tool.sh --default-option'

# usage 
myTool subcommand <path...> --argument Value --some-option 

I know it's possible to create a mise task, but calling mise run seems like a longer command, especially when my script can also take many parameter and component arguments:

mise run myTool subcommand <path...> --argument Value --some-option 

If I understand correctly, you can use the env._.source directive and specify the path to the script (for example aliases.sh) in which all aliases will be declared.

BUT I want to avoid spreading the project settings across several files, and keep everything in one configuration mise:

# Aliases of bash scripts
[alias.bash] 
myTool='path/to/my_tool.sh --default-option'
# Aliases of ruby scripts
[alias.ruby]
myRubyTool='path/to/stuff.rb'

[jdx]

I think there would be value in having cross-shell aliases in mise similar to https://github.com/cpendery/kaldo

We would probably want to use the top-level [alias] key in the config, which unfortunately is already used for tools. We could probably still do this but have a migration path for people to move over to [tool_alias] or something similar to that. Or maybe we have [shell_alias] and [tool_alias] to avoid conflicting and support [alias] for backwards compatibility.

[Ernest0-Production]

Hi! It may make sense to add the env._.alias directive, since this functionality is close to the path/source directives.

And thanks for kaldo. I didn't know about the existence of such a tool!)

[jdx]

yeah it could go there too

[egnor]

(re the OP https://github.com/jdx/mise/issues/2034#issue-2281176873 I think env._.source doesn't quite do this, as it only pulls environment variables, not aliases or other shell-internal things. What you'd probably do is use env._.path to add a local directory to $PATH, and then put little mini scripts in there for each of your commands. this would still involve the more-distributed configuration the OP doesn't like of course)