Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: sourcing a sh file in zsh
- X-seq: zsh-workers 26502
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: sourcing a sh file in zsh
- Date: Sat, 31 Jan 2009 13:39:52 -0800
- In-reply-to: <200901312110.n0VLA2bR006281@xxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <200901312110.n0VLA2bR006281@xxxxxxxxxxxxxxxxxxx>
On Jan 31, 9:10pm, Peter Stephenson wrote:
} Subject: Re: sourcing a sh file in zsh
}
} Bart Schaefer wrote:
} > We face a similar problem with the "sticky" emulation idea. Let's
} > suppose for purposes of illustration that "emulate -S" activates it.
} >
} > emulate -S sh -c 'debug() { set -vx }'
}
} What would be the intention of the code above, anyway?
Well, suppose I've got this sort of thing in a file somewhere:
debug() { set -vx }
big_hairy_sh_app() {
if [[ x$1 = x-d ]]; then debug; shift; fi
do_some_sh_stuff
do_more_sh_stuff
}
do_some_sh_stuff() { echo whatever }
do_more_sh_stuff() { echo whocares }
The intent would be to run
emulate -S sh -c 'source big_hairy_sh_app_as_a_function_library.sh'
and them later invoke it with
big_hairy_sh_app -d
and have all the right emulation settings magically take effect.
If *every* function defined in the sourced file gets an implicit
LOCAL_OPTIONS by virtue of emulation stickyness, then even within the
call to big_hairy_sh_app the embedded call to debug is going to clear
XTRACE and VERBOSE upon returning, and the -d option to the function
library has become useless.
I'm with you that we may just have to say "tough cookies" but we at
least need to understand what we're not allowing.
} To get this right (if that is right), we do need to be careful about
} how } we handle sticky emulation in functions: if we're already in the
} sticky emulation environment, as here, we don't want to set and restore
} options around execution of functions defined in the same emulation
} mode.
I agree, but that means that "already in the sticky" may have to include
"have entered a function that was originally defined with the sticky."
} That would be regardless of which chunks of code they were
} defined in, I think, otherwise we have a new type of firewall (between
} code chunks rather than emulations) that we don't want.
}
} In other words, your orignal code chunk would be fine if combined with
} other code defined in another "emulate sh -c ..." chunk. I think that's
} all we need to get the job done.
Yep, devil in details.
Messages sorted by:
Reverse Date,
Date,
Thread,
Author