type -m doesn't work

type -m doesn't work

[Vinnie Shelton]

In an unpatched beta19, "type -m" doesn't work:

: ~ Thu 30 8:56; type -m 'zsh*'
zsh is /pd/osbin/
zsh.old is /pd/osbin/
zsh-2.6-beta10 is /pd/osbin/
zsh-2.6-beta11 is /pd/osbin/
zsh-2.6-beta13 is /pd/osbin/
zsh-2.6-beta15 is /pd/osbin/
zsh-2.6-beta16 is /pd/osbin/
zsh-2.6-beta18 is /pd/osbin/
zsh-2.6-beta19 is /pd/osbin/

This is true under SunOS 4.1.3, Solaris 2.5 and UnixWare 1.4.
In each case, I built with --enable-zsh-mem, (in case it matters).

--vin



--JAA28902.833462548/steadfast.teradyne.com--

beta19, SunOS 4.1.3_U1 and nawk

[Vinnie Shelton]

Beta19 using nawk on SunOS 4.1.3_U1 generates an invalid signames.h
file.  All the #else's are turned into else's.

After patching up signames.h, everything built fine.

--vin

beta19, SunOS 4.1.3_U1 and nawk

[Peter A. Newson]

>Beta19 using nawk on SunOS 4.1.3_U1 generates an invalid signames.h
>file.  All the #else's are turned into else's.
>
It built with no probs for me on the same system.

Pete

beta19, SunOS 4.1.3_U1 and nawk

[Peter A. Newson]

Whoops, sorry Vin. 

I forgot I have gawk installed. After applying Zoltan's patch, signames.h is 
generated correctly using either gawk or nawk.

Pete

Re: beta19, SunOS 4.1.3_U1 and nawk

[Andreas Koenig]

  >>Beta19 using nawk on SunOS 4.1.3_U1 generates an invalid signames.h
  >>file.  All the #else's are turned into else's.
  >>
  >It built with no probs for me on the same system.

The NeXT 3.2 also has an awk that loses the hashmark in front of the
else. NeXT's awk is very old and slow and there's no nawk available in
the standard OS.

Sorry, can't dig any deeper,
andreas

Re: type -m doesn't work

[Bart Schaefer]

On May 30,  9:21am, Vinnie Shelton wrote:
} Subject: type -m doesn't work
}
} In an unpatched beta19, "type -m" doesn't work:
} 
} : ~ Thu 30 8:56; type -m 'zsh*'
} zsh is /pd/osbin/
} zsh.old is /pd/osbin/
} zsh-2.6-beta10 is /pd/osbin/
} zsh-2.6-beta11 is /pd/osbin/
} zsh-2.6-beta13 is /pd/osbin/
} zsh-2.6-beta15 is /pd/osbin/
} zsh-2.6-beta16 is /pd/osbin/
} zsh-2.6-beta18 is /pd/osbin/
} zsh-2.6-beta19 is /pd/osbin/

It's a metafication problem, I think; here's what I get on linux:

zagzig% type -m z\*
zdump is /usr/sbin/\M-P\M-_^E^Hx\M-L^E^HP\M-[^E^H
zmail is /usr/bin/\M-`\M-_^E^H\M-x\M-O^E^H
zipsplit is /usr/local/bin/@\M-[^E^H\M-^@\M-L^E^H\M-`\M-_^E^H\M-x\M-O^E^H
zcat is /bin/\M-^@\M-L^E^H\M-`\M-_^E^H\M-x\M-O^E^H
zmore is /usr/bin/\M-`\M-_^E^H\M-x\M-O^E^H
znew is /usr/bin/\M-`\M-_^E^H\M-x\M-O^E^H
zdiff is /usr/bin/\M-`\M-_^E^H\M-x\M-O^E^H
zipgrep is /usr/local/bin/@\M-[^E^H\M-^@\M-L^E^H\M-`\M-_^E^H\M-x\M-O^E^H
zipinfo is /usr/local/bin/@\M-[^E^H\M-^@\M-L^E^H\M-`\M-_^E^H\M-x\M-O^E^H
zgv is /usr/bin/\M-`\M-_^E^H\M-x\M-O^E^H
zipcloak is /usr/local/bin/@\M-[^E^H\M-^@\M-L^E^H\M-`\M-_^E^H\M-x\M-O^E^H
zic is /usr/sbin/\M-P\M-_^E^Hx\M-L^E^HP\M-[^E^H
zip is /usr/local/bin/@\M-[^E^H\M-^@\M-L^E^H\M-`\M-_^E^H\M-x\M-O^E^H
zforce is /usr/bin/\M-`\M-_^E^H\M-x\M-O^E^H
zgrep is /usr/bin/\M-`\M-_^E^H\M-x\M-O^E^H
zcmp is /usr/bin/\M-`\M-_^E^H\M-x\M-O^E^H
zipnote is /usr/local/bin/@\M-[^E^H\M-^@\M-L^E^H\M-`\M-_^E^H\M-x\M-O^E^H


-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: list-choices

[Bart Schaefer]

On Oct 3,  2:12pm, Vinnie Shelton wrote:
> Subject: list-choices
> If I use automenu to complete a directory, how do I list the choices under
> that directory?  I thought ^D would work, and then I tried ESC ^D, but
> still no joy.
[...]
> I want to accept the current selection and move to the next layer down -

Amazing as it may seem, you want slash (/), or any other character that
interrupts the menu cycle, and then ctrl-D.  delete-char-or-list no longer
interrupts menu cycles (I don't recall how long this has been true).

If you have autoremoveslash set, typing a slash will interrupt the cycle
without actually adding a slash to the command line (this didn't work in
earlier versions; you used to get two slashes), and you can then proceed
with listing or whatever.

The way *I'd* really like it to work is for delete-char-or-list to show
me what's below abc/, but then continue cycling through the original menu
completion.  That is,

% vi ab<TAB>
abc  abd
% vi ab<TAB>		<-- Tab again to trigger automenu
% vi abc/<C-D>		<-- Hmm, show me what's in that directory
aaa  bbb  ccc		<-- Wrong, I wanted the directory containing "eee"
% vi abc/<TAB>		<-- Keep cycling the menu that autolist showed me
% vi abd/<C-D>		<-- Now show me what's in THAT directory
ddd  eee  fff		<-- Ok, abd/ is is the right one!
% vi abd/e<TAB>		<-- So now I can complete what I really wanted
% vi abd/eee

This seems to me to be somewhat more useful than having C-D show the menu
that is already in progress, which is the behavior right now, and FAR more
useful than having to interrupt the menu cycle and start over after finding
out that your first guess was wrong.

Re: list-choices

[Vinnie Shelton]

schaefer@candle.brasslantern.com said:
> If you have autoremoveslash set, typing a slash will interrupt the 
> cycle without actually adding a slash to the command line (this 
> didn't work in earlier versions; you used to get two slashes), and 
> you can then proceed with listing or whatever.

That's pretty cool.  Silently absorbing the slash is probably a little 
mysterious to new users, but I LIKE IT!

> The way *I'd* really like it to work is for delete-char-or-list to 
> show me what's below abc/, but then continue cycling through the 
> original menu completion.

I, too, think this would be best.  I thought it once worked that way, but I 
tried out 2.6-beta10, and the behavior was the same as now.

Thanks.

Re: list-choices

[Zefram]

>> I want to accept the current selection and move to the next layer down -
>
>Amazing as it may seem, you want slash (/), or any other character that
>interrupts the menu cycle, and then ctrl-D.  delete-char-or-list no longer
>interrupts menu cycles (I don't recall how long this has been true).

2.6-beta12.  One of my favourite new features, actually.

>The way *I'd* really like it to work is for delete-char-or-list to show
>me what's below abc/, but then continue cycling through the original menu
>completion.  That is,
...
>This seems to me to be somewhat more useful than having C-D show the menu
>that is already in progress, which is the behavior right now, and FAR more
>useful than having to interrupt the menu cycle and start over after finding
>out that your first guess was wrong.

That sounds like a very nice thing to have.  (In fact, there's already
some code for execute-named-command that displays a temporary list
while a menu completion may already be in progress -- this could be
moved into a separate function in zle_tricky.c and made a bit more
complete in order to implement this feature.)  But I wouldn't want this
sort of listing to be on the usual list-choices etc. keys: it's useful
to be able to explicitly display the list one is menuing through.  It
would have to be a new command.

-zefram

list-choices

[Vinnie Shelton]

If I use automenu to complete a directory, how do I list the choices under
that directory?  I thought ^D would work, and then I tried ESC ^D, but
still no joy.

For example:

: ~/foo Thu 3 14:02; zsh -f
spacely% echo $ZSH_VERSION
3.0.1-test2
spacely% uname -a
SunOS spacely 5.5 Generic sun4m sparc SUNW,SPARCstation-5
spacely% ls -R
.:
abc         abd
 
./abc:
aaa  bbb  ccc
 
./abd:
spacely% setopt automenu autolist
spacely% ls ab<TAB>
abc  abd
                         <TAB> again yields:
spacely% ls abc/
                         Now if I press ^D or "ESC ^D", I get:
abc  abd

I want to accept the current selection and move to the next layer down -
I want the choices listed to be "aaa bbb ccc".  I thought delete-char-or-list
used to do what I want, but I can't reproduce the desired behavior.

TIA,
  Vin Shelton