Re: [Feature Request]export extglob from environment

[Raph]

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, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/