Rationalized? aliases

Rationalized? aliases

[Vinnie Shelton]

With beta10 and previous releases, the following worked:

% echo $ZSH_VERSION 
2.6-beta10
% alias e="gnuclient -q"
% [[ $HOST != $HOMESYSTEM ]] && alias e="$(whence e) -h $HOMESYSTEM"
% type e
e is an alias for gnuclient -q -h spacely


Now however, the rationalized alias output makes this not work:

% echo $ZSH_VERSION
2.6-beta11
alias e="gnuclient -q"
% [[ $HOST != $HOMESYSTEM ]] && alias e="$(whence e) -h $HOMESYSTEM"
% type e
e is an alias for \''gnuclient -q'\'' -h spacely'

This is not what I desire ('gnuclient -q' is not a valid command) - what
 I want is to append "-h spacely" to the alias.  How can I do this?

Thanks in advance,
  Vin

Re: Rationalized? aliases

[Richard Coleman]

> Now however, the rationalized alias output makes this not work:
> 
> % echo $ZSH_VERSION
> 2.6-beta11
> alias e="gnuclient -q"
> % [[ $HOST != $HOMESYSTEM ]] && alias e="$(whence e) -h $HOMESYSTEM"
> % type e
> e is an alias for \''gnuclient -q'\'' -h spacely'
> 
> This is not what I desire ('gnuclient -q' is not a valid command) - what
>  I want is to append "-h spacely" to the alias.  How can I do this?

Hmm... A quick fix for your problem is to change
printaliasnode() in hashtable.c so that when the flags
PRINT_WHENCE_* are present, that it will use printf (or puts)
instead of printquoted().  This is exactly how it was done in
beta10.  But is this what we want to do?  It looks natural for
the output of `type' and `which' to be quoted.  For `whence' it
is not quite so clear which is best.

Rather than changing the code of zsh for this, maybe you should
just use

alias e="$(whence e | tr -d \') -h"

Doing things like this is what makes command substitution so
cool.

rc

Re: Rationalized? aliases

[Barton E. Schaefer]

On Nov 8,  6:17pm, Richard Coleman wrote:
} Subject: Re: Rationalized? aliases
}
} > Now however, the rationalized alias output makes this not work:
} > 
} > % echo $ZSH_VERSION
} > 2.6-beta11
} > alias e="gnuclient -q"
} > % [[ $HOST != $HOMESYSTEM ]] && alias e="$(whence e) -h $HOMESYSTEM"
} > % type e
} > e is an alias for \''gnuclient -q'\'' -h spacely'
} > 
} > This is not what I desire ('gnuclient -q' is not a valid command) - what
} >  I want is to append "-h spacely" to the alias.  How can I do this?
} 
} Rather than changing the code of zsh for this, maybe you should
} just use
} 
} alias e="$(whence e | tr -d \') -h"
} 
} Doing things like this is what makes command substitution so
} cool.

What's wrong with:

e="gnuclient -q"
[[ $HOST != $HOMESYSTEM ]] && alias e="$=e -h $HOMESYSTEM" || alias e="$=e"

??  Why get "whence" involved at all?

-- 
Bart Schaefer                     Vice President, Technology, Z-Code Software
schaefer@z-code.com                  Division of NCD Software Corporation
http://www.well.com/www/barts

Re: Rationalized? aliases

[Vinnie Shelton]

In message <199511082317.SAA29367@redwood.skiles.gatech.edu>, Richard Coleman w
rote:
>
>Rather than changing the code of zsh for this, maybe you should
>just use
>
>alias e="$(whence e | tr -d \') -h"
>
>Doing things like this is what makes command substitution so
>cool.

Yes, but then I have to know to do the tr substition.
I want a general solution that works for commands and aliases
and is a little bit cleaner than piping the output through 'tr'
(IMHO).

--vin

Re: Rationalized? aliases

[Mark Borges]

>> On Wed, 8 Nov 1995 15:36:43 -0800,
>> Barton E Schaefer(B) wrote:
B> } > % echo $ZSH_VERSION
B> } > 2.6-beta11
B> } > alias e="gnuclient -q"
B> } > % [[ $HOST != $HOMESYSTEM ]] && alias e="$(whence e) -h $HOMESYSTEM"
B> } > % type e
B> } > e is an alias for \''gnuclient -q'\'' -h spacely'
B> } > 

B> What's wrong with:

B> e="gnuclient -q"
B> [[ $HOST != $HOMESYSTEM ]] && alias e="$=e -h $HOMESYSTEM" || alias e="$=e"

B> ??  Why get "whence" involved at all?

An interesting idea, but it doesn't seem to do the same thing on my
system:

	$ e="gnuclient -q"
	$ echo $=e
	gnuclient -q
	$ alias e="$=e -h $HOMESYSTEM"
	$ type e
	e is an alias for gnuclient
	$ alias e="gnuclient -h $HOMESYSTEM"
	$ type e
	e is an alias for 'gnuclient -h foo'
	$

does it (HOMESYSTEM=foo here) ?

Unless this is an hzoli-ism...

  -mb-

Re: Rationalized? aliases

[Barton E. Schaefer]

On Nov 8,  5:52pm, Mark Borges wrote:
} Subject: Re: Rationalized? aliases
}
} B> e="gnuclient -q"
} B> [[ $HOST != $HOMESYSTEM ]] && alias e="$=e -h $HOMESYSTEM" || alias e="$=e"
} 
} An interesting idea, but it doesn't seem to do the same thing on my
} system:
} 
} 	$ e="gnuclient -q"
} 	$ echo $=e
} 	gnuclient -q
} 	$ alias e="$=e -h $HOMESYSTEM"
} 	$ type e
} 	e is an alias for gnuclient

Looks like a bug.  Try it with just $e rather than $=e ... using $=e was
a typo anyway; with the double quotes around it, it *should* have become
completely equivalent to just $e.  Instead, zsh seems to have broken the
entire quoted string into two words at the space in the value of $e.


-- 
Bart Schaefer                     Vice President, Technology, Z-Code Software
schaefer@z-code.com                  Division of NCD Software Corporation
http://www.well.com/www/barts

Re: Rationalized? aliases

[Zefram]

>Hmm... A quick fix for your problem is to change
>printaliasnode() in hashtable.c so that when the flags
>PRINT_WHENCE_* are present, that it will use printf (or puts)
>instead of printquoted().  This is exactly how it was done in
>beta10.  But is this what we want to do?  It looks natural for
>the output of `type' and `which' to be quoted.  For `whence' it
>is not quite so clear which is best.

"whence" is supposed to be used by humans.  Its output should be
quoted.  Putting it in a command substitution is, and always was, a
kludge.  That's what equals substitution is for:

% alias foo=bar
% echo =foo
bar

but there is an inconsistency, in a way, between equals substitution of
normal commands and of aliases:

% whence 'a*b'
/dcs/94/zefram/bin/a*b
% echo ='a*b'
/dcs/94/zefram/bin/a*b
% ='a*b'
This is a script with a silly name.
% alias foobar='echo *'
% echo =foobar
echo *
% =foobar
zsh: command not found: echo *

Actually the inconsistency is not in the equals substitution itself,
but in the fact that the text it expands to will, in actual use, be
rescanned.  This limits the use of equals substitution a little.

I think for builtins and shell functions equals substitution should
expand to the command name, rather than its present behaviour of
failing.  Then equals substitution will be usable in functions in an
interesting way:

function foo {
  local savecmd==$1 evalhack=
  alias $1 >&- && evalhack=eval
  # some commands that mess up PATH or whatever
  $=evalhack $savecmd some args
  # more commands
}

Maybe there should be another syntax similar to equals substitution --
say, ==command -- that puts an extra layer of quoting on the
substituted filename unless the command is an alias.  That would make
the above function:

function foo {
  local savecmd===$1 evalhack=
  # some commands that mess up PATH or whatever
  alias savedcmd=$savecmd
  savedcmd some args
  # more commands
}

Anyone got any better ideas?

-zefram

Re: Rationalized? aliases

[Zoltan Hidvegi]

Mark Borges wrote:
> An interesting idea, but it doesn't seem to do the same thing on my
> system:
> 
> 	$ e="gnuclient -q"
> 	$ echo $=e
> 	gnuclient -q
> 	$ alias e="$=e -h $HOMESYSTEM"
> 	$ type e
> 	e is an alias for gnuclient
> 	$ alias e="gnuclient -h $HOMESYSTEM"
> 	$ type e
> 	e is an alias for 'gnuclient -h foo'
> 	$
> 
> does it (HOMESYSTEM=foo here) ?
> 
> Unless this is an hzoli-ism...

It is.  I think if one writes $=e she wants to split something.  So it is not
a bug but a feature.

Even `rc' expansion can be used:

 % foo='a b c'
 % echo "${^=foo}bar"
abar bbar cbar

But splitting is disabled when the result should be one word:

 % bar="${^=foo}bar"
 % echo $bar
a b cbar

Bye,

  Zoltan