On Dec 17, 2014, at 3:23 PM, Greg Wooledge wrote:
> On Wed, Dec 17, 2014 at 03:16:53PM -0500, Steve Simmons wrote:
>> Advance apologies if I'm misunderstanding, but the described bug looks like
>> reasonable behavior to me.
>
> It would be more reasonable for bas
Advance apologies if I'm misunderstanding, but the described bug looks like
reasonable behavior to me.
When a ssh connection drops, which side notices and when depends on the I/O
being done on either side, the state of any keepalive settings, and the
timeouts involved. If there's a long time be
On Dec 9, 2014, at 9:47 AM, Stephane Chazelas
wrote:
> It's a bit confusing that ${VAR:-""} should be treated
> differently from ${VAR:=""}. Was there a rationale for changing
> the behaviour other than strict POSIX conformance? AFAICT, ksh
> and mksh behave differently (from bash and from each
On Dec 2, 2014, at 4:24 AM, bijay pant wrote:
> From: root
>
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86
On Nov 23, 2014, at 2:08 PM, Chet Ramey wrote:
> On 11/23/14 5:54 AM, Xie Yuheng wrote:
>> we should add ".bash/" along with ".bashrc" as the default init dir.
>> this will make things more flexible, and will not break any existed code.
>> to be "default" is important, people who right simple ma
On Nov 6, 2014, at 10:14 AM, Ian Jackson
wrote:
> Chet Ramey writes ("Re: Shellshock-vulnerable version still most obvious on
> ftp.gnu.org"):
>> On 11/6/14, 7:47 AM, Ian Jackson wrote:
>>> But in the current environment it's looking rather quaint. We could
>>> probably provide a full tarball
On Oct 15, 2014, at 9:38 AM, lorenz.bucher@rohde-schwarz.com wrote:
> Hello,
> in refer to
> http://lists.gnu.org/archive/html/bug-bash/2014-09/msg00278.html variables
> with suffix "%%" can't be set/exported.
> This makes problems restoring environments which where saved by external
> prog
On Oct 9, 2014, at 9:34 PM, TODD TRIMMER wrote:
> If I compile from bash-4.2 from source, cumulatively applying patches through
> 52, things work fine. If I start from scratch and apply through 53, it errors
> out:
>
> gcc -L.. . .
> ./builtins/libbuiltins.a(evalstring.o): In function `parse_
On Sep 27, 2014, at 6:51 PM, Eric Blake wrote:
> On 09/27/2014 04:21 PM, Chet Ramey wrote:
>>
>>> 2) build a 'real' /bin/sh without those compiled in. This begs the
>>> definition of 'real', but IMHO if it's not in POSIX, it shouldn't be in
>>> 'real' /bin/sh
>>
>> This is dash's niche.
>
>
On Sep 27, 2014, at 2:19 AM, Eric Blake wrote:
> The prefix is nice for quick identification, but what is ESSENTIAL is
> something that puts shell functions in a namespace that is untouchable
> by normal shell variables (the "()" suffix in Florian's patch). If all
> you do is add a prefix, but
On Sep 26, 2014, at 12:55 PM, Steve Simmons wrote:
> If I manually update patchlevel.h to change from 0 to 9, the version is
> reported as '2.05b.((1)-release'. Bug?
Bad Steve, no donut. With patchlevel.h correctly modified as above, bash
reports the version as 2.05b.9(1)-re
These patches build and run without problem in our initial bash2 tests.
However, I notice that both the version number reported by ./bash --version and
doing ./bash followed by echo $BASH_VERSION both report "2.05b.0(1)-release".
All versions that I've tested of bash3 and bash4 report their patc
On Sep 26, 2014, at 10:36 AM, Eric Blake wrote:
> . . . I _also_ agree that since function exports are NOT required by POSIX,
> that it would be okay if we let /bin/bash continue to import functions
> by default, but have bash invoked as /bin/sh refuse to do imports by
> default. . .
The more I
On Sep 25, 2014, at 5:42 PM, Alexandre FERRIEUX - SOFT/LAN
wrote:
> 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 ?
>
> Thanks. Like thousands of people I guess, I have never ima
On Sep 25, 2014, at 2:47 PM, lolilolicon wrote:
> On Fri, Sep 26, 2014 at 2:28 AM, Ángel González wrote:
> [...]
>> On the other hand, this approach would be much more interesting if bash
>> delayed parsing of exported functions until they are used (ie. check
>
> This is what function autoload
On Sep 24, 2014, at 4:06 PM, lolilolicon wrote:
> On Thu, Sep 25, 2014 at 3:53 AM, Greg Wooledge wrote:
>>
>> So, if Chet removes the feature, it would probably break something that
>> someone cares about. Maybe there could be a compile-time option to
>> disable it. Maybe there already is --
On Sep 10, 2014, at 4:58 AM, Vincent Lefevre wrote:
> In error messages, raw non-printable characters from arguments should
> not be output without transformation, at least if this is on a terminal.
> If stderr has been redirected, this is more a matter of choice.
>
> An example: type "cd /^M"
On Aug 28, 2014, at 12:37 PM, Chris Down wrote:
> I really don't understand -- why is this unexpected? It's exactly what I'd
> expect to happen if you try to do something like that. It should not be
> disallowed to source yourself, that prevents people from doing things when
> *sensibly* sourc
On Aug 13, 2014, at 2:31 PM, Ken Irving wrote:
> I like the idea, but switch negation would need to be supported, and
> I don't think that's been covered sufficiently. Using ! as a switch
> modifier might be possible, and I like it, but would then also apply to
> single filetest switches, e.g.,
On Aug 12, 2014, at 4:36 PM, Chet Ramey wrote:
> On 8/9/14, 7:07 AM, Steve Simmons wrote:
>
>> It would be nice to have ganged file test switches. As an example, to test
>> that a directory exists and is properly accessible one could do
>>
>> if [[ -d foo ]
On Aug 9, 2014, at 11:16 AM, Andreas Schwab wrote:
> Steve Simmons writes:
>
>> Advance apologies if this has already been discussed and rejected.
>>
>> It would be nice to have ganged file test switches. As an example, to test
>> that a directory exists and is
Advance apologies if this has already been discussed and rejected.
It would be nice to have ganged file test switches. As an example, to test that
a directory exists and is properly accessible one could do
if [[ -d foo ]] && [[ -r foo ]] && [[ -x foo ]] ; then . . .
but
if [[ -drx foo ]] ;
ure set would make life easier on system admins and users
alike. I'm curious as to others' opinions, and am certainly willing to
modify mine.
Best,
Steve Simmons
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
23 matches
Mail list logo
