[Feature Request]export extglob from environment
Raph
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
- $SHELLOPTS is readonly
- bashrc is evaluated after the environment
- the environment needs extglob
It happens that sometimes you need to export some functions
without explicitely wanting to add the extglob option.
And alias bash='bash -O extglob' doesn't seem to be clean to me
(even if possible as a workaround)
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
- ...
I wish it's understandable, thank in advance.
Raph
Chet Ramey
> 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 ch...@case.edu http://cnswww.cns.cwru.edu/~chet/
Raph
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
Jan Schampera
hello Raph,
I was involved in the discussion on IRC (Freenode / #bash) yesterday,
maybe I can give one or the other comment.
It took a while for us to find out why it happens. When we knew it, and
after some discussion, we agreed that the easiest way would be to make
Bash able to initialize the shopts from the environment, similar to
SHELLOPTS.
We discussed other ways, also non-Bash solutions, but they're all more
workarounds than solutions.
>> - the environment needs extglob
>
> Not really. In this particular case, you could have used `xterm -e'
> to run bash with the -O extglob option.
This isn't always possible, easy or even wanted. One of those
"workarounds" from above, IMHO.
> 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.
I'd prefer some own transport variable in environment, like you said.
It's not only extglob that isn't transported, though for the rest it
doesn't result in syntax errors. Transporting these options would make
the behaviour more consistent and less surprising.
If a configure option exists or not is more a matter of taste I'd say.
But this particular problem would have been solved, yes :)
Regards,
Jan "TheBonsai" Schampera