From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-9255-mason-zsh=primenet.com.au@sunsite.auc.dk>
Received: (qmail 17958 invoked from network); 6 Jan 2000 20:17:55 -0000
Received: from sunsite.auc.dk (130.225.51.30)
  by ns1.primenet.com.au with SMTP; 6 Jan 2000 20:17:55 -0000
Received: (qmail 29495 invoked by alias); 6 Jan 2000 20:17:44 -0000
Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm
Precedence: bulk
X-No-Archive: yes
X-Seq: 9255
Received: (qmail 29488 invoked from network); 6 Jan 2000 20:17:43 -0000
To: "ZSH workers mailing list" <zsh-workers@sunsite.auc.dk>
Subject: Re: mapfile module - avoiding $(...) in completion functions 
In-reply-to: ""Andrej Borsenkow""'s message of "Thu, 06 Jan 2000 10:32:54 +0300."
             <000401bf5818$3e881bb0$21c9ca95@mow.siemens.ru> 
Date: Thu, 06 Jan 2000 20:19:39 +0000
From: Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Message-Id: <E126JLp-0007J0-00.2000-01-06-20-17-41@cmailg7.svr.pol.co.uk>

"Andrej Borsenkow" wrote:
> May be it was discussed already, but is not mapfile module alternative to
> $(...)? We mostly need it to parse files content, as in
> $(</etc/printcap), and in this case we could just as well mmap the file.

There's no real efficiency issue here --- $(<...) is handled without
forking, just by reading the file in, so while mapping may in principal be
quicker the gain is certainly negligible.

mapfile is supposed to do this, too, if it doesn't find enough memory
management tools, so it should be safe to use anyway.  However, it's not a
particularly good idea to keep requiring extra modules for completion to
work:  completion is a basic feature, and the modules are supposed to be
optional to avoid the overhead.  This is even worse, for obvious reasons,
if the shell is statically linked.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>