Re: alias problem -- conflict found

[Robert Elz]

    Date:        Wed, 10 Jul 2019 05:01:28 -0700
    From:        L A Walsh <bash@tlinx.org>
    Message-ID:  <5D25D398.7010300@tlinx.org>

  | You are going to tell me that saying
  | int i=1 is too obscure to be deciphered by most, versus
  | declare -i i=1;

People can guess at the first, for the second, they can look it
up in the manual.   The former leads to a "I wonder if that was
right?" experience, the latter to "Now I know how that is done".
Which do you really feel is better?

  | Including those that have never seen a unix shell?

I have no idea why such a person would ever be looking at a unix
shell script.

  | Try write a function to emulate "int" in a posix compatible shell.

I have no idea what you're asking there - pure posix shells have
nothing equivalent, and no need for it.   All data is a string.

To write an int function for bash

        int() { local _A; for _A; do declare -gi "$_A"; done; }

what's hard about that?

  | I actually don't use Export.  Ever.

That's not important, that one was just an example.


  | I don't know, I don't have a function named export.

export is a standard builtin command.

  | At least in my testing I used Export and not 'export'...

Yes, they way you were (are) doing it you would want to.

  | So if you have a function that returns the names of options, howdo you
  | declare the name in the function and have it be in global scope without
  | using the bash-only flag for defining at global scope?

You're already using bash only code all over the place.   In other shells
(which have no declare) defining a variable in a function defines a global
variable (unless it is explicitly declared local).   I agree that it is
kind of weird that "declare" (or typeset) in bash (probably ksh93 too)
makes local variables by default when used inside a function, but if you're
writing code uses bashisms (or ksh addons copied by bash) then you can also
use its option to undo that (as I did above).

  | You can so it with an alias+function, but not functions only.

I have absolutely no idea how using an alias makes any difference to
what a function can do, unless you mean something like
        alias declare='declare -g'
but you might just as well write "declare -g" as do that.

  | Functions can't process their arguments in the current scope.

I have no idea what you're getting at there.

  | Like you said above, if 'my' was a function then
  | it tried to use a function named Export to export variables that came
  | after it, it wouldn't be at global scope.

That isn't what I was suggesting that you do, rather more like (nb:
this one is untested, and is just a hint)

        my()
        {
                local args=-g

                while [ $# -gt 0 ]
                do
                        case "$1" in
                        export)         args="$args -x"; shift;;
                        int)            args="$args -i"; shift;;
                        whatever-else)  args="$args -?"; shift;;
                        *)              break;;
                done
                test $# -gt 0 || {
                        printf >&2 '%s\n' 'Usage: my type... var[=val]'
                        return 1;
                }
                declare $args "$@"
        }

If you also want an "int" function, that's above.  Nothing is needed
for export, that's a builtin already.

  | I use functions where appropriate, but there are things not
  | appropriate for functions.

Almost nothing.    There are rules for what a function name can
be, and what it can override, which can sometimes be a nuisance.
The ones for func name syntax have no reason to exist at all, but
they do (to a degree) - where that's a problem, sometimes an alias
can help.

  | aliases are simple substitutions.  For the most part, they
  | are done as the file is read in.

Ther are done as the relevant code is parsed.   The alias definition
has to have been processed (executed) before that.   There are a few
odd cases where that causes problems.

  | They take no memory

Nonsense, the aliases need to be remembered in the shell just like
anything else.   They might end up using less mem than a function
definition, but it isn't zero - and if you have code where the function
definitions use enough memory that you can actually detect it (that it
makes any difference you can notice) and you tried to replace that with
aliases, you'd have a disaster.   That just is not something to concern
yourself with.

  | Functions are executed at run time.
  |  You can change their definition at run time.  With aliases
  | you can't do that.

Of course you can.   Everything in sh is executable.   Everything
can be undone and done again, differently.

  | Aliases are used internally by bash to store path lookups, by
  | default.

Really?   I haven't looked at any bash code in a very long time
(for licensing reasons, I don't want to be corrupted by the GPL)
but that sounds like a very weird way of implementing things if true.

  | They are simply more efficient.  If functions were better, bash would
  | implement path lookups by defining a function for each

No it wouldn't, it would (probably actually does, since I can find
nothing that indicates otherwise) keep a hash table with the results
of path lookups.   Nothing related to aliases in any way at all.

kre