zsh-users
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@brasslantern.com>
To: zsh-users@math.gatech.edu
Subject: Re: completion ignoring
Date: Fri, 29 May 1998 11:55:41 -0700	[thread overview]
Message-ID: <980529115541.ZM1633@candle.brasslantern.com> (raw)
In-Reply-To: <19980529161402.A12061@ens-lyon.fr>
In-Reply-To: <vbra1d6qdn.fsf@snake.isode.com>

On May 29,  4:14pm, Vincent Lefevre wrote:
} Subject: Re: completion ignoring
}
} On Wed, May 27, 1998 at 17:21:18 +0100, Bruce Stephens wrote:
} > That's what I understood the question to be.  And yes, isn't this how
} > zsh works right now?
} 
} No:
} 
} $ benchmul[TAB]
} benchmul-sparc4  benchmul-ultra1  benchmul.o
} 
} (These 3 files are in a directory that is in my PATH.)
} 
} -rw-r--r--   1 vlefevre lip          1388 May 29 16:12 sparc/benchmul.o

On May 29,  4:36pm, Bruce Stephens wrote:
} Subject: Re: completion ignoring
}
} OK, I think that's a bug in 3.0.5 then.

It's a deficiency (?) in building the command hash table, specifically.
If you enter a full (or even relative) path to a prefix of the name of
any non-executable file and then attempt to do command completion on it,
it fails.  But if you look at the output of "hash" you'll see that every
file in every directory in $PATH has been put in the table -- and command
completion reads the hash table by default, without further testing the
file permissions on the target of the hashed name.

gen_matches_files(), which is called for things not in the PATH, does do
a stat() and look for the S_IEXEC bit.

I don't think hashtable.c has changed much in 3.1.x, so this problem is
likely still present.  However, stat()-ing every file in every directory
in $PATH is probably prohibitively slow, so this could reasonably only be
handled as a special case during completion.

Unfortunately, the code that determines whether a word matches the prefix
is completely generic -- it doesn't know that the word came from the
command hash table, or even that it's a command being completed -- and it
works by adding the word to the completion list if it matches the prefix
or by ignoring it if it doesn't match the prefix.  There's no hook for
discovering that the word *might* match and then doing an extra test on
it using any other information (such as the target of the hash).  So this
behavior is unlikely to be changed anytime soon.

Of course, you could do something like

    function xhash () {
      emulate -R zsh
      setopt localoptions
      local maybe cmd i=0
      reply=()
      hash -f
      maybe=( $(hash -m ${1}\*${2}) )
      for cmd in ${maybe##*\=}
      do
        ((++i))
	[[ -x $cmd ]] && reply=( $reply ${${maybe[$i]}%\=*} )
      done
    }

    compctl -C -aBF -K xhash -g '*(*)'

This says, attempt to complete any aliases, builtins or functions, any
executables in the hash table, and any executable files.  The `xhash'
function fills the hash table, lists everything in it that matches the
prefix and suffix of the completion, then tests the path to which each
hashes to see if it is executable before adding it to the result.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com


  parent reply	other threads:[~1998-05-29 19:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-05-22 15:01 Timothy J Luoma
1998-05-22 15:22 ` Matthew Lovell
1998-05-22 15:23 ` Andrew Main
1998-05-22 15:34   ` Timothy J Luoma
1998-05-22 16:00     ` Bruce Stephens
1998-05-22 16:52       ` Bart Schaefer
1998-05-27 12:20         ` Vincent Lefevre
1998-05-27 13:18           ` Bruce Stephens
1998-05-27 15:41             ` Sven Guckes
1998-05-27 16:21               ` Bruce Stephens
1998-05-29 14:14                 ` Vincent Lefevre
1998-05-29 15:36                   ` Bruce Stephens
1998-05-29 16:59                     ` Vincent Lefevre
1998-05-29 18:55                     ` Bart Schaefer [this message]
1998-05-27 16:31               ` Bart Schaefer
1998-05-27 22:34           ` Shawn Leas
1998-05-22 15:32 ` Bruce Stephens
     [not found] <"hsoX92.0.773.iEPPr"@tequila.systemsz.cs.yale.edu>
1998-05-22 20:07 ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=980529115541.ZM1633@candle.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=zsh-users@math.gatech.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).