Skip to main content
deleted 1402 characters in body
Source Link
Warren Young
  • 73.4k
  • 17
  • 182
  • 172

It's simply a matter of surrounding it all with appropriate error checks:

fn_dir=~/.bash_functions
if [ -d "$fn_dir" ]; then
    for file in "$fn_dir"/*; do
        [ -r "$file" ] && . "$file"
    done
fi

I'm purposely not quoting values here because I'm making an assumption that you're not going to have a home directory or script name with spaces in it. That seems to go beyond robustness and into protection against malice. Since these are scripts you are writing for yourself, I don't think we need to go that far. :)


Multiple Errors correction attempt:

  1. It is an opinion-based bad habit, not an error, to name variables with caps.

  2. Always quote file names, and paths, actually unless you do need word-splitting/globbing, just do it.

  3. test -x is irrelevant, sourced files do not need to have an execution bit. So unless you don't need dynamic control over what files are sourced and which are not, suffice to check if we can read it.

  4. source built-in is OK, changed for POSIX dot . just out of my scripting deformation. :)

  5. Avoid using .sh file name suffix, this is not needed and could bring questions about your naming convention. Like .sh for POSIX scripts and .bash for bash scripts? No, the shebang is all that's needed, and in this case not even that.


Editor's Note: It is imperative that we script by example to others not to take bad habits. Double-quoting in this answer is necessary for the snippet to work under most conditions. Do not allow yourself to just assume anything, double-check, triple-check.

It's simply a matter of surrounding it all with appropriate error checks:

fn_dir=~/.bash_functions
if [ -d "$fn_dir" ]; then
    for file in "$fn_dir"/*; do
        [ -r "$file" ] && . "$file"
    done
fi

I'm purposely not quoting values here because I'm making an assumption that you're not going to have a home directory or script name with spaces in it. That seems to go beyond robustness and into protection against malice. Since these are scripts you are writing for yourself, I don't think we need to go that far. :)


Multiple Errors correction attempt:

  1. It is an opinion-based bad habit, not an error, to name variables with caps.

  2. Always quote file names, and paths, actually unless you do need word-splitting/globbing, just do it.

  3. test -x is irrelevant, sourced files do not need to have an execution bit. So unless you don't need dynamic control over what files are sourced and which are not, suffice to check if we can read it.

  4. source built-in is OK, changed for POSIX dot . just out of my scripting deformation. :)

  5. Avoid using .sh file name suffix, this is not needed and could bring questions about your naming convention. Like .sh for POSIX scripts and .bash for bash scripts? No, the shebang is all that's needed, and in this case not even that.


Editor's Note: It is imperative that we script by example to others not to take bad habits. Double-quoting in this answer is necessary for the snippet to work under most conditions. Do not allow yourself to just assume anything, double-check, triple-check.

It's simply a matter of surrounding it all with appropriate error checks:

fn_dir=~/.bash_functions
if [ -d "$fn_dir" ]; then
    for file in "$fn_dir"/*; do
        [ -r "$file" ] && . "$file"
    done
fi
Editor's Note: It is imperative that we script by example to others not to take bad habits. Double-quoting in this answer is necessary for the snippet to work under most conditions. Do not allow yourself to just assume anything, double-check, triple-check.
Source Link
Vlastimil Burián
  • 31.1k
  • 66
  • 209
  • 358

It's simply a matter of surrounding it all with appropriate error checks:

FNDIR=~/.bash_functions
if [ -d $FNDIR ]
then
    for f in $FNDIR/*.sh
    do
       test -x $f && source $f
    done
fi
fn_dir=~/.bash_functions
if [ -d "$fn_dir" ]; then
    for file in "$fn_dir"/*; do
        [ -r "$file" ] && . "$file"
    done
fi

I'm purposely not quoting values here because I'm making an assumption that you're not going to have a home directory or script name with spaces in it. That seems to go beyond robustness and into protection against malice. Since these are scripts you are writing for yourself, I don't think we need to go that far. :)


Multiple Errors correction attempt:

  1. It is an opinion-based bad habit, not an error, to name variables with caps.

  2. Always quote file names, and paths, actually unless you do need word-splitting/globbing, just do it.

  3. test -x is irrelevant, sourced files do not need to have an execution bit. So unless you don't need dynamic control over what files are sourced and which are not, suffice to check if we can read it.

  4. source built-in is OK, changed for POSIX dot . just out of my scripting deformation. :)

  5. Avoid using .sh file name suffix, this is not needed and could bring questions about your naming convention. Like .sh for POSIX scripts and .bash for bash scripts? No, the shebang is all that's needed, and in this case not even that.


Editor's Note: It is imperative that we script by example to others not to take bad habits. Double-quoting in this answer is necessary for the snippet to work under most conditions. Do not allow yourself to just assume anything, double-check, triple-check.

It's simply a matter of surrounding it all with appropriate error checks:

FNDIR=~/.bash_functions
if [ -d $FNDIR ]
then
    for f in $FNDIR/*.sh
    do
       test -x $f && source $f
    done
fi

I'm purposely not quoting values here because I'm making an assumption that you're not going to have a home directory or script name with spaces in it. That seems to go beyond robustness and into protection against malice. Since these are scripts you are writing for yourself, I don't think we need to go that far. :)

It's simply a matter of surrounding it all with appropriate error checks:

fn_dir=~/.bash_functions
if [ -d "$fn_dir" ]; then
    for file in "$fn_dir"/*; do
        [ -r "$file" ] && . "$file"
    done
fi

I'm purposely not quoting values here because I'm making an assumption that you're not going to have a home directory or script name with spaces in it. That seems to go beyond robustness and into protection against malice. Since these are scripts you are writing for yourself, I don't think we need to go that far. :)


Multiple Errors correction attempt:

  1. It is an opinion-based bad habit, not an error, to name variables with caps.

  2. Always quote file names, and paths, actually unless you do need word-splitting/globbing, just do it.

  3. test -x is irrelevant, sourced files do not need to have an execution bit. So unless you don't need dynamic control over what files are sourced and which are not, suffice to check if we can read it.

  4. source built-in is OK, changed for POSIX dot . just out of my scripting deformation. :)

  5. Avoid using .sh file name suffix, this is not needed and could bring questions about your naming convention. Like .sh for POSIX scripts and .bash for bash scripts? No, the shebang is all that's needed, and in this case not even that.


Editor's Note: It is imperative that we script by example to others not to take bad habits. Double-quoting in this answer is necessary for the snippet to work under most conditions. Do not allow yourself to just assume anything, double-check, triple-check.

Source Link
Warren Young
  • 73.4k
  • 17
  • 182
  • 172

It's simply a matter of surrounding it all with appropriate error checks:

FNDIR=~/.bash_functions
if [ -d $FNDIR ]
then
    for f in $FNDIR/*.sh
    do
       test -x $f && source $f
    done
fi

I'm purposely not quoting values here because I'm making an assumption that you're not going to have a home directory or script name with spaces in it. That seems to go beyond robustness and into protection against malice. Since these are scripts you are writing for yourself, I don't think we need to go that far. :)