Thank for the answer,
even if I don't think that making available to programmers
a notation which failed to be parsed at export because the
interpreter rely on a specific option disabled by default
is (always ?) a good idea; I'll precise my real use-case:
I wanted to make some functions available once for the whole
X session.
I *guess* that reading (again) the bash_* from the HD is not the
slowest part (but processing it maybe), but I want to attempt
to put those in RAM for X (you would maybe be right to see
that as a dump-newbie-reinventing-the-wheel-he-doesn't-understand
attempt) anyway :
typeset -F|grep '^_[^=]'|cut -d' ' -f3|while read f; do
export -f "$f"
done
(I keep bashcompletion in mind and will probably cry when attempting
to export its arrays)
As fluxbox is currently loaded by the .xinitrc I don't want to do :
exec bash -O extglob -c fluxbox ; (should I really ?)
I also noticed that using $(which) bring the error of definition
one more time :|
>From what I understand there is no way to declare a function
read-only (that would be shared between bash instances without being
copied over and over) so that's why I try to lighter my (surely too
heavy) .bashrc this way.
Best regards
Raph
On Sat, May 09, 2009 at 08:24:49PM -0400, Chet Ramey wrote:
> Raph wrote:
> > Hello,
> > while trying to export this function :
> >
> > foo() {
> > case "$1" in
> > ?(a))
> > echo a
> > ;;
> > esac
> > }
> >
> > with export -f foo I went into some problem
> > as soon as any new instance is launched :
> > bash -c "foo bar" : failed
> > xterm & : failed
> > bash -O extglob : ok
> > bash -O extglob -c "xterm" : failed
> >
> > The failure of the new instance is the following :
> > -
> > bash: foo: line 1: syntax error near unexpected token `('
> > bash: foo: line 1: ` ?(a))'
> > bash: error importing function definition for `foo'
> > -
> > In fact:
> > - $SHELLOPTS doesn't contains extglob
>
> Of course. It's only designed to transmit options settable with `set -o'
> to child processes.
>
> > - $SHELLOPTS is readonly
>
> Yes. You manipulate those options using set -o.
>
> > - bashrc is evaluated after the environment
>
> How else would settings in startup files override the environment?
>
> > - the environment needs extglob
>
> Not really. In this particular case, you could have used `xterm -e'
> to run bash with the -O extglob option.
>
> > It happens that sometimes you need to export some functions
> > without explicitely wanting to add the extglob option.
>
> Maybe. But you're going to have to parse them somehow. That's how
> function definitions work. If you want to pass functions through
> the environment without parsing the definition, save the text to a
> variable and `eval' its value when you want it.
>
> > And alias bash='bash -O extglob' doesn't seem to be clean to me
> > (even if possible as a workaround)
>
> It's not. How would it have helped in your example?
>
> > So the feature request is about a way to set the extglob status
> > from the environment.
> > Kind of solution though in IRC :
> > - shopt -s exportopts
> > - shopt -s exportextglob
> > - extglob part of $SHELLOPTS
> > - load of a kind of .bashrc.env_insensible before anything else
>
> None of these are compelling. Maybe a BASHOPTS analog to SHELLOPTS
> for `shopt' options. It might be useful to provide a configuration
> option that defaults extglob to on, also.
>
> Chet
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>
> Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
