Mike Frysinger wrote:
On 18 Aug 2015 13:34, Linda Walsh wrote:
Then can you give any technical reason why a static
lib that uses no network services (i.e. running
on a mini-root ) couldn't be made available for
the various calls that currently claim "dynamic library
support" is necessary.
(1
On 18 Aug 2015 10:51, Chet Ramey wrote:
> On 8/17/15 4:19 AM, isabella parakiss wrote:
> > Quoting is necessary in a few cases:
> >
> > $ var=foo; declare -A "arr$var=([x]=y)"
> > bash: warning: arrfoo=([x]=y): quoted compound array assignment deprecated
> > $ var=foo; declare -A arr$var=([x]=y)
>
On 18 Aug 2015 13:34, Linda Walsh wrote:
> Then can you give any technical reason why a static
> lib that uses no network services (i.e. running
> on a mini-root ) couldn't be made available for
> the various calls that currently claim "dynamic library
> support" is necessary.
(1) http://www.akkad
On Wed, 19 Aug 2015, Yan Pashkovsky wrote:
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_64-pc-linux-gnu'
-DCONF_VENDO
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_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACK
Greg Wooledge wrote:
On Tue, Aug 18, 2015 at 01:49:53PM -0700, Linda Walsh wrote:
Ex: rmx -fr (alias to rm --one-file-system -fr, since rm lacks the
-x switch like 'find, cp, mv, et al.) no longer works to clean
out a directory && stay on *one* file system.
When did POSIX or any historical U
On Tue, Aug 18, 2015 at 3:50 PM, Chet Ramey wrote:
> On 8/18/15 1:43 PM, Dan Douglas wrote:
>> On Tuesday, August 18, 2015 9:54:55 AM CDT Isaac Good wrote:
>>> Would you mind sharing the rational behind having it undocumented?
>>
>> Since I like guessing: the syntax for parameter expansion operato
Andreas Schwab wrote:
Linda Walsh writes:
Ex: rmx -fr (alias to rm --one-file-system -fr, since rm lacks the
-x switch like 'find, cp, mv, et al.) no longer works to clean
out a directory && stay on *one* file system.
Now rm will delete things on any number of file systems, as long
as they
Linda Walsh writes:
> Ex: rmx -fr (alias to rm --one-file-system -fr, since rm lacks the
> -x switch like 'find, cp, mv, et al.) no longer works to clean
> out a directory && stay on *one* file system.
>
> Now rm will delete things on any number of file systems, as long
> as they correspond to a
Sorry I meant to reply to that thread but ran out of time. I think Stephane's
eventual proposal was pretty close to what I had in mind but expressed badly.
I'm not sure why it was eventually decided to deprecate the current system
entirely but I'm not opposed to the idea - especially if it provi
On Tue, Aug 18, 2015 at 01:49:53PM -0700, Linda Walsh wrote:
> Ex: rmx -fr (alias to rm --one-file-system -fr, since rm lacks the
> -x switch like 'find, cp, mv, et al.) no longer works to clean
> out a directory && stay on *one* file system.
When did POSIX or any historical Unix rm have a --one-f
On 8/18/15 1:43 PM, Dan Douglas wrote:
> On Tuesday, August 18, 2015 9:54:55 AM CDT Isaac Good wrote:
>> Would you mind sharing the rational behind having it undocumented?
>
> Since I like guessing: the syntax for parameter expansion operators is
> currently non-extensible, so the namespace of te
Eric Blake wrote:
Like it or not, it is the historical behavior standardized by POSIX.
This is not true. POSIX no longer documents historical behavior,
but now dictates new, historically-incompatible behaviors for a
variety of features in a variety of products (not just BASH).
As such,
2015-08-17 10:19:00 +0200, isabella parakiss:
> Quoting is necessary in a few cases:
>
> $ var=foo; declare -A "arr$var=([x]=y)"
> bash: warning: arrfoo=([x]=y): quoted compound array assignment deprecated
> $ var=foo; declare -A arr$var=([x]=y)
> bash: syntax error near unexpected token `('
> $ v
Clark Wang wrote:
I had the same problem months ago. See Chet's answer:
http://lists.gnu.org/archive/html/bug-bash/2014-03/msg00069.html
===
Yep though I'm not sure about the reasoning in providing
different behaviors based on default-dir-expansion ==> convert
all relative paths to abso
Mike Frysinger wrote:
it is not political, nor is it related to bash at all
-mike
Then can you give any technical reason why a static
lib that uses no network services (i.e. running
on a mini-root ) couldn't be made available for
the various calls that currently claim "dynamic library
support
On 8/18/15 1:52 PM, isabella parakiss wrote:
> Sorry for being both pedantic and late for that discussion but what's the
> point of this warning? From my understanding, the code is still valid, so
> it doesn't stop a possible attacker and it only annoys regular users.
It's meant as an indication
On 8/18/15, Chet Ramey wrote:
> On 8/17/15 4:19 AM, isabella parakiss wrote:
>> Quoting is necessary in a few cases:
>>
>> $ var=foo; declare -A "arr$var=([x]=y)"
>> bash: warning: arrfoo=([x]=y): quoted compound array assignment
>> deprecated
>> $ var=foo; declare -A arr$var=([x]=y)
>> bash: synt
On Tuesday, August 18, 2015 9:54:55 AM CDT Isaac Good wrote:
> Would you mind sharing the rational behind having it undocumented?
Since I like guessing: the syntax for parameter expansion operators is
currently non-extensible, so the namespace of terse operators is in limited
supply. New syntax
Would you mind sharing the rational behind having it undocumented?
On Tue, Aug 18, 2015 at 7:38 AM, Chet Ramey wrote:
> On 8/18/15 9:50 AM, Dan Douglas wrote:
>
> >> Description:
> >> The man page fails to document the ${var~} and ${var~~} case inversion
> >> expansion.
> >> It got the upper and
On 8/17/15 4:19 AM, isabella parakiss wrote:
> Quoting is necessary in a few cases:
>
> $ var=foo; declare -A "arr$var=([x]=y)"
> bash: warning: arrfoo=([x]=y): quoted compound array assignment deprecated
> $ var=foo; declare -A arr$var=([x]=y)
> bash: syntax error near unexpected token `('
> $ va
On Tue, Aug 18, 2015 at 09:22:07AM -0500, Dan Douglas wrote:
> The `~` is obviously inspired by the vim
> movement to toggle caps.
~ is standard vi, not a vim extension.
On 8/18/15 9:50 AM, Dan Douglas wrote:
>> Description:
>> The man page fails to document the ${var~} and ${var~~} case inversion
>> expansion.
>> It got the upper and lower, ie ${var^} and ${var,} but not invert.
>>
>> Fix:
>> More documentation.
>
> I'm pretty sure that's intentional. The corres
On 8/18/15 9:12 AM, Dan Douglas wrote:
> Actually I think I spoke too soon. There's already some considerable logic in
> braces.c to check for overflow (e.g. around braces.c:390 shortly after
> declaration of the int). Looks like there were some changes in this code last
> year to "beef it up"
On 8/15/15 9:02 PM, Sergey Tselikh wrote:
> Description:
> An incorrect conversion from indexed to associative array in bash script leads
> bash interpreter to segfault (bash still gives a useful error report in this
> situation,
> which is good).
>
> As seen in the output of GDB, bash terminate
On Tuesday, August 18, 2015 08:50:51 AM Dan Douglas wrote:
> I'm pretty sure that's intentional. The corresponding `declare -c` has never
> been documented either.
>
Hrm, it doesn't "correspond" actually. declare -c just capitalizes the first
letter of the string.
Another thing about the ${var
BASH PATCH REPORT
=
Bash-Release: 4.3
Patch-ID: bash43-040
Bug-Reported-by:Jean Delvare
Bug-Reference-ID: <20150609180231.5f463695@endymion.delvare>
Bug-Reference-URL:
http://lists.gnu.org/archi
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/ locale' -DPACKAGE
On Monday, August 17, 2015 01:08:55 PM Isaac Good wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: i686
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linu
On Tuesday, August 18, 2015 09:04:33 AM Greg Wooledge wrote:
> On Tue, Aug 18, 2015 at 07:54:48AM -0500, Dan Douglas wrote:
> > IMHO the issue of whether the integer is allowed to overflow is separate
from
> > the question of whether the resulting expansion is "too big". Code that
does
> > an `
BASH PATCH REPORT
=
Bash-Release: 4.3
Patch-ID: bash43-042
Bug-Reported-by:Nathan Neulinger
Bug-Reference-ID: <558efdf2.7060...@neulinger.org>
Bug-Reference-URL:
http://lists.gnu.org/archive/htm
BASH PATCH REPORT
=
Bash-Release: 4.3
Patch-ID: bash43-041
Bug-Reported-by:Hanno Böck
Bug-Reference-ID: <20150623131106.6f111da9@pc1>,
<20150707004640.0e61d2f9@pc1>
Bug-Reference-URL:
http://l
On Tue, Aug 18, 2015 at 07:54:48AM -0500, Dan Douglas wrote:
> IMHO the issue of whether the integer is allowed to overflow is separate from
> the question of whether the resulting expansion is "too big". Code that does
> an `eval "blah{0..$n}"` is reasonably common and not necessarily stupid.
On Monday, August 17, 2015 04:15:50 PM Eric Blake wrote:
> On 08/17/2015 09:58 AM, Pasha K wrote:
> > Hey Greg,
> >
> > I wasn't particularly trying to actually generate that large amount of
> > strings in memory, I wa purposely trying to overflow the integer variable
> > "nelem"hoping to get Code
On Mon, Aug 17, 2015 at 6:15 PM, Eric Blake wrote:
>
> Fix your script to not do stupid things, like trying an insanely-large
> brace expansion, or trying an 'eval' (or similar) on untrusted user
> input. But don't call it a bash security hole that bash allows you to
> write stupid scripts.
>
On 08/17/2015 09:58 AM, Pasha K wrote:
> Hey Greg,
>
> I wasn't particularly trying to actually generate that large amount of
> strings in memory, I wa purposely trying to overflow the integer variable
> "nelem"hoping to get Code Execution. This could potentially be a security
> risk as shell shoc
36 matches
Mail list logo
