There's a bug that happens when you try to tab complete cd .. that causes it to give you suggestions for the .myaliases folder.

We maybe don't care that much, but printf and ed are a little noisy when they don't get what they want.

For some reason the $ABSPATH variable isn't being set in the .included. So this is a more fundamental problem found in the setup file.

so you know what just ran

When I alias cd to cds, I want to replace cd's tab completion with cds's. How is that done?

It's lonely and no one is talking about it. Please:

• Write a wiki page for it.
• Put comments in the file itself.

cd will add slashes to the end of its suggestions. I want cds to do this too because then people won't have to type a slash each time they want to autocomplete another subdirectory.

Cause I think that would be fast to implement and very helpful

If .usr_aliases contains the alias you're trying to write, delete the previously defined line.
I'm not quite sure how to do this using a variable. See uninstall script for how I did this previously.

Maybe not forks (let's overapply 105 woo) but make it not need to occupy the terminal session.

You can pass more than one shortcut name to cds - to delete multiple shortcuts at a time (ex: cds - <shortcut1> <shortcut2>.

When tab completing cds -, only the first shortcut gets completions. _cds is not prepared to handle tab completions for cds - with an arbitrary number of shortcuts to be deleted.
So completions for cds - <letter(s)>[tab] works but those for cds - <shortcut1> <letter(s)>[tab] and cds - <shortcut1> <shortcut2> <letter(s)>[tab] do not work.

Also, completions should work at any point in typing the command, so cds - <letter(s)>[tab] <shortcut2> should also work.

Seems like there's some confusion with argument order. Check on this.

If a directory doesn't exist, the cds command will display the realpath error along with the "directory or file not found" error that is implemented in the code. Let's quiet the realpath error.

Please do the following when you get access to a lab mac:

• setup works!
• uninstall works!
• documentation for this process written!
• check src command works for mac, or at least fails gracefully? (it does not. this is the wrong file to source.)

In today's episode of making cds more like cd:

• exit codes
  cds doesn't return an exit code of 1 when it fails. cd does
• options
  cds doesn't work when cd's -P option is used. This is because cds doesn't recognize -P as a directory, so it doesn't call regular cd
  Also what should we do about cd's -L option? It's turned on by default

https://github.com/GiselleSerate/myaliases/wiki/.bash_alias

@aryam7 I noticed you had typeset in aliasing cd to cds. I threw it in my page on .bash_alias but I'm not actually sure why you had that?

If we decide to support zsh, here's what's going to be involved:

• bootstrap the shebang at the top of all scripts to correspond to the shell being used
• modify the .zshrc to include our generated .bash_aliases file
• make sure all sourcing is done to the .zshrc

Fair warning, this is probably going to be pretty annoying. It's not going to be super generalizable either; you're going to have to do this for every single other shell you support.

You'll have to do this with regexes because people usually have spaces in quotes and weird stuff like that.
Only do this check if the flag is present. If it is compliant with the regex, continue; if not, break.

tl:dr; you have to run setup but you have to include it in your .zshrc manually

Put it in the setup script and add it to .included as the first thing.

While tagging this repo, I discovered some other repos in the bashrc tag and others that might be helpful for figuring out what shells are actually common and necessary to be compatible with. Which, maybe we don't have to add the other shells, maybe we need to worry about depth rather than breadth?
Anyway, some examples I found:

• https://github.com/voku/dotfiles
  Cygwin, Git Bash
• https://github.com/Bash-it/bash-it
  Okay this is basically exactly us but big, that's worrying lol . . . did we happen to check if these commands/aliases are already a thing?
• https://github.com/codenameyau/dotfiles
  Further research yields this, which has user-friendly symlinks (although I like cds a lot better). Are we reinventing the wheel here?

You could source each file individually. But for safety, simulate include guards from C? Like how you use ifndef. Shouldn't be terrible to implement, but you'd just have to do it for every file.

Part of a compiler's job is to create machine readable code that works for the computer on which it was compiled, right?
Well, the compiled realpath isn't executable on my phone. I keep getting an error: cannot execute binary file: Exec format error.
Normally, I wouldn't worry about this, but it may be a problem for other computers in the future.

so here's a strategy that might work: pass the command to alias and then run alias nickname to get the line that alias assigned, and then write that straight to file.

# myaliases: include
if [ -f  ]; then
        .
fi

Yeah, I don't know what this is, this probably ain't good.

From commit 3005b00. Thanks, Arya.

Also, if this method of parsing the -s flag doesn't work or gets too complicated, there's also this:

while getopts "s" opt; do
	case ${opt} in
		s) local there_was_an_s="true"; shift;;
	esac
done

which will create the boolean there_was_an_s if the -s flag was included.
You can use it later by creating an if-statement, like so:

if [ -n there_was_an_s ]; then
	# code that happens if the -s flag is specified
else
	# code that happens when the -s flag isn't specified
fi

That if-statement just checks whether the boolean variable exists.

If we modify .bash_aliases, we should really have a way to fix it back.
This uninstall script should:

• delete our lines from .bash_aliases (involves ed?)
• delete .included (simple rm)

It might be cleaner for a single helper function to parse options for all of our functions instead of having the functions do it themselves. This would likely only work if all of our functions use optional arguments in the future. If any one function needs to specify a required argument, it will need to parse the options itself.
I envision the helper function putting variables for each relevant option into an accessible scope for later use by the functions that call it. Our helper function could also return the new $@ argument list that the original functions could use instead of their old $@ argument list.
This would make using options significantly easier and cleaner.

Wiki's out of date; see bash_nav, see main page.

Add to readme? Wiki? I don't know. Somewhere.

I ran into this error using cds:

-bash: redirection error: cannot duplicate fd: Too many open files
-bash: /dev/null: Too many open files

Is the problem reproducible? Try keeping terminal open for a couple days and using cds a lot.
Maybe WSL isn't properly removing file descriptors?

In any case, the problem went away as soon as I closed the terminal and reopened it. It seems kinda obscure. I haven't run into it a second time.

This sounds really involved to do manually. Does normal alias do this? How does it do this?

cds is not happy if you give it a quoted directory with spaces in it. It supposedly breaks up the string into multiple arguments because I used "$@" syntax instead of $@.
ex: cds "Financial Economics"

Make sure you're calling the old alias and not one you define, just in case the user wants to alias alias to altalias.

We've had a new idea for a command that aliases a bunch of your prior commands together into a single command. It will probably use bash history. It will be written in c because c is so much easier.

Wouldn't it be great if the cds command did tab completion?!

The readlink command, which cds uses to get the absolute, target path for a symlink, is not supported on all systems, especially Macs. It apparently doesn't have good alternatives.

like it no longer works
I mean, presumably it's been made obsolete by cds but we should really do something about it.

As follows:

gserate@knuth [~]
#(1) % echo $SHELL
/bin/zsh
gserate@knuth [~]
#(2) % src
~/.bashrc sourced.
\A [\u@\h:\w]
\!
\A [\u@\h:\w]
\!
\A [\u@\h:\w]
\!
\A [\u@\h:\w]
\!

Somehow the conditional checking what shell we're using broke.

What if you want to use a variable in your nickname but you want it evaluated on src instead of on calling altalias? Use single quotes: '$var1'="commands"

Use cases: Uh . . . call with username?

Consider whether you even want this behavior or if someone would find this useful. It's undefined by alias.

I'm very, very confused about the best way to use options in a bash script. There are a lot of competing answers on the internet and none of them seem ideal. I'm going to try explaining them here. @GiselleSerate, let me know what you think.
I found a great explanation of three ways to parse options in this Stack Overflow answer. They recommend just using regular bash in the first two methods, both of which seem quite robust, if not a little verbose. The last answer, however, explains that the builtin getopts (which I presume was made specifically for this sort of thing) might be better because it's portable and can handle combining options automatically (like using -vf instead of -v -f).
I looked into getopts using this tutorial. The only downside, it seems, is that it can't handle optional option arguments, like the kind we're planning to use for -h. This Stack Overflow post details some work-arounds.
However, the second answer in that post describes a much better alternative called enhanced getopt, which honestly sounds like the best thing ever. It does all of the stuffs and is supposedly standard on any system. However, a comment to that answer specified that it would be bad for wrapper scipts, which is kinda what we're doing, right? They suggested this code, instead.

Could we also just use c?

clangl should have the functionality of clangd on request, so that if somebody compiles object files with clangp and then wants to link with clangl, they can still have the option to delete all files afterward.
Ideally, this would be done with options, but that gets a bit tricky...

We mentioned letting users add new aliases from anywhere without having to open any of the dotfiles themselves. This doesn't seem like it would be too hard.

concept/plan:

setup:

• make .bash_alias << should we name this something else?
• check if alias is a reserved name (yes, it's very reserved)

usage:

add alias "aliasname"="command" or add "aliasname" "command"
Pick the second for now; we don't have enough syrup here for waffling.
Final syntax: addalias aliasname="commands go here"

• figure out how to make spaces work in command
• decide whether you'll support spaces in aliasname (this part's optional)

implementation:

• write the alias to a new file (.usr_aliases?)
• include .usr_aliases in something that will get run when you source the .bashrc (in the bottom of .bash_alias)
• source the .bashrc or whatever it is (I'd like to use the src command from .cds_nav)

side of fries:

• we should really decide how we're going to include other functions . . . we should be able to force include dependencies from sibling files that we wrote. What if I want to use .cds_nav? See #41.
• decide if you want tab completion for commands. See #43.

Currently you have to manually update your .bashrc or .bash_aliases with every file you want. Can we somehow autoinclude everything?

Ideas:

• Have a single file in the myaliases folder which inside it includes the rest of the files in the repo, and then you only have to include that file in the .bashrc.
• Provide a function for inclusion in the .bashrc that goes through everything in the myaliases directory and includes it (I have no idea how to do this).

(Also note that if this repo gets cloned as something besides myaliases, there will be problems, but this has always been a problem and more of something to keep in mind than something we need to worry about that right now.)

The executable might be useful for later use. Maybe the developer wants to test their executable with different parameters several times, for example.

The current code in cds will check first whether the supplied argument is a directory before it executes cd. This is a necessary check so that cds can decide whether to attempt to cd with a shortcut; if the directory doesn't exist, cds tries one of its shortcuts.

I realized though that cd probably does this check itself, and likely a whole bunch of others too. So what's the point in guessing what those checks are and then hard-coding them into cds like I've been doing? Back when I first started, I didn't have a way to first attempt to execute \cd and then try a shortcut if it didn't work...
...until I learned about exit codes 😀

This refactor will finally be the breaking point after which I would be comfortable aliasing cd to cds by default when people run setup 😄 After this point, cds will literally be executing cd before it tries its stuff and there's no better way to create a wrapper function than that, right?

What do you think, @GiselleSerate? Should I do it?

Other Possible Upsides: significantly simplifies the code for cds; makes cds more compatible with other shells
Possible Downsides: makes cds ever so slightly slower to jump to a shortcut but makes it faster to jump to a regular directory

It's easy for the aliases in the file we wrote. What about other aliases? I think the alias command would be helpful here, but parsing might be sketchy.

clangl should not run if there are not enough arguments.

Currently I'm leaving the input checking very basic; you just can't use special characters. I think some of them are permissible in alias, though, so you should:

• figure out which characters are okay in alias
• add the above to the permissible character set

It might be nice if all functions didn't output the commands they were running by default. This would allow the developer to quickly see the output that is important (from his/her own code) rather than having to visually pick it out.
Perhaps the best way to do this is to add the option -v (for "verbose") to every function?