I found some aliases to shadow program binaries. There should not be clashes at least with widely used software as this can have unwanted side effects, e.g. for scripts.

Example

The alias gs='git status' from aliases/available/git.aliases.bash shadows the ghostscript binary named gs. This should be corrected, maybe use ggs or something that does not create a name clash.

Testing all aliases

I quickly wrote up a check for all aliases, using apt-file for i in $(sed -e '/^alias/!d;s#=.*$##;s#.#\.#g;s#alias #bin/#;s#$#$#' *); do echo "-- $i --"; apt-file -x search "$i"; done |tee /tmp/bashit-alias-check.txt bashit-alias-check.txt

File is attached (the loop takes a while, maybe it can be sped up with a regexp containing all patterns).

On a quick scan, I found the following being problematic, too:

-- bin/edit$ -- mime-support: /usr/bin/edit 389-dsgw: /usr/lib/x86_64-linux-gnu/dirsrv/dsgw-cgi-bin/edit -- bin/gm$ -- graphicsmagick: /usr/bin/gm -- bin/gst$ -- gnu-smalltalk: /usr/bin/gst -- bin/gs$ -- ghostscript: /usr/bin/gs -- bin/gpo$ -- gpodder: /usr/bin/gpo -- bin/gc$ -- graphviz: /usr/bin/gc -- bin/bup$ -- bup: /usr/bin/bup -- bin/bls$ -- bacula-sd: /usr/sbin/bls -- bin/jed$ -- jed: /usr/bin/jed -- bin/jls$ -- libtsk3-3-dbg: /usr/lib/debug/usr/bin/jls sleuthkit: /usr/bin/jls -- bin/jdb$ -- gcj-4.8-jdk: /usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/bin/jdb openjdk-6-dbg: /usr/lib/debug/usr/lib/jvm/java-6-openjdk-amd64/bin/jdb -- bin/nup$ -- dvi2ps: /usr/bin/nup -- bin/r$ -- littler: /usr/bin/r -- bin/restart$ -- fastdnaml: /usr/lib/fastdnaml/bin/restart interchange: /usr/lib/interchange/bin/restart upstart: /sbin/restart

OS and bash version

I use: bash --version GNU bash, Version 4.3.11(1)-release (x86_64-pc-linux-gnu) lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04.5 LTS Release: 14.04 Codename: trusty

What are your suggestions for resolving these conflicts?

Btw, I couldn't run the script, got the following error: sed: read error on data: Is a directory

Agreed, so far these conflicts have not been an issue for me (or for anyone else, at least nobody reported them).

I use the gs (git status) alias all the time, and I never use Ghostscript, so it's not an issue for me.

I'm not sure how to handle this - open for suggestions and ideas...

Personally, I have the issue with gs, but for my daily work, I prefer having the gs (git status) alias by hand, because I rarely need ghostscript.

A proposal that will work is to have a kind of "hook or "check step" that will try to guess if a command exists with the same name of an alias or a function name (in the past, this problem was with a function https://github.com/Bash-it/bash-it/pull/401) and ask the user for confirmation or for an alternative, like renaming the alias or function, or something similar...

This problem is not simple to solve, but we can try to do a "best effort" to mitigate it.

I found the 'namespace notation' not bad (with colon or maybe a dot, which is always near/same, even on different keyboard layouts), then it would be g.s for git status (or b:gs for bashit_namespace:alias). This will never clash with other binaries. And it is clearly an alias and easy to guess where it is defined.

Or check aliases against existing binaries as I did above.

@MunifTanjim this "script" had be run from within aliases/available/ dir, I added the full path, so it should work now from everywhere.

So what are we suggesting to do for this? How about the following (open for discussion, of course):

• The default behavior stays the same as it currently is to provide backwards compatibility.
• Add a flag to the installer that sets a config value to use the "b:" (or "bi:") namespace for aliases.
• If this config value is set, all of Bash-it's aliases are prefixed with the above namespace, so e.g. b:gs instead of just gs.

This would be an all-or-nothing setting, so that you either use the namespace for all aliases or for none of them. Why? I'd like to avoid having to check for existing commands at startup, which will be costly and time-consuming. Secondly, your aliases might change depending on what you install, which means you might be in for a surprise after installing a new OS package.

Ideally, the above can be implemented without changing any of the existing *.alias.bash files - maybe we can squeeze in the namespace while sourcing the alias files - which would prevent us from having to touch all of the alias files.

What do people think about this approach?

I just happened on this issue with R, as in #586. Thanks.

I'm not very worried about gs. I had one script that fails when I run it in my shell but it's fine when it is run from cron, whicxh is where I need it to work, I 'll just add an unalias gs to the script if I see I'll need it.

What did bother me is gst switching from status to stash all of a sudden in #1352, but I override it in my personal dotfiles.

Did y'all know that defining functions captures aliases?

So, if aliases/git is loaded first (which creates a gs alias), and then a function repdf referring to Ghostscript gs is loaded later, and then finally the user's custom.bash deletes the gs alias (since they use Ghostscript), then: declare -f repdf will still show a weird git command and will need to be loaded again fresh.

---

Aliases should be loaded dead-last, and I suggest extra care should be taken to avoid unintentional naming conflicts with existing commands. And probably something added to bash-it doctor to check for collisions.

Did y'all know that defining functions captures aliases?

TIL !

BUT really functions should probably be using command gs when they explicitly want to invoke ghostscript.

On the reverse side, bash-it has its own issues when encountering user-defined aliases for popular commands, ie ls, grep etc ... and we have to remember to explicitly invoke the command to avoid the alias.

Aliases should be loaded dead-last

Yeah that's probably true.

Another kinda related concern: Functions and aliases area meant to be loaded within .bashrc and not in .bash_profile - At some point I think we're going to need to look into separating bash-it into two/multiple stages.