Re: how are aliases exported?

[Linda Walsh]

Pierre Gaston wrote:

> On Sat, Apr 14, 2012 at 8:31 AM, Pierre Gaston <pierre.gaston@gmail.com 
> <mailto:pierre.gaston@gmail.com>> wrote:
>
>
>
>     On Sat, Apr 14, 2012 at 3:44 AM, Linda Walsh <bash@tlinx.org
>     <mailto:bash@tlinx.org>> wrote:
>
>
>
>         Dennis Williamson wrote:
>
>             Aliases are intended for command line convenience. You
>             should use
>             functions, which can be exported and are the correct thing
>             to use in
>             scripts (and even from the command line).
>
>             "For almost every purpose, shell functions are preferred
>             over aliases."
>
>             But, of course, you know that already.
>
>
>         ---
>         � � � �Yeah... and I've already demonstrated the 'almost' part.
>
>         It's one of those:
>
>         function _include_h { return "source <liblookup>$1" ;}
>
>
>         alias include='eval $( _include_h "$1")'
>
>         Near as I can tell, you can't do that in a function.
>         If you source a file in a function, the local vars in the file
>         would be local to the function -- not to the prog using the alias
>
>
>     local vars in the file? what is this? 
>
>
> Oh I get it, the non working code put me off (returning a string really?)
>
> You mean if you have "declare var=foo" in a file and then source it from 
> a function the variable will be local to the function, newer bash 
> versions have a -g option to work around this.

---
        Yeah, but I was hoping for a more portable solution.


Problem the various versions of bash are neither forward nor backward
compatible in various areas that hit my scripts.  Who's to say -g won't go
away in the next version?

Is it posix?  At least aliases and functions are in posix ..

What do you mean non working code?... the fact that I didn't expand the
internals of the function?  Sorry, I didn't think it would be
interesting to folks..


But if you want 'working' [sic] (doesn't because alias isn't easily 
exportable...).. but putting the alias definition in an exported var that
is evale'd in bash_env, would do the trick -- I use that to make arrays
inheritable as well...


---

!/bin/bash  -x


shopt -s expand_aliases
alias dcl=declare

dcl -x _SPATH
dcl -xa _FPATH
dcl -xA _INC

function _include_h {
# [[ ${0##*/} == include ]] && { exec "$@" ; }
  [[ -z $1 ]] && return 1
  dcl fnc=$1
  [[ $PATH != $_SPATH ]] && {
    unset _FPATH; dcl -xa _FPATH=( $( IFS=:;  echo $PATH ) )
    unset _SPATH; dcl -x _SPATH="$PATH"
  }

  if [[ ! ${_INC[$fnc]:-""}  ]]; then
    for pw in "${_FPATH[@]}"; do
      if [[ -r $pw/$fnc ]]; then
        printf "%s" "source \"$pw/$fnc\""   && _INC[$fnc]="$pw/$fnc" && return 0
      fi
    done
    echo "ERROR: Missing \"$fnc\" in \$PATH" >&2
    exit 2
  fi
}

export -f _include_h
alias include='eval $( _include_h "$1")'
export include

# test if initial include -- if so, restart with aliases defined...
[[ ${0##*/} == include ]] && { exec "$@" ; }
# else include the arg
include "$@"

# vim: ts=2 sw=2