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 11:45 -------
(In reply to comment #5)

> > > 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.
> 
> I tried to point out one place where it doesn't (lines where $STD_DEBUG
> is expanded).

By that argument, someone could have set -e on, and then whenever any command
fails it should be fixed to not fail. Since its potentially a problem, if a
command fails.

By the information you've presented in the bug thusfar, and the way you've
carried this argument, this is not a problem, unless you have failglob on.
failglob is not valid inside sorcery, therefore its not a bug, in it of 
itself.


> 
> > 
> > So your argument is that its a debugging feature. 
> 
> Yes.

One that is unsupportable given its behavior.

> 
> > Therefore we should use it.
> 
> No.
> My argument is that I used it and it detected a potential problem.

My argument was that the "potential problem" you found is not a problem, and 
its
only caused by running the code in a way it was not intended to run. The code
isnt intended to run set -e, which is also a debugging feature.

> 
> > Unlike -W, which causes gcc to PRINT warnings, this causes the code to 
> > HALT.
> 
> I like that (and I can switch it off if needs be), but that's not the point.
> I did not suggest to switch on failglob; I suggested to fix the problem.
> 

Its not something you should have been able to turn on. Nor does the fact that
it fail, imply that a real bug exists. Theres lots of places in the code where
you could get a failglob to crash sorcery. That does not imply those are real
bugs, in-it-of-itself.

> 

(In reply to comment #6)
> > 
> > i understand what the problem is, thank you.
> 
> I'm not convinced we are talking about the same thing: to reproduce this bug
> without ever setting failglob try this:
> 
> mkdir '_stddbg_file=${_stddbg_file##.};touch Foobar ;'
> touch '_stddbg_file=${_stddbg_file##.};touch Foobar ;/};'
> 
> Then cast something.
> 
> (Luckily, cast never seems to evaluate $STD_DEBUG while being in /tmp)
>  

Ok, you're changing directions pretty drastically at this point. Lets recap.

You introduced the problem as:

I turned failglob on.
Bad things happened.
Backquote the bad thing to make the problem go away.

The implication therefore is that failglob was a valid and supported thing to
do, and that a problem caused by setting failglob should be fixed. With the 
only
justification being that failglob makes it fail.

I disagreed and said that failglob is not valid inside sorcery, therefore the
problem is not valid because you ran the code outside its contract. That the
code should be fixed to disallow running it outside its contract.

Now you're claiming the bug exists without failglob at all. Do you still 
contend
failglob is valid inside sorcery? Or can we move on now?

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