On Tuesday, September 30, 2014 2:42:33 AM UTC+2, Chet Ramey wrote:
> On 9/29/14, 7:53 PM, Alexandre Ferrieux wrote:
>
>
> > [bash -p] *does* disable that embarrassing nightmare of a misfeature that
> > is function import:
>
> I guess if that's what you mean by
On Tuesday, September 30, 2014 1:40:55 AM UTC+2, Chet Ramey wrote:
>
> > Forget about posix mode then: bash -p (privileged) offers a lean-and-mean
> > variant which pretty much satisfies anybody needing "just sh". However,
> > there is no way to store an option in a symbolic link, so all distrib
On Monday, September 29, 2014 9:51:45 PM UTC+2, Chet Ramey wrote:
> >
> > So it seems the order is wrong. As a consequence, and this is confirmed by
> > experience, the #!/bin/sh prefix behaves as featuristic bash.
> > My suggestion then is to undo that mistake.
>
> Posix mode was never intended
On Saturday, September 27, 2014 8:19:49 AM UTC+2, Eric Blake wrote:
>
> I am also in favor of both approaches - moving shell functions into a
> non-colliding namespace (so that arbitrary contents of regular variables
> CANNOT trigger parser bugs) and making shell function exports
> configurable an
On Friday, September 26, 2014 2:14:46 PM UTC+2, Greg Wooledge wrote:
> On Thu, Sep 25, 2014 at 11:53:18PM -0700, Alexandre Ferrieux wrote:
>
> > Of course, their intention is precisely expressed by the '#!/bin/sh' header
>
> Unfortunately, most people don't act
On Friday, September 26, 2014 10:00:08 AM UTC+2, Andreas Schwab wrote:
> Alexandre Ferrieux writes:
>
> > So, what about, in bash's initialization, detecting that we are invoked as
> > "/bin/sh",
>
> It already does. See (bash) Bash POSIX Mode.
Yes, it d
Hello,
In the wake of the exported func bug, as can be seen in the nearby thread
"Issues with exported functions", many people are just now discovering a host
of things that bash does, of course in a documented way, but that they never
needed in the first place.
Of course, their intention is p
On 26/09/2014 08:23, Ralf Naegele wrote:
Hello Eduardo,
I haven't installed the patched bash yet. I called it in the source
directory after compiling, it with ./bash so I think this should start the
patched bash.
You started ./bash as the parent reading the offending line, but did you also
mo
On 25/09/2014 22:51, Eric Blake wrote:
On 09/25/2014 08:48 AM, Alexandre Ferrieux wrote:
Is the response (workarounds and patch) being discussed elsewhere ?
(1) Patch
Looking at the code, it seems that the problem is that in
initialize_shell_variables(), when an inheritable function is
Is the response (workarounds and patch) being discussed elsewhere ?
(1) Patch
Looking at the code, it seems that the problem is that in
initialize_shell_variables(), when an inheritable function is detected in
the environment by the "() {" prefix, we then directly
call parse_and_execute(), on t
10 matches
Mail list logo
