zsh-users
 help / color / mirror / code / Atom feed
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/


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