Bugs for Sorcery are reported here

[bugzilla-daemon AT bugs.sourcemage.org]

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





------- Additional Comments From acedit AT armory.com  2007-02-26 09:14 -------
(In reply to comment #3)
> (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 code handles this situation other ways. It is not necessary to have it on.
Sorcery already handles glob failures by checking for emptiness or having 
loops.
Just because a feature exists doesnt mean its necessary to use it.

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

i understand what the problem is, thank you.

> 
> 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).
> 

So your argument is that its a debugging feature. Therefore we should use it.

> 
> 
> > 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.

Ok thanks, thats probably enough information to figure out how the leak was 
started.

> 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").
> 
> 
> 

Unlike -W, which causes gcc to PRINT warnings, this causes the code to HALT.
That is not a sound comparison.

Consider that its a mere coincidence your shell is the same language cast is
written in. You cant make the argument that because you have shell settings a
certain way, that sorcery *should* allow those settings to be used internally,
whether or not its advertised.

You would not have a very successful time convincing anyone of the same thing 
if
your shell of choice was perlsh. Then you chose to enable a debugging option 
in
it then it effected some tools you use, which happen to be written in perl.

I am not arguing that these shell options (which in my experience very few
people use) are completely useless. Certainly they have a use. Im arguing that
they are not something that sorcery needs to use. As I've stated, we handle
globs differently by testing the results. Glob failures are *expected* in some
of our code. Inserting failure points there is

Before you try and make sweeping policy decisions, I think you need more
background in sorcery internals. Its not a trivial "script" that you can just
turn shell options on or off and have it still work. Its a program, like any
other. It just happens to be written in bash.

-- 
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.