Is it possible to check where an alias was defined?
Clash Royale CLAN TAG#URR8PPP
up vote
13
down vote
favorite
An alias, such as ll
is defined with the alias
command.
I can check the command with things like type ll
which prints
ll is aliased to `ls -l --color=auto'
or command -v ll
which prints
alias ll='ls -l --color=auto'
or alias ll
which also prints
alias ll='ls -l --color=auto'
but I can't seem to find where the alias was defined, i.e. a file such as .bashrc
, or perhaps manually in the running shell. At this point I'm unsure if this is even possible.
Should I simply go through all files that are loaded by bash
and check every one of them?
bash terminal bashrc
add a comment |
up vote
13
down vote
favorite
An alias, such as ll
is defined with the alias
command.
I can check the command with things like type ll
which prints
ll is aliased to `ls -l --color=auto'
or command -v ll
which prints
alias ll='ls -l --color=auto'
or alias ll
which also prints
alias ll='ls -l --color=auto'
but I can't seem to find where the alias was defined, i.e. a file such as .bashrc
, or perhaps manually in the running shell. At this point I'm unsure if this is even possible.
Should I simply go through all files that are loaded by bash
and check every one of them?
bash terminal bashrc
Off the cuff I'd say runbash -xl
– Jeff Schaller
Nov 10 '16 at 22:19
Related unix.stackexchange.com/questions/322817/…
– icarus
Nov 12 '16 at 22:22
add a comment |
up vote
13
down vote
favorite
up vote
13
down vote
favorite
An alias, such as ll
is defined with the alias
command.
I can check the command with things like type ll
which prints
ll is aliased to `ls -l --color=auto'
or command -v ll
which prints
alias ll='ls -l --color=auto'
or alias ll
which also prints
alias ll='ls -l --color=auto'
but I can't seem to find where the alias was defined, i.e. a file such as .bashrc
, or perhaps manually in the running shell. At this point I'm unsure if this is even possible.
Should I simply go through all files that are loaded by bash
and check every one of them?
bash terminal bashrc
An alias, such as ll
is defined with the alias
command.
I can check the command with things like type ll
which prints
ll is aliased to `ls -l --color=auto'
or command -v ll
which prints
alias ll='ls -l --color=auto'
or alias ll
which also prints
alias ll='ls -l --color=auto'
but I can't seem to find where the alias was defined, i.e. a file such as .bashrc
, or perhaps manually in the running shell. At this point I'm unsure if this is even possible.
Should I simply go through all files that are loaded by bash
and check every one of them?
bash terminal bashrc
bash terminal bashrc
asked Nov 10 '16 at 22:09
polemon
5,64464177
5,64464177
Off the cuff I'd say runbash -xl
– Jeff Schaller
Nov 10 '16 at 22:19
Related unix.stackexchange.com/questions/322817/…
– icarus
Nov 12 '16 at 22:22
add a comment |
Off the cuff I'd say runbash -xl
– Jeff Schaller
Nov 10 '16 at 22:19
Related unix.stackexchange.com/questions/322817/…
– icarus
Nov 12 '16 at 22:22
Off the cuff I'd say run
bash -xl
– Jeff Schaller
Nov 10 '16 at 22:19
Off the cuff I'd say run
bash -xl
– Jeff Schaller
Nov 10 '16 at 22:19
Related unix.stackexchange.com/questions/322817/…
– icarus
Nov 12 '16 at 22:22
Related unix.stackexchange.com/questions/322817/…
– icarus
Nov 12 '16 at 22:22
add a comment |
6 Answers
6
active
oldest
votes
up vote
13
down vote
accepted
Manual definition will be hard to spot (the history logs, maybe) though asking the shell to show what it is doing and then grep
should help find those set in a rc file:
bash -ixlc : 2>&1 | grep ...
zsh -ixc : 2>&1 | grep ...
If the shell isn't precisely capturing the necessary options with one of the above invocations (that interactively run the null command), then script
:
script somethingtogrep thatstrangeshell -x
...
grep ... somethingtogrep
Another option would be to use something like strace
or sysdig
to find all the files the shell touches, then go grep
those manually (handy if the shell or program does not have an -x
flag); the standard RC files are not sufficient for a manual filename check if something like oh-my-zsh or site-specific configurations are pulling in code from who knows where (or also there may be environment variables, as sorontar points out in their answer).
Thanks! Even though the output is a bit hard to parse, but I found the file that defined the alias I was looking for. When the alias isn't present anywhere in that list, would it be safe to assume the alias was defined manually?
– polemon
Nov 10 '16 at 22:58
@polemon somewhat safe; it could be (or have been) defined in a file that isn't being read in because of who-knows-what-reason-or-was-deleted (especially if there's some sort of shell framework adding complexity that the user does not understand).
– thrig
Nov 10 '16 at 23:01
1
To make the point where the alias is defined a bit easier to find, you can use PS4, which is prepended to every line in a trace:PS4='+The ll alias is "$BASH_ALIASES["ll"]" ' bash -ixlc :
– Mark Plotnick
Nov 11 '16 at 9:08
add a comment |
up vote
5
down vote
Here is where I find grep -rl
very useful:
grep -rl alias ~/.bash* ~/.profile /etc/profile /etc/bash.bashrc
will tell you in which file the word alias
is used.
Probably in ~/.bashrc
and most certainly in ~/.bash_aliases
if it exists.
It is however impossible to be absolutely sure that that covers all options.
Those files may also call or load any other files.
An environment variable like ENV or $BASH_ENV
may direct bash to load some other files.
looks for the variable BASH_ENV in the environment, expands its value if it appears there, and uses the expanded value as the name of a file to read and execute.
And aliases may even be defined by setting a variable (emphasis mine):
BASH_ALIASES
An associative array variable whose members correspond to the internal list of aliases as maintained by the alias builtin. Elements added to this array appear in the alias list
grep -rl alias ~/.bash*
may falsely match history files, but +1 for pointing out the BASH_ALIASES array!
– Jeff Schaller
Nov 10 '16 at 23:59
add a comment |
up vote
1
down vote
I don't know of a way to actually list the source of your aliases, but since it looks like you're using bash I think these are the possible source files:
/etc/profile
~/.profile
/etc/bash.bashrc
~/.bash_profile
~/.bashrc
You should be able to grep through those to find the alias, e.g. grep 'ls -l --color=auto' /etc/profile ~/.profile /etc/bash.bashrc ~/.bash_profile ~/.bashrc
.
Or files included from there...
– Jeff Schaller
Nov 10 '16 at 22:56
@JeffSchaller - Right, you'd need something more complex for that likebash -x
, as you mentioned. I figured the above was easy enough to run quickly and if it doesn't find the alias you can read through the execution steps.
– edaemon
Nov 10 '16 at 23:32
add a comment |
up vote
0
down vote
I've had success simply using which
.
[crclayton@pc scripts]$ which foo
foo: aliased to python $HOME/projects/python/foo.py
which
can handle aliases in tcsh (and maybe earlier csh) and zsh where it is a builtin, and in bash using default profile on RedHat-family which has a kludge to run the (external) GNU program but feed it shell alias data, otherwise not. More important it only tells what the alias is set to, not where it was set, which was the Q here.
– dave_thompson_085
Nov 22 at 7:48
add a comment |
up vote
0
down vote
Combining thrig's answer with @MarkPlotnick's suggestion, you can test whether BASH_ALIASES[ll]
is set to narrow it down. The BASH_SOURCE
array and LINENO
variables are particularly useful here. Unfortunately, the check whether BASH_ALIASES[ll]
is set will only succeed after the alias has been set, and so the first such line could be in another file altogether.
PS4='$BASH_ALIASES["ll"]+"The ll alias has been defined before" $BASH_SOURCE:$LINENO ' bash -lixc : |&
grep 'll alias' -m1 -B1
Giving output like:
/home/muru/.bash_aliases:1 alias 'll=ls -AlhF'
TThe ll alias has been defined before /home/muru/.bashrc:116 alias 'ping=ping -c5'
You can even terminate the shell using this check:
$ PS4='$BASH_ALIASES["ll"]+"$(kill -9 $$)" $BASH_SOURCE:$LINENO ' bash -lixc : |& tail -n1
/home/muru/.bash_aliases:1 alias 'll=ls -AlhF'
add a comment |
up vote
-1
down vote
Check ~/.profile if it's not in ~/.bashrc
Or files included from there...
– Jeff Schaller
Nov 10 '16 at 22:55
add a comment |
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
13
down vote
accepted
Manual definition will be hard to spot (the history logs, maybe) though asking the shell to show what it is doing and then grep
should help find those set in a rc file:
bash -ixlc : 2>&1 | grep ...
zsh -ixc : 2>&1 | grep ...
If the shell isn't precisely capturing the necessary options with one of the above invocations (that interactively run the null command), then script
:
script somethingtogrep thatstrangeshell -x
...
grep ... somethingtogrep
Another option would be to use something like strace
or sysdig
to find all the files the shell touches, then go grep
those manually (handy if the shell or program does not have an -x
flag); the standard RC files are not sufficient for a manual filename check if something like oh-my-zsh or site-specific configurations are pulling in code from who knows where (or also there may be environment variables, as sorontar points out in their answer).
Thanks! Even though the output is a bit hard to parse, but I found the file that defined the alias I was looking for. When the alias isn't present anywhere in that list, would it be safe to assume the alias was defined manually?
– polemon
Nov 10 '16 at 22:58
@polemon somewhat safe; it could be (or have been) defined in a file that isn't being read in because of who-knows-what-reason-or-was-deleted (especially if there's some sort of shell framework adding complexity that the user does not understand).
– thrig
Nov 10 '16 at 23:01
1
To make the point where the alias is defined a bit easier to find, you can use PS4, which is prepended to every line in a trace:PS4='+The ll alias is "$BASH_ALIASES["ll"]" ' bash -ixlc :
– Mark Plotnick
Nov 11 '16 at 9:08
add a comment |
up vote
13
down vote
accepted
Manual definition will be hard to spot (the history logs, maybe) though asking the shell to show what it is doing and then grep
should help find those set in a rc file:
bash -ixlc : 2>&1 | grep ...
zsh -ixc : 2>&1 | grep ...
If the shell isn't precisely capturing the necessary options with one of the above invocations (that interactively run the null command), then script
:
script somethingtogrep thatstrangeshell -x
...
grep ... somethingtogrep
Another option would be to use something like strace
or sysdig
to find all the files the shell touches, then go grep
those manually (handy if the shell or program does not have an -x
flag); the standard RC files are not sufficient for a manual filename check if something like oh-my-zsh or site-specific configurations are pulling in code from who knows where (or also there may be environment variables, as sorontar points out in their answer).
Thanks! Even though the output is a bit hard to parse, but I found the file that defined the alias I was looking for. When the alias isn't present anywhere in that list, would it be safe to assume the alias was defined manually?
– polemon
Nov 10 '16 at 22:58
@polemon somewhat safe; it could be (or have been) defined in a file that isn't being read in because of who-knows-what-reason-or-was-deleted (especially if there's some sort of shell framework adding complexity that the user does not understand).
– thrig
Nov 10 '16 at 23:01
1
To make the point where the alias is defined a bit easier to find, you can use PS4, which is prepended to every line in a trace:PS4='+The ll alias is "$BASH_ALIASES["ll"]" ' bash -ixlc :
– Mark Plotnick
Nov 11 '16 at 9:08
add a comment |
up vote
13
down vote
accepted
up vote
13
down vote
accepted
Manual definition will be hard to spot (the history logs, maybe) though asking the shell to show what it is doing and then grep
should help find those set in a rc file:
bash -ixlc : 2>&1 | grep ...
zsh -ixc : 2>&1 | grep ...
If the shell isn't precisely capturing the necessary options with one of the above invocations (that interactively run the null command), then script
:
script somethingtogrep thatstrangeshell -x
...
grep ... somethingtogrep
Another option would be to use something like strace
or sysdig
to find all the files the shell touches, then go grep
those manually (handy if the shell or program does not have an -x
flag); the standard RC files are not sufficient for a manual filename check if something like oh-my-zsh or site-specific configurations are pulling in code from who knows where (or also there may be environment variables, as sorontar points out in their answer).
Manual definition will be hard to spot (the history logs, maybe) though asking the shell to show what it is doing and then grep
should help find those set in a rc file:
bash -ixlc : 2>&1 | grep ...
zsh -ixc : 2>&1 | grep ...
If the shell isn't precisely capturing the necessary options with one of the above invocations (that interactively run the null command), then script
:
script somethingtogrep thatstrangeshell -x
...
grep ... somethingtogrep
Another option would be to use something like strace
or sysdig
to find all the files the shell touches, then go grep
those manually (handy if the shell or program does not have an -x
flag); the standard RC files are not sufficient for a manual filename check if something like oh-my-zsh or site-specific configurations are pulling in code from who knows where (or also there may be environment variables, as sorontar points out in their answer).
edited Nov 10 '16 at 23:22
answered Nov 10 '16 at 22:44
thrig
23.7k12955
23.7k12955
Thanks! Even though the output is a bit hard to parse, but I found the file that defined the alias I was looking for. When the alias isn't present anywhere in that list, would it be safe to assume the alias was defined manually?
– polemon
Nov 10 '16 at 22:58
@polemon somewhat safe; it could be (or have been) defined in a file that isn't being read in because of who-knows-what-reason-or-was-deleted (especially if there's some sort of shell framework adding complexity that the user does not understand).
– thrig
Nov 10 '16 at 23:01
1
To make the point where the alias is defined a bit easier to find, you can use PS4, which is prepended to every line in a trace:PS4='+The ll alias is "$BASH_ALIASES["ll"]" ' bash -ixlc :
– Mark Plotnick
Nov 11 '16 at 9:08
add a comment |
Thanks! Even though the output is a bit hard to parse, but I found the file that defined the alias I was looking for. When the alias isn't present anywhere in that list, would it be safe to assume the alias was defined manually?
– polemon
Nov 10 '16 at 22:58
@polemon somewhat safe; it could be (or have been) defined in a file that isn't being read in because of who-knows-what-reason-or-was-deleted (especially if there's some sort of shell framework adding complexity that the user does not understand).
– thrig
Nov 10 '16 at 23:01
1
To make the point where the alias is defined a bit easier to find, you can use PS4, which is prepended to every line in a trace:PS4='+The ll alias is "$BASH_ALIASES["ll"]" ' bash -ixlc :
– Mark Plotnick
Nov 11 '16 at 9:08
Thanks! Even though the output is a bit hard to parse, but I found the file that defined the alias I was looking for. When the alias isn't present anywhere in that list, would it be safe to assume the alias was defined manually?
– polemon
Nov 10 '16 at 22:58
Thanks! Even though the output is a bit hard to parse, but I found the file that defined the alias I was looking for. When the alias isn't present anywhere in that list, would it be safe to assume the alias was defined manually?
– polemon
Nov 10 '16 at 22:58
@polemon somewhat safe; it could be (or have been) defined in a file that isn't being read in because of who-knows-what-reason-or-was-deleted (especially if there's some sort of shell framework adding complexity that the user does not understand).
– thrig
Nov 10 '16 at 23:01
@polemon somewhat safe; it could be (or have been) defined in a file that isn't being read in because of who-knows-what-reason-or-was-deleted (especially if there's some sort of shell framework adding complexity that the user does not understand).
– thrig
Nov 10 '16 at 23:01
1
1
To make the point where the alias is defined a bit easier to find, you can use PS4, which is prepended to every line in a trace:
PS4='+The ll alias is "$BASH_ALIASES["ll"]" ' bash -ixlc :
– Mark Plotnick
Nov 11 '16 at 9:08
To make the point where the alias is defined a bit easier to find, you can use PS4, which is prepended to every line in a trace:
PS4='+The ll alias is "$BASH_ALIASES["ll"]" ' bash -ixlc :
– Mark Plotnick
Nov 11 '16 at 9:08
add a comment |
up vote
5
down vote
Here is where I find grep -rl
very useful:
grep -rl alias ~/.bash* ~/.profile /etc/profile /etc/bash.bashrc
will tell you in which file the word alias
is used.
Probably in ~/.bashrc
and most certainly in ~/.bash_aliases
if it exists.
It is however impossible to be absolutely sure that that covers all options.
Those files may also call or load any other files.
An environment variable like ENV or $BASH_ENV
may direct bash to load some other files.
looks for the variable BASH_ENV in the environment, expands its value if it appears there, and uses the expanded value as the name of a file to read and execute.
And aliases may even be defined by setting a variable (emphasis mine):
BASH_ALIASES
An associative array variable whose members correspond to the internal list of aliases as maintained by the alias builtin. Elements added to this array appear in the alias list
grep -rl alias ~/.bash*
may falsely match history files, but +1 for pointing out the BASH_ALIASES array!
– Jeff Schaller
Nov 10 '16 at 23:59
add a comment |
up vote
5
down vote
Here is where I find grep -rl
very useful:
grep -rl alias ~/.bash* ~/.profile /etc/profile /etc/bash.bashrc
will tell you in which file the word alias
is used.
Probably in ~/.bashrc
and most certainly in ~/.bash_aliases
if it exists.
It is however impossible to be absolutely sure that that covers all options.
Those files may also call or load any other files.
An environment variable like ENV or $BASH_ENV
may direct bash to load some other files.
looks for the variable BASH_ENV in the environment, expands its value if it appears there, and uses the expanded value as the name of a file to read and execute.
And aliases may even be defined by setting a variable (emphasis mine):
BASH_ALIASES
An associative array variable whose members correspond to the internal list of aliases as maintained by the alias builtin. Elements added to this array appear in the alias list
grep -rl alias ~/.bash*
may falsely match history files, but +1 for pointing out the BASH_ALIASES array!
– Jeff Schaller
Nov 10 '16 at 23:59
add a comment |
up vote
5
down vote
up vote
5
down vote
Here is where I find grep -rl
very useful:
grep -rl alias ~/.bash* ~/.profile /etc/profile /etc/bash.bashrc
will tell you in which file the word alias
is used.
Probably in ~/.bashrc
and most certainly in ~/.bash_aliases
if it exists.
It is however impossible to be absolutely sure that that covers all options.
Those files may also call or load any other files.
An environment variable like ENV or $BASH_ENV
may direct bash to load some other files.
looks for the variable BASH_ENV in the environment, expands its value if it appears there, and uses the expanded value as the name of a file to read and execute.
And aliases may even be defined by setting a variable (emphasis mine):
BASH_ALIASES
An associative array variable whose members correspond to the internal list of aliases as maintained by the alias builtin. Elements added to this array appear in the alias list
Here is where I find grep -rl
very useful:
grep -rl alias ~/.bash* ~/.profile /etc/profile /etc/bash.bashrc
will tell you in which file the word alias
is used.
Probably in ~/.bashrc
and most certainly in ~/.bash_aliases
if it exists.
It is however impossible to be absolutely sure that that covers all options.
Those files may also call or load any other files.
An environment variable like ENV or $BASH_ENV
may direct bash to load some other files.
looks for the variable BASH_ENV in the environment, expands its value if it appears there, and uses the expanded value as the name of a file to read and execute.
And aliases may even be defined by setting a variable (emphasis mine):
BASH_ALIASES
An associative array variable whose members correspond to the internal list of aliases as maintained by the alias builtin. Elements added to this array appear in the alias list
edited Nov 10 '16 at 23:14
answered Nov 10 '16 at 22:58
sorontar
4,378828
4,378828
grep -rl alias ~/.bash*
may falsely match history files, but +1 for pointing out the BASH_ALIASES array!
– Jeff Schaller
Nov 10 '16 at 23:59
add a comment |
grep -rl alias ~/.bash*
may falsely match history files, but +1 for pointing out the BASH_ALIASES array!
– Jeff Schaller
Nov 10 '16 at 23:59
grep -rl alias ~/.bash*
may falsely match history files, but +1 for pointing out the BASH_ALIASES array!– Jeff Schaller
Nov 10 '16 at 23:59
grep -rl alias ~/.bash*
may falsely match history files, but +1 for pointing out the BASH_ALIASES array!– Jeff Schaller
Nov 10 '16 at 23:59
add a comment |
up vote
1
down vote
I don't know of a way to actually list the source of your aliases, but since it looks like you're using bash I think these are the possible source files:
/etc/profile
~/.profile
/etc/bash.bashrc
~/.bash_profile
~/.bashrc
You should be able to grep through those to find the alias, e.g. grep 'ls -l --color=auto' /etc/profile ~/.profile /etc/bash.bashrc ~/.bash_profile ~/.bashrc
.
Or files included from there...
– Jeff Schaller
Nov 10 '16 at 22:56
@JeffSchaller - Right, you'd need something more complex for that likebash -x
, as you mentioned. I figured the above was easy enough to run quickly and if it doesn't find the alias you can read through the execution steps.
– edaemon
Nov 10 '16 at 23:32
add a comment |
up vote
1
down vote
I don't know of a way to actually list the source of your aliases, but since it looks like you're using bash I think these are the possible source files:
/etc/profile
~/.profile
/etc/bash.bashrc
~/.bash_profile
~/.bashrc
You should be able to grep through those to find the alias, e.g. grep 'ls -l --color=auto' /etc/profile ~/.profile /etc/bash.bashrc ~/.bash_profile ~/.bashrc
.
Or files included from there...
– Jeff Schaller
Nov 10 '16 at 22:56
@JeffSchaller - Right, you'd need something more complex for that likebash -x
, as you mentioned. I figured the above was easy enough to run quickly and if it doesn't find the alias you can read through the execution steps.
– edaemon
Nov 10 '16 at 23:32
add a comment |
up vote
1
down vote
up vote
1
down vote
I don't know of a way to actually list the source of your aliases, but since it looks like you're using bash I think these are the possible source files:
/etc/profile
~/.profile
/etc/bash.bashrc
~/.bash_profile
~/.bashrc
You should be able to grep through those to find the alias, e.g. grep 'ls -l --color=auto' /etc/profile ~/.profile /etc/bash.bashrc ~/.bash_profile ~/.bashrc
.
I don't know of a way to actually list the source of your aliases, but since it looks like you're using bash I think these are the possible source files:
/etc/profile
~/.profile
/etc/bash.bashrc
~/.bash_profile
~/.bashrc
You should be able to grep through those to find the alias, e.g. grep 'ls -l --color=auto' /etc/profile ~/.profile /etc/bash.bashrc ~/.bash_profile ~/.bashrc
.
answered Nov 10 '16 at 22:39
edaemon
1665
1665
Or files included from there...
– Jeff Schaller
Nov 10 '16 at 22:56
@JeffSchaller - Right, you'd need something more complex for that likebash -x
, as you mentioned. I figured the above was easy enough to run quickly and if it doesn't find the alias you can read through the execution steps.
– edaemon
Nov 10 '16 at 23:32
add a comment |
Or files included from there...
– Jeff Schaller
Nov 10 '16 at 22:56
@JeffSchaller - Right, you'd need something more complex for that likebash -x
, as you mentioned. I figured the above was easy enough to run quickly and if it doesn't find the alias you can read through the execution steps.
– edaemon
Nov 10 '16 at 23:32
Or files included from there...
– Jeff Schaller
Nov 10 '16 at 22:56
Or files included from there...
– Jeff Schaller
Nov 10 '16 at 22:56
@JeffSchaller - Right, you'd need something more complex for that like
bash -x
, as you mentioned. I figured the above was easy enough to run quickly and if it doesn't find the alias you can read through the execution steps.– edaemon
Nov 10 '16 at 23:32
@JeffSchaller - Right, you'd need something more complex for that like
bash -x
, as you mentioned. I figured the above was easy enough to run quickly and if it doesn't find the alias you can read through the execution steps.– edaemon
Nov 10 '16 at 23:32
add a comment |
up vote
0
down vote
I've had success simply using which
.
[crclayton@pc scripts]$ which foo
foo: aliased to python $HOME/projects/python/foo.py
which
can handle aliases in tcsh (and maybe earlier csh) and zsh where it is a builtin, and in bash using default profile on RedHat-family which has a kludge to run the (external) GNU program but feed it shell alias data, otherwise not. More important it only tells what the alias is set to, not where it was set, which was the Q here.
– dave_thompson_085
Nov 22 at 7:48
add a comment |
up vote
0
down vote
I've had success simply using which
.
[crclayton@pc scripts]$ which foo
foo: aliased to python $HOME/projects/python/foo.py
which
can handle aliases in tcsh (and maybe earlier csh) and zsh where it is a builtin, and in bash using default profile on RedHat-family which has a kludge to run the (external) GNU program but feed it shell alias data, otherwise not. More important it only tells what the alias is set to, not where it was set, which was the Q here.
– dave_thompson_085
Nov 22 at 7:48
add a comment |
up vote
0
down vote
up vote
0
down vote
I've had success simply using which
.
[crclayton@pc scripts]$ which foo
foo: aliased to python $HOME/projects/python/foo.py
I've had success simply using which
.
[crclayton@pc scripts]$ which foo
foo: aliased to python $HOME/projects/python/foo.py
answered Jan 31 at 18:52
Charles Clayton
1094
1094
which
can handle aliases in tcsh (and maybe earlier csh) and zsh where it is a builtin, and in bash using default profile on RedHat-family which has a kludge to run the (external) GNU program but feed it shell alias data, otherwise not. More important it only tells what the alias is set to, not where it was set, which was the Q here.
– dave_thompson_085
Nov 22 at 7:48
add a comment |
which
can handle aliases in tcsh (and maybe earlier csh) and zsh where it is a builtin, and in bash using default profile on RedHat-family which has a kludge to run the (external) GNU program but feed it shell alias data, otherwise not. More important it only tells what the alias is set to, not where it was set, which was the Q here.
– dave_thompson_085
Nov 22 at 7:48
which
can handle aliases in tcsh (and maybe earlier csh) and zsh where it is a builtin, and in bash using default profile on RedHat-family which has a kludge to run the (external) GNU program but feed it shell alias data, otherwise not. More important it only tells what the alias is set to, not where it was set, which was the Q here.– dave_thompson_085
Nov 22 at 7:48
which
can handle aliases in tcsh (and maybe earlier csh) and zsh where it is a builtin, and in bash using default profile on RedHat-family which has a kludge to run the (external) GNU program but feed it shell alias data, otherwise not. More important it only tells what the alias is set to, not where it was set, which was the Q here.– dave_thompson_085
Nov 22 at 7:48
add a comment |
up vote
0
down vote
Combining thrig's answer with @MarkPlotnick's suggestion, you can test whether BASH_ALIASES[ll]
is set to narrow it down. The BASH_SOURCE
array and LINENO
variables are particularly useful here. Unfortunately, the check whether BASH_ALIASES[ll]
is set will only succeed after the alias has been set, and so the first such line could be in another file altogether.
PS4='$BASH_ALIASES["ll"]+"The ll alias has been defined before" $BASH_SOURCE:$LINENO ' bash -lixc : |&
grep 'll alias' -m1 -B1
Giving output like:
/home/muru/.bash_aliases:1 alias 'll=ls -AlhF'
TThe ll alias has been defined before /home/muru/.bashrc:116 alias 'ping=ping -c5'
You can even terminate the shell using this check:
$ PS4='$BASH_ALIASES["ll"]+"$(kill -9 $$)" $BASH_SOURCE:$LINENO ' bash -lixc : |& tail -n1
/home/muru/.bash_aliases:1 alias 'll=ls -AlhF'
add a comment |
up vote
0
down vote
Combining thrig's answer with @MarkPlotnick's suggestion, you can test whether BASH_ALIASES[ll]
is set to narrow it down. The BASH_SOURCE
array and LINENO
variables are particularly useful here. Unfortunately, the check whether BASH_ALIASES[ll]
is set will only succeed after the alias has been set, and so the first such line could be in another file altogether.
PS4='$BASH_ALIASES["ll"]+"The ll alias has been defined before" $BASH_SOURCE:$LINENO ' bash -lixc : |&
grep 'll alias' -m1 -B1
Giving output like:
/home/muru/.bash_aliases:1 alias 'll=ls -AlhF'
TThe ll alias has been defined before /home/muru/.bashrc:116 alias 'ping=ping -c5'
You can even terminate the shell using this check:
$ PS4='$BASH_ALIASES["ll"]+"$(kill -9 $$)" $BASH_SOURCE:$LINENO ' bash -lixc : |& tail -n1
/home/muru/.bash_aliases:1 alias 'll=ls -AlhF'
add a comment |
up vote
0
down vote
up vote
0
down vote
Combining thrig's answer with @MarkPlotnick's suggestion, you can test whether BASH_ALIASES[ll]
is set to narrow it down. The BASH_SOURCE
array and LINENO
variables are particularly useful here. Unfortunately, the check whether BASH_ALIASES[ll]
is set will only succeed after the alias has been set, and so the first such line could be in another file altogether.
PS4='$BASH_ALIASES["ll"]+"The ll alias has been defined before" $BASH_SOURCE:$LINENO ' bash -lixc : |&
grep 'll alias' -m1 -B1
Giving output like:
/home/muru/.bash_aliases:1 alias 'll=ls -AlhF'
TThe ll alias has been defined before /home/muru/.bashrc:116 alias 'ping=ping -c5'
You can even terminate the shell using this check:
$ PS4='$BASH_ALIASES["ll"]+"$(kill -9 $$)" $BASH_SOURCE:$LINENO ' bash -lixc : |& tail -n1
/home/muru/.bash_aliases:1 alias 'll=ls -AlhF'
Combining thrig's answer with @MarkPlotnick's suggestion, you can test whether BASH_ALIASES[ll]
is set to narrow it down. The BASH_SOURCE
array and LINENO
variables are particularly useful here. Unfortunately, the check whether BASH_ALIASES[ll]
is set will only succeed after the alias has been set, and so the first such line could be in another file altogether.
PS4='$BASH_ALIASES["ll"]+"The ll alias has been defined before" $BASH_SOURCE:$LINENO ' bash -lixc : |&
grep 'll alias' -m1 -B1
Giving output like:
/home/muru/.bash_aliases:1 alias 'll=ls -AlhF'
TThe ll alias has been defined before /home/muru/.bashrc:116 alias 'ping=ping -c5'
You can even terminate the shell using this check:
$ PS4='$BASH_ALIASES["ll"]+"$(kill -9 $$)" $BASH_SOURCE:$LINENO ' bash -lixc : |& tail -n1
/home/muru/.bash_aliases:1 alias 'll=ls -AlhF'
edited Nov 22 at 4:40
answered Nov 22 at 4:35
muru
35.2k581155
35.2k581155
add a comment |
add a comment |
up vote
-1
down vote
Check ~/.profile if it's not in ~/.bashrc
Or files included from there...
– Jeff Schaller
Nov 10 '16 at 22:55
add a comment |
up vote
-1
down vote
Check ~/.profile if it's not in ~/.bashrc
Or files included from there...
– Jeff Schaller
Nov 10 '16 at 22:55
add a comment |
up vote
-1
down vote
up vote
-1
down vote
Check ~/.profile if it's not in ~/.bashrc
Check ~/.profile if it's not in ~/.bashrc
answered Nov 10 '16 at 22:22
Michael Tatum
1
1
Or files included from there...
– Jeff Schaller
Nov 10 '16 at 22:55
add a comment |
Or files included from there...
– Jeff Schaller
Nov 10 '16 at 22:55
Or files included from there...
– Jeff Schaller
Nov 10 '16 at 22:55
Or files included from there...
– Jeff Schaller
Nov 10 '16 at 22:55
add a comment |
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f322459%2fis-it-possible-to-check-where-an-alias-was-defined%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Off the cuff I'd say run
bash -xl
– Jeff Schaller
Nov 10 '16 at 22:19
Related unix.stackexchange.com/questions/322817/…
– icarus
Nov 12 '16 at 22:22