[SOLVED] how to unalias "vi" and "ls" globally in Linux
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I'm perplexed. I am unable to figure out how to permanently unalias "vi" and "ls" (mainly to get rid of the color).
I've looked in /etc/bashrc, /etc/profile, /root/.bashrc, etc, but no where can I find where these aliases are set.
Obviously, I can add an "unalias <cmd>" into the above files and that will resolve the issue, but that seems like I am not addressing the real problem of where these aliases are set.
Yes, I tried first "grep "alias" ~/.* -i" and saw nothing relevant.
Then I tried "grep "alias" /etc -ir", and this pointed to some files in /etc/profile.d
It seems some files in this directory are setting the aliases that I'm annoyed with.
e.g.,
colorls.csh:alias ll 'ls -l'
colorls.csh:alias l. 'ls -d .*'
colorls.csh:alias ll 'ls -l --color=tty'
colorls.csh:alias l. 'ls -d .* --color=tty'
colorls.csh:alias ls 'ls --color=tty'
colorls.sh:alias ll='ls -l' 2>/dev/null
colorls.sh:alias l.='ls -d .*' 2>/dev/null
colorls.sh: alias ll='ls -l --color=tty' 2>/dev/null
colorls.sh: alias l.='ls -d .* --color=tty' 2>/dev/null
colorls.sh: alias ls='ls --color=tty' 2>/dev/null
vim.csh: alias vi vim
vim.sh: # for bash and zsh, only if no alias is already set
vim.sh: alias vi >/dev/null 2>&1 || alias vi=vim
which-2.sh:alias which='alias | /usr/bin/which --tty-only --read-alias --show-dot --show-tilde'
But, logging in directly as root, and the typing "alias", I do not see some of these aliases.
For example, the alias for vi to point to vim instead.
# alias
alias cp='cp -i'
alias l.='ls -d .* --color=tty'
alias ll='ls -l --color=tty'
alias ls='ls --color=tty'
alias mv='mv -i'
alias rm='rm -i'
alias which='alias | /usr/bin/which --tty-only --read-alias --show-dot --show-tilde'
Then I tried "grep "alias" /etc -ir", and this pointed to some files in /etc/profile.d
It seems some files in this directory are setting the aliases that I'm annoyed with.
Quote:
Originally Posted by wolffjw
But, logging in directly as root, and the typing "alias", I do not see some of these aliases.
For example, the alias for vi to point to vim instead.
It may be that some or all of the the scripts in /etc/profile.d are only applied to regular users, e.g. your /etc/profile might check for your userid being something other than 0.
Probably not there because he has already realised that the alias's are being set in /etc/profile.d. In any case you can source stuff with a simple '.', e.g. from Slackware's default /etc/profile:
Code:
# Append any additional sh scripts found in /etc/profile.d/:
for profile_script in /etc/profile.d/*.sh ; do
if [ -x $profile_script ]; then
. $profile_script
fi
done
So that grep may potentially miss things that are sourced in.
Sometimes it helps to trace what happens (there can be a lot of output, especially when using bash --login instead of just bash to trace what happens when a login shell starts up):
Code:
set -xv
bash
Some scrippets in /etc/profile.d have comments to identify themselves when they are run. Helpful
/etc/profile.d/*.sh files can be disabled by changing their extensions, by emptying them or by removing read permission from them. The first method will not survive an upgrade, the second two probably will, depending on what the upgrade does when it finds package files have been modified.
It may be that some or all of the the scripts in /etc/profile.d are only applied to regular users, e.g. your /etc/profile might check for your userid being something other than 0.
What distro are you using?
It is the same regardless whether I log in as root, or another user.
Red Hat Enterprise Linux Server release 5.7 (Tikanga)
It is the same regardless whether I log in as root, or another user.
Ok, then I misunderstood you. In that case I would go with catkin's advice and remove execute permissions on the files in /etc/profile.d/ that you do not want run.
How about an alias in ~/.bashrc to avoid the color output?
Well, there are a few similar options that I can resolve the problem, but for now, I'm mainly trying to find the source that is creating the aliases, such as vi to use vim with color.
I'm mainly trying to find the source that is creating the aliases, such as vi to use vim with color.
You said above that you already found that vi was using vim because of /etc/profile.d/vim.sh, i.e.
Quote:
Originally Posted by wolffjw
Code:
vim.sh: alias vi >/dev/null 2>&1 || alias vi=vim
You also found that /etc/profile.d/colorls.sh was the reason for coloured ls output, i.e.
Quote:
Originally Posted by wolffjw
Code:
colorls.sh:alias ll='ls -l' 2>/dev/null
colorls.sh:alias l.='ls -d .*' 2>/dev/null
colorls.sh: alias ll='ls -l --color=tty' 2>/dev/null
colorls.sh: alias l.='ls -d .* --color=tty' 2>/dev/null
colorls.sh: alias ls='ls --color=tty' 2>/dev/null
As for the fact that vim uses colour, this is probably down to vim's own configuration file.
EDIT: Simplest fix is probably to install actual vi then remove read permissions on /etc/profile.d/vim.sh and /etc/profile.d/colorls.sh. You will then need to log out and back in again.
Last edited by ruario; 05-03-2013 at 02:43 PM.
Reason: changed execute permissions to read permissions as likely to be more foolproof.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.