Why doesn't my Bash script recognize aliases?
Clash Royale CLAN TAG#URR8PPP
up vote
170
down vote
favorite
In my ~/.bashrc
file reside two definitions:
commandA
, which is an alias to a longer pathcommandB
, which is an alias to a Bash script
I want to process the same file with these two commands, so I wrote the following Bash script:
#!/bin/bash
for file in "$@"
do
commandA $file
commandB $file
done
Even after logging out of my session and logging back in, Bash prompts me with command not found
errors for both commands when I run this script.
What am I doing wrong?
bash alias
add a comment |Â
up vote
170
down vote
favorite
In my ~/.bashrc
file reside two definitions:
commandA
, which is an alias to a longer pathcommandB
, which is an alias to a Bash script
I want to process the same file with these two commands, so I wrote the following Bash script:
#!/bin/bash
for file in "$@"
do
commandA $file
commandB $file
done
Even after logging out of my session and logging back in, Bash prompts me with command not found
errors for both commands when I run this script.
What am I doing wrong?
bash alias
9
BTW, there's no need to log in and out to have an alias recognized. You need just dosource ~/.bashrc
.
â Tshepang
Nov 25 '10 at 19:10
For my case I was connected by SSH agent remotely, after adding alias as I closed the SSH agent and connected again it started working.
â dav
Sep 6 '15 at 5:05
add a comment |Â
up vote
170
down vote
favorite
up vote
170
down vote
favorite
In my ~/.bashrc
file reside two definitions:
commandA
, which is an alias to a longer pathcommandB
, which is an alias to a Bash script
I want to process the same file with these two commands, so I wrote the following Bash script:
#!/bin/bash
for file in "$@"
do
commandA $file
commandB $file
done
Even after logging out of my session and logging back in, Bash prompts me with command not found
errors for both commands when I run this script.
What am I doing wrong?
bash alias
In my ~/.bashrc
file reside two definitions:
commandA
, which is an alias to a longer pathcommandB
, which is an alias to a Bash script
I want to process the same file with these two commands, so I wrote the following Bash script:
#!/bin/bash
for file in "$@"
do
commandA $file
commandB $file
done
Even after logging out of my session and logging back in, Bash prompts me with command not found
errors for both commands when I run this script.
What am I doing wrong?
bash alias
edited Dec 16 '17 at 13:21
ilkkachu
50.5k677138
50.5k677138
asked Sep 2 '10 at 9:38
Zaid
3,48493033
3,48493033
9
BTW, there's no need to log in and out to have an alias recognized. You need just dosource ~/.bashrc
.
â Tshepang
Nov 25 '10 at 19:10
For my case I was connected by SSH agent remotely, after adding alias as I closed the SSH agent and connected again it started working.
â dav
Sep 6 '15 at 5:05
add a comment |Â
9
BTW, there's no need to log in and out to have an alias recognized. You need just dosource ~/.bashrc
.
â Tshepang
Nov 25 '10 at 19:10
For my case I was connected by SSH agent remotely, after adding alias as I closed the SSH agent and connected again it started working.
â dav
Sep 6 '15 at 5:05
9
9
BTW, there's no need to log in and out to have an alias recognized. You need just do
source ~/.bashrc
.â Tshepang
Nov 25 '10 at 19:10
BTW, there's no need to log in and out to have an alias recognized. You need just do
source ~/.bashrc
.â Tshepang
Nov 25 '10 at 19:10
For my case I was connected by SSH agent remotely, after adding alias as I closed the SSH agent and connected again it started working.
â dav
Sep 6 '15 at 5:05
For my case I was connected by SSH agent remotely, after adding alias as I closed the SSH agent and connected again it started working.
â dav
Sep 6 '15 at 5:05
add a comment |Â
5 Answers
5
active
oldest
votes
up vote
99
down vote
accepted
First of all, as ddeimeke said, aliases by default are not expanded in non-interactive shells.
Second, .bashrc
is not read by non-interactive shells unless you set the BASH_ENV
environment variable.
But most importantly: don't do that! Please? One day you will move that script somewhere where the necessary aliases are not set and it will break again.
Instead set and use environment variables as shortcuts in your script:
#!/bin/bash
CMDA=/path/to/gizmo
CMDB=/path/to/huzzah.sh
for file in "$@"
do
$CMDA "$file"
$CMDB "$file"
done
3
That solution doesnâÂÂt work for the usualalias
use cases. E.g.alias mv="mv -v --backup=numbered"
.
â Evi1M4chine
Apr 23 '16 at 20:11
@Evi1M4chine: Yes, it does. At least after I reverted Gilles unnecessary edit. But it might be better to use a different variable for the parameters, anyway.
â user601
Apr 24 '16 at 15:50
1
Ah, note the lack of quotes around$CMDA
/$CMDB
⦠Apart from uppercase variables being reserved for bash itself in bash, and it indeed working, that lack of quotes makes me really uneasy⦠Thanks anyway.
â Evi1M4chine
Apr 30 '16 at 0:26
@Evi1M4chine: Uh, what? 1. I removed the quotes myself in the most recent edit. 2. where do you get the "reserved for bash itself" from? this would be the first I've heard of it. 3. If that makes you uneasy, how do you feel about using bash in the first place? Anyway, use a separate variable for the options as I told you.
â user601
Apr 30 '16 at 17:46
1
@alvas: the assumption is thatgizmo
is not on the path or there is a command with the same name but a higher priority. else you could simple setCMDA
to plaingizmo
in the first place.
â user601
Apr 5 '17 at 9:20
 |Â
show 5 more comments
up vote
114
down vote
If you look into the bash manpage you find:
Aliases are not expanded when the
shell is not interactive, unless the
expand_aliases shell option is set
using shopt (see the description of
shopt under SHELL BUILTIN COMMANDS
below).
So put a
shopt -s expand_aliases
in your script.
Make sure to source your aliases file after setting this in your script.
shopt -s expand_aliases
source ~/.bash_aliases
1
I placed it in my script, but it's still not working. Same error.
â Zaid
Sep 2 '10 at 10:29
4
Addingshopt -s expand_aliases source ~/.bash_aliases
works perfectly for me. Often there is a form of interactive shell detection in .bashrc like this:# If not running interactively, don't do anything [ -z "$PS1" ] && return
@Zaid, Maybe you want to check for that in the file you sourced.
â Frank Schubert
Apr 4 '13 at 1:46
1
excellent! saved my scripts!! :) it is so hard to read/search/browse info and manpages in the terminal that I just gave up long ago and go search on the internet...
â Aquarius Power
Sep 17 '13 at 19:24
2
Curiously,shopt -s expand_aliases
doesn't have to go before the alias definition but before the alias use. Adding to @FrankSchubert: Interactive shell detection may also be done using$-
which contains the options for the shell, specificallyi
if the shell is interactive.
â valid
Mar 20 '15 at 14:12
2
this isn't a correct answer... Sourcing your aliases inside your script isn't the answer. Your~/.bash_aliases
might depend on other stuff previously loaded on an interactive shell... The closest thing I found is changing your hashbang to#!/bin/bash -li
Still not perfect. Ideally you should use functions and not aliases.
â Stefanos Kalantzis
Feb 5 '16 at 11:47
 |Â
show 2 more comments
up vote
37
down vote
Aliases can't be exported so they're not available in shell scripts in which they aren't defined. In other words, if you define them in ~/.bashrc
they're not available to your_script.sh
(unless you source ~/.bashrc
in the script, which I wouldn't recommend but there are ways to do this properly).
However, functions can be exported and would be available to shell scripts that are run from an environment in which they are defined. This can be done by placing this in your bashrc:
foo()
echo "Hello World!"
export -f foo
As the Bash manual says, "For almost every purpose, shell functions are preferred over aliases."
1
While this doesn't technically answer the question, as you say you can simply replacealias commandA=...
withcommandA() ...
thenexport commandA
and you get identical behavior to the alias. So this is pretty much an identical alternative to aliases as far as I know that works great in bash scripts
â Phylliida
May 21 at 18:35
add a comment |Â
up vote
8
down vote
[cmd line] > bash -i [your script's file path]
The i
is for interactive and sources your bash
profile for you.
add a comment |Â
up vote
-4
down vote
I found sometimes bash script doesn't recognize export either. However, changing it to
#!/bin/sh
works for me.
1
No, it didn't...
â Hafiz Temuri
Apr 22 at 17:12
add a comment |Â
protected by slm⦠Apr 18 '14 at 15:08
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
99
down vote
accepted
First of all, as ddeimeke said, aliases by default are not expanded in non-interactive shells.
Second, .bashrc
is not read by non-interactive shells unless you set the BASH_ENV
environment variable.
But most importantly: don't do that! Please? One day you will move that script somewhere where the necessary aliases are not set and it will break again.
Instead set and use environment variables as shortcuts in your script:
#!/bin/bash
CMDA=/path/to/gizmo
CMDB=/path/to/huzzah.sh
for file in "$@"
do
$CMDA "$file"
$CMDB "$file"
done
3
That solution doesnâÂÂt work for the usualalias
use cases. E.g.alias mv="mv -v --backup=numbered"
.
â Evi1M4chine
Apr 23 '16 at 20:11
@Evi1M4chine: Yes, it does. At least after I reverted Gilles unnecessary edit. But it might be better to use a different variable for the parameters, anyway.
â user601
Apr 24 '16 at 15:50
1
Ah, note the lack of quotes around$CMDA
/$CMDB
⦠Apart from uppercase variables being reserved for bash itself in bash, and it indeed working, that lack of quotes makes me really uneasy⦠Thanks anyway.
â Evi1M4chine
Apr 30 '16 at 0:26
@Evi1M4chine: Uh, what? 1. I removed the quotes myself in the most recent edit. 2. where do you get the "reserved for bash itself" from? this would be the first I've heard of it. 3. If that makes you uneasy, how do you feel about using bash in the first place? Anyway, use a separate variable for the options as I told you.
â user601
Apr 30 '16 at 17:46
1
@alvas: the assumption is thatgizmo
is not on the path or there is a command with the same name but a higher priority. else you could simple setCMDA
to plaingizmo
in the first place.
â user601
Apr 5 '17 at 9:20
 |Â
show 5 more comments
up vote
99
down vote
accepted
First of all, as ddeimeke said, aliases by default are not expanded in non-interactive shells.
Second, .bashrc
is not read by non-interactive shells unless you set the BASH_ENV
environment variable.
But most importantly: don't do that! Please? One day you will move that script somewhere where the necessary aliases are not set and it will break again.
Instead set and use environment variables as shortcuts in your script:
#!/bin/bash
CMDA=/path/to/gizmo
CMDB=/path/to/huzzah.sh
for file in "$@"
do
$CMDA "$file"
$CMDB "$file"
done
3
That solution doesnâÂÂt work for the usualalias
use cases. E.g.alias mv="mv -v --backup=numbered"
.
â Evi1M4chine
Apr 23 '16 at 20:11
@Evi1M4chine: Yes, it does. At least after I reverted Gilles unnecessary edit. But it might be better to use a different variable for the parameters, anyway.
â user601
Apr 24 '16 at 15:50
1
Ah, note the lack of quotes around$CMDA
/$CMDB
⦠Apart from uppercase variables being reserved for bash itself in bash, and it indeed working, that lack of quotes makes me really uneasy⦠Thanks anyway.
â Evi1M4chine
Apr 30 '16 at 0:26
@Evi1M4chine: Uh, what? 1. I removed the quotes myself in the most recent edit. 2. where do you get the "reserved for bash itself" from? this would be the first I've heard of it. 3. If that makes you uneasy, how do you feel about using bash in the first place? Anyway, use a separate variable for the options as I told you.
â user601
Apr 30 '16 at 17:46
1
@alvas: the assumption is thatgizmo
is not on the path or there is a command with the same name but a higher priority. else you could simple setCMDA
to plaingizmo
in the first place.
â user601
Apr 5 '17 at 9:20
 |Â
show 5 more comments
up vote
99
down vote
accepted
up vote
99
down vote
accepted
First of all, as ddeimeke said, aliases by default are not expanded in non-interactive shells.
Second, .bashrc
is not read by non-interactive shells unless you set the BASH_ENV
environment variable.
But most importantly: don't do that! Please? One day you will move that script somewhere where the necessary aliases are not set and it will break again.
Instead set and use environment variables as shortcuts in your script:
#!/bin/bash
CMDA=/path/to/gizmo
CMDB=/path/to/huzzah.sh
for file in "$@"
do
$CMDA "$file"
$CMDB "$file"
done
First of all, as ddeimeke said, aliases by default are not expanded in non-interactive shells.
Second, .bashrc
is not read by non-interactive shells unless you set the BASH_ENV
environment variable.
But most importantly: don't do that! Please? One day you will move that script somewhere where the necessary aliases are not set and it will break again.
Instead set and use environment variables as shortcuts in your script:
#!/bin/bash
CMDA=/path/to/gizmo
CMDB=/path/to/huzzah.sh
for file in "$@"
do
$CMDA "$file"
$CMDB "$file"
done
edited Apr 24 '16 at 15:52
answered Sep 2 '10 at 12:37
user601
3
That solution doesnâÂÂt work for the usualalias
use cases. E.g.alias mv="mv -v --backup=numbered"
.
â Evi1M4chine
Apr 23 '16 at 20:11
@Evi1M4chine: Yes, it does. At least after I reverted Gilles unnecessary edit. But it might be better to use a different variable for the parameters, anyway.
â user601
Apr 24 '16 at 15:50
1
Ah, note the lack of quotes around$CMDA
/$CMDB
⦠Apart from uppercase variables being reserved for bash itself in bash, and it indeed working, that lack of quotes makes me really uneasy⦠Thanks anyway.
â Evi1M4chine
Apr 30 '16 at 0:26
@Evi1M4chine: Uh, what? 1. I removed the quotes myself in the most recent edit. 2. where do you get the "reserved for bash itself" from? this would be the first I've heard of it. 3. If that makes you uneasy, how do you feel about using bash in the first place? Anyway, use a separate variable for the options as I told you.
â user601
Apr 30 '16 at 17:46
1
@alvas: the assumption is thatgizmo
is not on the path or there is a command with the same name but a higher priority. else you could simple setCMDA
to plaingizmo
in the first place.
â user601
Apr 5 '17 at 9:20
 |Â
show 5 more comments
3
That solution doesnâÂÂt work for the usualalias
use cases. E.g.alias mv="mv -v --backup=numbered"
.
â Evi1M4chine
Apr 23 '16 at 20:11
@Evi1M4chine: Yes, it does. At least after I reverted Gilles unnecessary edit. But it might be better to use a different variable for the parameters, anyway.
â user601
Apr 24 '16 at 15:50
1
Ah, note the lack of quotes around$CMDA
/$CMDB
⦠Apart from uppercase variables being reserved for bash itself in bash, and it indeed working, that lack of quotes makes me really uneasy⦠Thanks anyway.
â Evi1M4chine
Apr 30 '16 at 0:26
@Evi1M4chine: Uh, what? 1. I removed the quotes myself in the most recent edit. 2. where do you get the "reserved for bash itself" from? this would be the first I've heard of it. 3. If that makes you uneasy, how do you feel about using bash in the first place? Anyway, use a separate variable for the options as I told you.
â user601
Apr 30 '16 at 17:46
1
@alvas: the assumption is thatgizmo
is not on the path or there is a command with the same name but a higher priority. else you could simple setCMDA
to plaingizmo
in the first place.
â user601
Apr 5 '17 at 9:20
3
3
That solution doesnâÂÂt work for the usual
alias
use cases. E.g. alias mv="mv -v --backup=numbered"
.â Evi1M4chine
Apr 23 '16 at 20:11
That solution doesnâÂÂt work for the usual
alias
use cases. E.g. alias mv="mv -v --backup=numbered"
.â Evi1M4chine
Apr 23 '16 at 20:11
@Evi1M4chine: Yes, it does. At least after I reverted Gilles unnecessary edit. But it might be better to use a different variable for the parameters, anyway.
â user601
Apr 24 '16 at 15:50
@Evi1M4chine: Yes, it does. At least after I reverted Gilles unnecessary edit. But it might be better to use a different variable for the parameters, anyway.
â user601
Apr 24 '16 at 15:50
1
1
Ah, note the lack of quotes around
$CMDA
/ $CMDB
⦠Apart from uppercase variables being reserved for bash itself in bash, and it indeed working, that lack of quotes makes me really uneasy⦠Thanks anyway.â Evi1M4chine
Apr 30 '16 at 0:26
Ah, note the lack of quotes around
$CMDA
/ $CMDB
⦠Apart from uppercase variables being reserved for bash itself in bash, and it indeed working, that lack of quotes makes me really uneasy⦠Thanks anyway.â Evi1M4chine
Apr 30 '16 at 0:26
@Evi1M4chine: Uh, what? 1. I removed the quotes myself in the most recent edit. 2. where do you get the "reserved for bash itself" from? this would be the first I've heard of it. 3. If that makes you uneasy, how do you feel about using bash in the first place? Anyway, use a separate variable for the options as I told you.
â user601
Apr 30 '16 at 17:46
@Evi1M4chine: Uh, what? 1. I removed the quotes myself in the most recent edit. 2. where do you get the "reserved for bash itself" from? this would be the first I've heard of it. 3. If that makes you uneasy, how do you feel about using bash in the first place? Anyway, use a separate variable for the options as I told you.
â user601
Apr 30 '16 at 17:46
1
1
@alvas: the assumption is that
gizmo
is not on the path or there is a command with the same name but a higher priority. else you could simple set CMDA
to plain gizmo
in the first place.â user601
Apr 5 '17 at 9:20
@alvas: the assumption is that
gizmo
is not on the path or there is a command with the same name but a higher priority. else you could simple set CMDA
to plain gizmo
in the first place.â user601
Apr 5 '17 at 9:20
 |Â
show 5 more comments
up vote
114
down vote
If you look into the bash manpage you find:
Aliases are not expanded when the
shell is not interactive, unless the
expand_aliases shell option is set
using shopt (see the description of
shopt under SHELL BUILTIN COMMANDS
below).
So put a
shopt -s expand_aliases
in your script.
Make sure to source your aliases file after setting this in your script.
shopt -s expand_aliases
source ~/.bash_aliases
1
I placed it in my script, but it's still not working. Same error.
â Zaid
Sep 2 '10 at 10:29
4
Addingshopt -s expand_aliases source ~/.bash_aliases
works perfectly for me. Often there is a form of interactive shell detection in .bashrc like this:# If not running interactively, don't do anything [ -z "$PS1" ] && return
@Zaid, Maybe you want to check for that in the file you sourced.
â Frank Schubert
Apr 4 '13 at 1:46
1
excellent! saved my scripts!! :) it is so hard to read/search/browse info and manpages in the terminal that I just gave up long ago and go search on the internet...
â Aquarius Power
Sep 17 '13 at 19:24
2
Curiously,shopt -s expand_aliases
doesn't have to go before the alias definition but before the alias use. Adding to @FrankSchubert: Interactive shell detection may also be done using$-
which contains the options for the shell, specificallyi
if the shell is interactive.
â valid
Mar 20 '15 at 14:12
2
this isn't a correct answer... Sourcing your aliases inside your script isn't the answer. Your~/.bash_aliases
might depend on other stuff previously loaded on an interactive shell... The closest thing I found is changing your hashbang to#!/bin/bash -li
Still not perfect. Ideally you should use functions and not aliases.
â Stefanos Kalantzis
Feb 5 '16 at 11:47
 |Â
show 2 more comments
up vote
114
down vote
If you look into the bash manpage you find:
Aliases are not expanded when the
shell is not interactive, unless the
expand_aliases shell option is set
using shopt (see the description of
shopt under SHELL BUILTIN COMMANDS
below).
So put a
shopt -s expand_aliases
in your script.
Make sure to source your aliases file after setting this in your script.
shopt -s expand_aliases
source ~/.bash_aliases
1
I placed it in my script, but it's still not working. Same error.
â Zaid
Sep 2 '10 at 10:29
4
Addingshopt -s expand_aliases source ~/.bash_aliases
works perfectly for me. Often there is a form of interactive shell detection in .bashrc like this:# If not running interactively, don't do anything [ -z "$PS1" ] && return
@Zaid, Maybe you want to check for that in the file you sourced.
â Frank Schubert
Apr 4 '13 at 1:46
1
excellent! saved my scripts!! :) it is so hard to read/search/browse info and manpages in the terminal that I just gave up long ago and go search on the internet...
â Aquarius Power
Sep 17 '13 at 19:24
2
Curiously,shopt -s expand_aliases
doesn't have to go before the alias definition but before the alias use. Adding to @FrankSchubert: Interactive shell detection may also be done using$-
which contains the options for the shell, specificallyi
if the shell is interactive.
â valid
Mar 20 '15 at 14:12
2
this isn't a correct answer... Sourcing your aliases inside your script isn't the answer. Your~/.bash_aliases
might depend on other stuff previously loaded on an interactive shell... The closest thing I found is changing your hashbang to#!/bin/bash -li
Still not perfect. Ideally you should use functions and not aliases.
â Stefanos Kalantzis
Feb 5 '16 at 11:47
 |Â
show 2 more comments
up vote
114
down vote
up vote
114
down vote
If you look into the bash manpage you find:
Aliases are not expanded when the
shell is not interactive, unless the
expand_aliases shell option is set
using shopt (see the description of
shopt under SHELL BUILTIN COMMANDS
below).
So put a
shopt -s expand_aliases
in your script.
Make sure to source your aliases file after setting this in your script.
shopt -s expand_aliases
source ~/.bash_aliases
If you look into the bash manpage you find:
Aliases are not expanded when the
shell is not interactive, unless the
expand_aliases shell option is set
using shopt (see the description of
shopt under SHELL BUILTIN COMMANDS
below).
So put a
shopt -s expand_aliases
in your script.
Make sure to source your aliases file after setting this in your script.
shopt -s expand_aliases
source ~/.bash_aliases
edited Nov 21 '12 at 21:48
Stéphane Chazelas
283k53521855
283k53521855
answered Sep 2 '10 at 10:20
ddeimeke
2,59211216
2,59211216
1
I placed it in my script, but it's still not working. Same error.
â Zaid
Sep 2 '10 at 10:29
4
Addingshopt -s expand_aliases source ~/.bash_aliases
works perfectly for me. Often there is a form of interactive shell detection in .bashrc like this:# If not running interactively, don't do anything [ -z "$PS1" ] && return
@Zaid, Maybe you want to check for that in the file you sourced.
â Frank Schubert
Apr 4 '13 at 1:46
1
excellent! saved my scripts!! :) it is so hard to read/search/browse info and manpages in the terminal that I just gave up long ago and go search on the internet...
â Aquarius Power
Sep 17 '13 at 19:24
2
Curiously,shopt -s expand_aliases
doesn't have to go before the alias definition but before the alias use. Adding to @FrankSchubert: Interactive shell detection may also be done using$-
which contains the options for the shell, specificallyi
if the shell is interactive.
â valid
Mar 20 '15 at 14:12
2
this isn't a correct answer... Sourcing your aliases inside your script isn't the answer. Your~/.bash_aliases
might depend on other stuff previously loaded on an interactive shell... The closest thing I found is changing your hashbang to#!/bin/bash -li
Still not perfect. Ideally you should use functions and not aliases.
â Stefanos Kalantzis
Feb 5 '16 at 11:47
 |Â
show 2 more comments
1
I placed it in my script, but it's still not working. Same error.
â Zaid
Sep 2 '10 at 10:29
4
Addingshopt -s expand_aliases source ~/.bash_aliases
works perfectly for me. Often there is a form of interactive shell detection in .bashrc like this:# If not running interactively, don't do anything [ -z "$PS1" ] && return
@Zaid, Maybe you want to check for that in the file you sourced.
â Frank Schubert
Apr 4 '13 at 1:46
1
excellent! saved my scripts!! :) it is so hard to read/search/browse info and manpages in the terminal that I just gave up long ago and go search on the internet...
â Aquarius Power
Sep 17 '13 at 19:24
2
Curiously,shopt -s expand_aliases
doesn't have to go before the alias definition but before the alias use. Adding to @FrankSchubert: Interactive shell detection may also be done using$-
which contains the options for the shell, specificallyi
if the shell is interactive.
â valid
Mar 20 '15 at 14:12
2
this isn't a correct answer... Sourcing your aliases inside your script isn't the answer. Your~/.bash_aliases
might depend on other stuff previously loaded on an interactive shell... The closest thing I found is changing your hashbang to#!/bin/bash -li
Still not perfect. Ideally you should use functions and not aliases.
â Stefanos Kalantzis
Feb 5 '16 at 11:47
1
1
I placed it in my script, but it's still not working. Same error.
â Zaid
Sep 2 '10 at 10:29
I placed it in my script, but it's still not working. Same error.
â Zaid
Sep 2 '10 at 10:29
4
4
Adding
shopt -s expand_aliases source ~/.bash_aliases
works perfectly for me. Often there is a form of interactive shell detection in .bashrc like this: # If not running interactively, don't do anything [ -z "$PS1" ] && return
@Zaid, Maybe you want to check for that in the file you sourced.â Frank Schubert
Apr 4 '13 at 1:46
Adding
shopt -s expand_aliases source ~/.bash_aliases
works perfectly for me. Often there is a form of interactive shell detection in .bashrc like this: # If not running interactively, don't do anything [ -z "$PS1" ] && return
@Zaid, Maybe you want to check for that in the file you sourced.â Frank Schubert
Apr 4 '13 at 1:46
1
1
excellent! saved my scripts!! :) it is so hard to read/search/browse info and manpages in the terminal that I just gave up long ago and go search on the internet...
â Aquarius Power
Sep 17 '13 at 19:24
excellent! saved my scripts!! :) it is so hard to read/search/browse info and manpages in the terminal that I just gave up long ago and go search on the internet...
â Aquarius Power
Sep 17 '13 at 19:24
2
2
Curiously,
shopt -s expand_aliases
doesn't have to go before the alias definition but before the alias use. Adding to @FrankSchubert: Interactive shell detection may also be done using $-
which contains the options for the shell, specifically i
if the shell is interactive.â valid
Mar 20 '15 at 14:12
Curiously,
shopt -s expand_aliases
doesn't have to go before the alias definition but before the alias use. Adding to @FrankSchubert: Interactive shell detection may also be done using $-
which contains the options for the shell, specifically i
if the shell is interactive.â valid
Mar 20 '15 at 14:12
2
2
this isn't a correct answer... Sourcing your aliases inside your script isn't the answer. Your
~/.bash_aliases
might depend on other stuff previously loaded on an interactive shell... The closest thing I found is changing your hashbang to #!/bin/bash -li
Still not perfect. Ideally you should use functions and not aliases.â Stefanos Kalantzis
Feb 5 '16 at 11:47
this isn't a correct answer... Sourcing your aliases inside your script isn't the answer. Your
~/.bash_aliases
might depend on other stuff previously loaded on an interactive shell... The closest thing I found is changing your hashbang to #!/bin/bash -li
Still not perfect. Ideally you should use functions and not aliases.â Stefanos Kalantzis
Feb 5 '16 at 11:47
 |Â
show 2 more comments
up vote
37
down vote
Aliases can't be exported so they're not available in shell scripts in which they aren't defined. In other words, if you define them in ~/.bashrc
they're not available to your_script.sh
(unless you source ~/.bashrc
in the script, which I wouldn't recommend but there are ways to do this properly).
However, functions can be exported and would be available to shell scripts that are run from an environment in which they are defined. This can be done by placing this in your bashrc:
foo()
echo "Hello World!"
export -f foo
As the Bash manual says, "For almost every purpose, shell functions are preferred over aliases."
1
While this doesn't technically answer the question, as you say you can simply replacealias commandA=...
withcommandA() ...
thenexport commandA
and you get identical behavior to the alias. So this is pretty much an identical alternative to aliases as far as I know that works great in bash scripts
â Phylliida
May 21 at 18:35
add a comment |Â
up vote
37
down vote
Aliases can't be exported so they're not available in shell scripts in which they aren't defined. In other words, if you define them in ~/.bashrc
they're not available to your_script.sh
(unless you source ~/.bashrc
in the script, which I wouldn't recommend but there are ways to do this properly).
However, functions can be exported and would be available to shell scripts that are run from an environment in which they are defined. This can be done by placing this in your bashrc:
foo()
echo "Hello World!"
export -f foo
As the Bash manual says, "For almost every purpose, shell functions are preferred over aliases."
1
While this doesn't technically answer the question, as you say you can simply replacealias commandA=...
withcommandA() ...
thenexport commandA
and you get identical behavior to the alias. So this is pretty much an identical alternative to aliases as far as I know that works great in bash scripts
â Phylliida
May 21 at 18:35
add a comment |Â
up vote
37
down vote
up vote
37
down vote
Aliases can't be exported so they're not available in shell scripts in which they aren't defined. In other words, if you define them in ~/.bashrc
they're not available to your_script.sh
(unless you source ~/.bashrc
in the script, which I wouldn't recommend but there are ways to do this properly).
However, functions can be exported and would be available to shell scripts that are run from an environment in which they are defined. This can be done by placing this in your bashrc:
foo()
echo "Hello World!"
export -f foo
As the Bash manual says, "For almost every purpose, shell functions are preferred over aliases."
Aliases can't be exported so they're not available in shell scripts in which they aren't defined. In other words, if you define them in ~/.bashrc
they're not available to your_script.sh
(unless you source ~/.bashrc
in the script, which I wouldn't recommend but there are ways to do this properly).
However, functions can be exported and would be available to shell scripts that are run from an environment in which they are defined. This can be done by placing this in your bashrc:
foo()
echo "Hello World!"
export -f foo
As the Bash manual says, "For almost every purpose, shell functions are preferred over aliases."
edited May 9 '13 at 14:03
answered Sep 2 '10 at 20:38
Dennis Williamson
5,17812132
5,17812132
1
While this doesn't technically answer the question, as you say you can simply replacealias commandA=...
withcommandA() ...
thenexport commandA
and you get identical behavior to the alias. So this is pretty much an identical alternative to aliases as far as I know that works great in bash scripts
â Phylliida
May 21 at 18:35
add a comment |Â
1
While this doesn't technically answer the question, as you say you can simply replacealias commandA=...
withcommandA() ...
thenexport commandA
and you get identical behavior to the alias. So this is pretty much an identical alternative to aliases as far as I know that works great in bash scripts
â Phylliida
May 21 at 18:35
1
1
While this doesn't technically answer the question, as you say you can simply replace
alias commandA=...
with commandA() ...
then export commandA
and you get identical behavior to the alias. So this is pretty much an identical alternative to aliases as far as I know that works great in bash scriptsâ Phylliida
May 21 at 18:35
While this doesn't technically answer the question, as you say you can simply replace
alias commandA=...
with commandA() ...
then export commandA
and you get identical behavior to the alias. So this is pretty much an identical alternative to aliases as far as I know that works great in bash scriptsâ Phylliida
May 21 at 18:35
add a comment |Â
up vote
8
down vote
[cmd line] > bash -i [your script's file path]
The i
is for interactive and sources your bash
profile for you.
add a comment |Â
up vote
8
down vote
[cmd line] > bash -i [your script's file path]
The i
is for interactive and sources your bash
profile for you.
add a comment |Â
up vote
8
down vote
up vote
8
down vote
[cmd line] > bash -i [your script's file path]
The i
is for interactive and sources your bash
profile for you.
[cmd line] > bash -i [your script's file path]
The i
is for interactive and sources your bash
profile for you.
edited Apr 18 '14 at 15:56
enedil
1,26131125
1,26131125
answered Apr 18 '14 at 14:23
user65576
8911
8911
add a comment |Â
add a comment |Â
up vote
-4
down vote
I found sometimes bash script doesn't recognize export either. However, changing it to
#!/bin/sh
works for me.
1
No, it didn't...
â Hafiz Temuri
Apr 22 at 17:12
add a comment |Â
up vote
-4
down vote
I found sometimes bash script doesn't recognize export either. However, changing it to
#!/bin/sh
works for me.
1
No, it didn't...
â Hafiz Temuri
Apr 22 at 17:12
add a comment |Â
up vote
-4
down vote
up vote
-4
down vote
I found sometimes bash script doesn't recognize export either. However, changing it to
#!/bin/sh
works for me.
I found sometimes bash script doesn't recognize export either. However, changing it to
#!/bin/sh
works for me.
edited May 8 '13 at 8:50
Anthon
58.6k1796159
58.6k1796159
answered May 8 '13 at 8:29
lwpro2
932
932
1
No, it didn't...
â Hafiz Temuri
Apr 22 at 17:12
add a comment |Â
1
No, it didn't...
â Hafiz Temuri
Apr 22 at 17:12
1
1
No, it didn't...
â Hafiz Temuri
Apr 22 at 17:12
No, it didn't...
â Hafiz Temuri
Apr 22 at 17:12
add a comment |Â
protected by slm⦠Apr 18 '14 at 15:08
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
9
BTW, there's no need to log in and out to have an alias recognized. You need just do
source ~/.bashrc
.â Tshepang
Nov 25 '10 at 19:10
For my case I was connected by SSH agent remotely, after adding alias as I closed the SSH agent and connected again it started working.
â dav
Sep 6 '15 at 5:05