From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: PATCH: parser (was: Re: PATCH: Improved _mailboxes)
Date: Fri, 25 Feb 2000 09:41:24 +0100 (MET) [thread overview]
Message-ID: <200002250841.JAA25219@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: "Bart Schaefer"'s message of Thu, 24 Feb 2000 18:08:52 +0000
Bart Schaefer wrote:
> On Feb 24, 10:07am, Sven Wischnowsky wrote:
> } Subject: RE: PATCH: parser (was: Re: PATCH: Improved _mailboxes)
> }
> }
> } Andrej Borsenkow wrote:
> }
> } > zcodeload file
>
> Let's not do that, shall we? Let's stick with autoload and have a file
> suffix convention, like emacs' .el and .elc, or something. Heck, there
> could even be separate fpath and compiled_fpath or ...
I was wondering what to do when the directory isn't writable... but a
$COMPILED_FPATH containing one directory would be enough. Hm. Do you
want to say that you actually like the idea? Making everything ready
for the mmap would be quite simple. The only problem I can see is that
we would need to have a wordcode-verifier (but, of course, that can be
done). That's yet another reason for having only a scalar containing
only one directory name (so $COMPILED_FDIR might be a better name) --
save compiled functions only if that is set and names an existing,
writable directory. Users would set it to a directory in their account
so that others can't trick them into using evil code.
> } All this also makes me think about a way to allow multiple zsh's to
> } share other memory bits (like the command table and so on). How
> } portable is anonymous shared mmap or shared mmap on /dev/null?
>
> Do we really want to go down the road of having e.g. zmodload in one
> zsh suddenly make new builtins available to another zsh? I don't want
> the behavior of a script that's running in the background to change
> because of something I loaded into my foreground shell ...
Should be configurable, of course. And to be turned on explicitly. If
at all...
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
next reply other threads:[~2000-02-25 8:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-02-25 8:41 Sven Wischnowsky [this message]
2000-02-25 9:44 ` Precompiled wordcode zsh functions Bart Schaefer
2000-02-25 9:55 ` PATCH: parser (was: Re: PATCH: Improved _mailboxes) Andrej Borsenkow
-- strict thread matches above, loose matches on Subject: below --
2000-02-24 10:03 Sven Wischnowsky
2000-02-24 9:07 Sven Wischnowsky
2000-02-24 18:08 ` Bart Schaefer
2000-02-24 8:54 Sven Wischnowsky
2000-02-23 13:21 Sven Wischnowsky
2000-02-23 16:45 ` Bart Schaefer
2000-02-23 18:58 ` Peter Stephenson
2000-02-24 7:47 ` Andrej Borsenkow
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=200002250841.JAA25219@beta.informatik.hu-berlin.de \
--to=wischnow@informatik.hu-berlin.de \
--cc=zsh-workers@sunsite.auc.dk \
/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).