[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: how are aliases exported?

From: Linda Walsh
Subject: Re: how are aliases exported?
Date: Sun, 15 Apr 2012 13:38:15 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100228 Lightning/0.9 Thunderbird/ Mnenhy/

Pierre Gaston wrote:

On Sat, Apr 14, 2012 at 8:31 AM, Pierre Gaston <address@hidden <mailto:address@hidden>> wrote:

    On Sat, Apr 14, 2012 at 3:44 AM, Linda Walsh <address@hidden
    <mailto:address@hidden>> 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 "address@hidden"; do
      if [[ -r $pw/$fnc ]]; then
        printf "%s" "source \"$pw/$fnc\""   && _INC[$fnc]="$pw/$fnc" && return 0
    echo "ERROR: Missing \"$fnc\" in \$PATH" >&2
    exit 2

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]