Ally is meant to function exactly like the ZSH alias
command, except with a few superpowers. This means that the invocation is exactly the same:
alias helloworld='echo "Hello, World\!"'
# Same thing below!
ally helloworld='echo "Hello, World\!"'
However, there is one key difference:
That is the whole point. Ally adds the aliases not to the local terminal session, but rather to the user's .ally
file, which is then source
d in the ZSHRC. This means that, while the behavior of ally
is the same as alias
for a terminal session, the aliases remain throughout sessions! In the example above, if a user were to open a new tab having only run alias
in the original, they would see:
alias helloworld='echo "Hello, World\!"'
[NEW TERMINAL SESSION]
❯ helloworld
zsh: command not found: helloworld
However, if the user had run ally
instead:
ally helloworld='echo "Hello, World\!"'
[NEW TERMINAL SESSION]
❯ helloworld
Hello, World!
This project is functional, but is ⚠️⚠️ NOT YET READY FOR USE! You might damage your system or config by running it! Ally is much more reliable than it was when first started, but still occasionally will exhibit unexpected behavior. The only documented example of this currently is in the init
command, which will overwrite the existing .ally
file if invoked again on a system with an existing install.
One-liner (inspired by Homebrew):
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/OCA-Creations/Ally/main/install.sh)"
[!NOTE]
The one-liner above assumes this install is not intended to be used for development of the Ally tool itself. Also, if you already have a directory namedAlly
in the location in which you are running the script, then install will fail with the following error:fatal: destination path 'Ally' already exists and is not an empty directory.
If you wish to install for development, follow the steps below:
- Download + Build the project (
git clone
andswift build
in the folder)- Locate the built executable and move it to the desired location.
- Run the executable with the parameter
init
.- Keep developing and building
ally
in the original directory - you may want to use it to add an alias to the Derived Data build!This tool was hacked in a night - it is still being developed! It is actively in progress, and is currently used, but needs work!
Some ideas/todos (strikethrough indicates complete):
ally dot
will open the .ally fileally edit ALIAS "OLD_COMMAND"
will edit an alias- The old command may not need to be in quotes.
Allow equals signs:ally add test=echo
is as valid asally add test 'echo'
.ally install --reinstall
will reinstall and format the dotfileally dot format
will format the dotfile- Can we call things like
ally init
from a Swift file with pure Swift? Call the class directly?ally zshrc
will transfer all current aliases to the .zshrc- Improve the quality and organization of the project
- Improve command docs
ally list
will print a list of aliasesally add ALIAS "OLD_COMMAND" -docs "DOCS"
will let the user add documentation for an alias (stored in a comment on the line above.)- Support bash and fish shells.
- Currently, reload doesn't do anything. Can we fix this or remove it altogether?
- Being worked on - see #8
- Currently, quotes need to be escaped. Can we auto-escape them?
- When installing, if
--reinstall
is not specified, don't overwrite the .ally file!- Should we rename to something other than .ally?
- Should we have a custom file format like https://github.com/DannyBen/alf
- Check out https://github.com/DannyBen/bashly
- Should this be public? How can we improve it first?
Add an sh install script for oneliner install.- Add tests (and allow custom directories to be inputted for them)?
- Allow the user to add a custom name for ally?
ally name CUSTOM_NAME
?- Improve code and args for all commands.
- Add docs.
- Add a man page? (#2
- Convert all of these notes into issues on GitHub.
- Should we have automatic alias generation based on frequently used commands?
- Should we have a list of aliases that you can add?
ally defaults DEFAULT_LIST_NAME
?ally debug -o OUTPUT_FILE_LOCATION
should save a debug report (text file) for contributors to track bugs and other things.- Some ideas for defaults:
os-interop
will let you transport Windows or UNIX commands to your current OS. If you're on Windows, then this would enablels
(dir
),touch
, etc. This would conversely enabledir
as a replacement forls
on UNIX.hacking
- all the aliases and tools one needs to hack.allyutils
orgeneralutils
- these are things that make usingally
or the Terminal easier, such as areload
command that reloads everything -source $HOME_DIR/.ally
, etc.- Improve verbosity, especially when adding a command. This could be specified with a degree of verbosity (like TensorFlow). We would need to warn users when entering aliases that already exist or aliasing over existing commands (see CommandRunner.swift to test out if a command already exists).
- What if we allowed users to create their own CLI tools from scripts? So the user passes in
ally add SCRIPT.py
(or another language), and then ally adds an alias for the script, and creates a CLI for it?Add to PATH instead of an alias.- Save and restore backups of
.ally
files- Allow sharing + install of custom
.ally
files?- Allow another syntax in
add
command:->
- This would allow us to add things like:
ally add getPID -> "ps aux | grep"
- Mimics Swift function naming