Skip to Content.
Sympa Menu

sm-sorcery-bugs - [SM-Sorcery-Bugs] [Bug 13565] undesired pathname expansion in $STD_DEBUG

sm-sorcery-bugs AT lists.ibiblio.org

Subject: Bugs for Sorcery are reported here

List archive

Chronological Thread  
  • From: bugzilla-daemon AT bugs.sourcemage.org
  • To: sm-sorcery-bugs AT lists.ibiblio.org
  • Subject: [SM-Sorcery-Bugs] [Bug 13565] undesired pathname expansion in $STD_DEBUG
  • Date: 26 Feb 2007 15:14:17 -0000

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.




Archive powered by MHonArc 2.6.24.

Top of Page