Bugs for Sorcery are reported here

[bugzilla-daemon AT bugs.sourcemage.org]

http://bugs.sourcemage.org/show_bug.cgi?id=13565





------- Additional Comments From jupp AT physik.uni-potsdam.de  2007-02-26 06:57 
-------
(In reply to comment #1)
> Thank you for tracking down the cause of the failure.
> 
> I disagree with your patch because it fixes merely a symptom of the 
> problem, and
> not the actual problem. Instead failglob should either be explicitly 
> disabled,
> or the leak through which failglob got enabled in cast's environment should 
> be
> closed. 

Funny, I would say it is the other way round: unsetting failglob is just
covering up the symptoms (bash will then silently ignore the non-match).

The actual problem is the shell attempting an expansion where this should
not happen (and where it is, admittedly, counterintuitive and unexpected).

Relying on "this expansion won't match anything so it doesn't matter" is
convenient on the command line but I don't think it's a good policy for
scripts (after all, a script which anticipates non-matching expansions
and can handle them can always use shopt -s nullglob instead).



> This failure is probably the tip of the iceberg for non-standard shell
> option setting malfunctions.
> 
> When I try to reproduce this I can only get the failure when I explicitly 
> shopt
> -s failglob *inside* cast or one of sorcery's config files. The way in 
> which you
> reproduce this needs to be further documented. Do you start cast as a 
> regular
> user and let it su for you? Do you run it through sudo? Do you run it 
> already as
> root? Where are you setting failglob?
> 
> Cast should be starting itself in a non-login, non-interactive shell 
> (iirc), so
> most custom settings should be ignored...maybe theres a valid reason and 
> way to
> have failglob enabled in scripts, in which case cast will have to explicitly
> disable it.
> 
> --
> 
> Cast shields itself from custom environment settings except for in specific
> known places. In general programs are written w/ some basic assumptions 
> about
> the environment, they're abstracted away from those details to make the core
> code simpler and easier to write/modify/debug. Imagine what life would be 
> like
> if cast allowed a custom IFS variable.

I have failglob enabled in /etc/profile, to detect and fix those problems.
I don't think of this as an exotic non-standard setting that should cause
unexpected behavour; to me, it's more like a -W switch for gcc.
(and the warnings I do get are quite rare, so it seems feasable to fix, not 
like
the "tip of an iceberg").




-- 
Configure bugmail: http://bugs.sourcemage.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.