From: DervishD <disposable1@telefonica.net>
To: zsh-users@sunsite.dk
Subject: Re: Making a script 'sourceable'
Date: Sun, 5 Sep 2004 15:33:20 +0200 [thread overview]
Message-ID: <20040905133320.GE13462@DervishD> (raw)
In-Reply-To: <Pine.LNX.4.61.0409040811330.1742@toltec.zanshin.com>
Hi Bart :)
* Bart Schaefer <schaefer@brasslantern.com> dixit:
> > > > The second thing is derived from the above question: since
> > > > checking for 'sourcery' ;) is very difficult even non portably, I've
> > > > thought about making my zsh scripts sourceables.
> > > Lloyd Z. has the way of it.
> > Well, an extra fork... I don't really like that method, but...
> There's also this, wherein a function name unlikely to exist in the
> calling shell is invented and then that function destroys itself as soon
> as it is invoked:
>
> --- 8< ---
> #! bin/zsh
> function __the_real_script_$$ {
> unfunction __the_real_script_$$
> emulate -LR zsh
> # body of script goes here, using "local" to control variables
> }
> __the_real_script_$$ "$@"
> --- >8 ---
>
> However, that pretty thoroughly demolishes the usefulness of $0, and any
> error messages that are printed will fail to show the name of the script
> and the line numbers will be "wrong".
So the method pointed by Lloyd is more suitable...
> On the other hand this (and the subshell wrapper variant, too) has the
> advantage that the entire script is parsed for syntax before any of it is
> executed, so if you make a mistake somewhere you don't have half-finished
> script processing to clean up.
Yes, I noticed that this morning, doing tests :)) For me that
pays for the extra fork.
> Back on the first hand again, though, you pay the memory cost of that
> parse on every call to the script.
Usually the scripts are quite short: in fact, that's the reason
that made me think about auditing the scripts to avoid side-effects
when the script is sourced instead of run in a subshell.
Thanks a lot for your help. I probably end up doing the '()'
thing, because the extra fork really is not very expensive, the only
problem is 'ps' output cluttering ;)
Raúl Núñez de Arenas Coronado
--
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/
next prev parent reply other threads:[~2004-09-05 13:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-04 11:07 DervishD
2004-09-04 15:44 ` Bart Schaefer
2004-09-05 13:33 ` DervishD [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-09-03 16:35 DervishD
2004-09-03 17:01 ` Lloyd Zusman
2004-09-03 22:16 ` DervishD
2004-09-03 17:20 ` Bart Schaefer
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=20040905133320.GE13462@DervishD \
--to=disposable1@telefonica.net \
--cc=zsh-users@sunsite.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).