Why doesn't my Bash script recognize aliases?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
170
down vote

favorite
47












In my ~/.bashrc file reside two definitions:




  1. commandA, which is an alias to a longer path


  2. commandB, 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?







share|improve this question


















  • 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















up vote
170
down vote

favorite
47












In my ~/.bashrc file reside two definitions:




  1. commandA, which is an alias to a longer path


  2. commandB, 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?







share|improve this question


















  • 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













up vote
170
down vote

favorite
47









up vote
170
down vote

favorite
47






47





In my ~/.bashrc file reside two definitions:




  1. commandA, which is an alias to a longer path


  2. commandB, 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?







share|improve this question














In my ~/.bashrc file reside two definitions:




  1. commandA, which is an alias to a longer path


  2. commandB, 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?









share|improve this question













share|improve this question




share|improve this question








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 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













  • 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








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











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





share|improve this answer


















  • 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










  • @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 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


















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





share|improve this answer


















  • 1




    I placed it in my script, but it's still not working. Same error.
    – Zaid
    Sep 2 '10 at 10:29






  • 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







  • 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, specifically i 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


















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."






share|improve this answer


















  • 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


















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.






share|improve this answer





























    up vote
    -4
    down vote













    I found sometimes bash script doesn't recognize export either. However, changing it to



    #!/bin/sh


    works for me.






    share|improve this answer


















    • 1




      No, it didn't...
      – Hafiz Temuri
      Apr 22 at 17:12









    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





    share|improve this answer


















    • 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










    • @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 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















    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





    share|improve this answer


















    • 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










    • @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 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













    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





    share|improve this answer














    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






    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Apr 24 '16 at 15:52

























    answered Sep 2 '10 at 12:37







    user601














    • 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










    • @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 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













    • 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










    • @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 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








    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













    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





    share|improve this answer


















    • 1




      I placed it in my script, but it's still not working. Same error.
      – Zaid
      Sep 2 '10 at 10:29






    • 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







    • 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, specifically i 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















    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





    share|improve this answer


















    • 1




      I placed it in my script, but it's still not working. Same error.
      – Zaid
      Sep 2 '10 at 10:29






    • 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







    • 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, specifically i 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













    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





    share|improve this answer














    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






    share|improve this answer














    share|improve this answer



    share|improve this answer








    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




      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




      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, specifically i 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




      I placed it in my script, but it's still not working. Same error.
      – Zaid
      Sep 2 '10 at 10:29






    • 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







    • 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, specifically i 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











    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."






    share|improve this answer


















    • 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















    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."






    share|improve this answer


















    • 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













    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."






    share|improve this answer














    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."







    share|improve this answer














    share|improve this answer



    share|improve this answer








    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 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













    • 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








    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











    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.






    share|improve this answer


























      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.






      share|improve this answer
























        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.






        share|improve this answer














        [cmd line] > bash -i [your script's file path]


        The i is for interactive and sources your bash profile for you.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Apr 18 '14 at 15:56









        enedil

        1,26131125




        1,26131125










        answered Apr 18 '14 at 14:23









        user65576

        8911




        8911




















            up vote
            -4
            down vote













            I found sometimes bash script doesn't recognize export either. However, changing it to



            #!/bin/sh


            works for me.






            share|improve this answer


















            • 1




              No, it didn't...
              – Hafiz Temuri
              Apr 22 at 17:12














            up vote
            -4
            down vote













            I found sometimes bash script doesn't recognize export either. However, changing it to



            #!/bin/sh


            works for me.






            share|improve this answer


















            • 1




              No, it didn't...
              – Hafiz Temuri
              Apr 22 at 17:12












            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.






            share|improve this answer














            I found sometimes bash script doesn't recognize export either. However, changing it to



            #!/bin/sh


            works for me.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            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












            • 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





            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?


            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Bahrain

            Postfix configuration issue with fips on centos 7; mailgun relay