zsh-workers
 help / color / mirror / code / Atom feed
* Re: mapfile module - avoiding $(...) in completion functions
@ 2000-01-06  9:45 Sven Wischnowsky
  0 siblings, 0 replies; 3+ messages in thread
From: Sven Wischnowsky @ 2000-01-06  9:45 UTC (permalink / raw)
  To: zsh-workers


Andrej Borsenkow wrote:

> > Since in the completion system we generally want to avoid the extra
> > processes needed for $(...), we would use caching for the printer
> > names there (and the function for the lp commands I just sent to
> > zsh-workers does that). And we would also make this nicer by
> > supporting the other mechanisms used throughout the completion system.
> >
> 
> 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.
>
> ...
> 
> Is there any system now-a-days without mmap support?

I'd like to know that, too. It's the reason why I haven't used mapfile 
in completion functions yet.

> And where the "real" $(...) is needed, we cannot cache it anyway (process list
> is an example).

And fonts, X-extensions, tar and YP-stuff are counterexamples.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: mapfile module - avoiding $(...) in completion functions
  2000-01-06  7:32 ` Andrej Borsenkow
@ 2000-01-06 20:19   ` Peter Stephenson
  0 siblings, 0 replies; 3+ messages in thread
From: Peter Stephenson @ 2000-01-06 20:19 UTC (permalink / raw)
  To: ZSH workers mailing list

"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>


^ permalink raw reply	[flat|nested] 3+ messages in thread

* mapfile module - avoiding $(...) in completion functions
       [not found] <200001051437.PAA10986@beta.informatik.hu-berlin.de>
@ 2000-01-06  7:32 ` Andrej Borsenkow
  2000-01-06 20:19   ` Peter Stephenson
  0 siblings, 1 reply; 3+ messages in thread
From: Andrej Borsenkow @ 2000-01-06  7:32 UTC (permalink / raw)
  To: ZSH workers mailing list

>
> Since in the completion system we generally want to avoid the extra
> processes needed for $(...), we would use caching for the printer
> names there (and the function for the lp commands I just sent to
> zsh-workers does that). And we would also make this nicer by
> supporting the other mechanisms used throughout the completion system.
>

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.

And where the "real" $(...) is needed, we cannot cache it anyway (process list
is an example).

Is there any system now-a-days without mmap support?

/andrej


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2000-01-06 20:17 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-01-06  9:45 mapfile module - avoiding $(...) in completion functions Sven Wischnowsky
     [not found] <200001051437.PAA10986@beta.informatik.hu-berlin.de>
2000-01-06  7:32 ` Andrej Borsenkow
2000-01-06 20:19   ` Peter Stephenson

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).