Open Marwe opened 7 years ago
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):
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.
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:
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