On 09/06/2560 05:26, Eduardo Bustamante wrote:
> What's wrong with:
>
> IFS= read -rd '' foo < "$file"
I think that's the winner!
Ooops... some more testing...
L
First) readonly & export by show vars in a re-usable format, however,
this doesn't work for functions.
---
It actually seems to be re-usable... though not nearly as
concisely as the var listing format.
Second) What is the official way to list functions
First) readonly & export by show vars in a re-usable format, however,
this doesn't work for functions.
Second) What is the official way to list functions w/their
flags+definitions
in a way reusable as input?
Third) How can one print the flags on a single function?
And a questio
On Thu, Jun 8, 2017 at 3:56 PM, Greg Wooledge wrote:
> On Thu, Jun 08, 2017 at 10:44:29PM +0200, Geir Hauge wrote:
>> You can pick one of these instead:
>>
>> mapfile < "$file"; IFS= foo="${MAPFILE[*]}"; unset -v IFS
>>
>> or
>>
>> mapfile < "$file"; printf -v foo %s "${MAPFILE[@]}"
>
> or
On Thu, Jun 08, 2017 at 10:44:29PM +0200, Geir Hauge wrote:
> You can pick one of these instead:
>
> mapfile < "$file"; IFS= foo="${MAPFILE[*]}"; unset -v IFS
>
> or
>
> mapfile < "$file"; printf -v foo %s "${MAPFILE[@]}"
or
lambda() { local MAPFILE IFS=; mapfile < "$file"; foo="${
On 09/06/2560 03:44, Geir Hauge wrote:
> Greg already pointed out that this doesn't work.
>
> You can pick one of these instead:
>
> mapfile < "$file"; IFS= foo="${MAPFILE[*]}"; unset -v IFS
>
> or
>
> mapfile < "$file"; printf -v foo %s "${MAPFILE[@]}"
>
Yes, thanks.
The second one lo
On Fri, Jun 09, 2017 at 03:34:39AM +0700, PePa wrote:
> On 09/06/2560 02:14, Greg Wooledge wrote:
> > Well, it leaves IFS changed, because you didn't revert or unset it,
> > or run the entire thing in a function with local IFS. Also, I'd use
> > "${MAPFILE[*]}" to reinforce that you are joining an
On 09/06/2560 02:14, Greg Wooledge wrote:
> Well, it leaves IFS changed, because you didn't revert or unset it,
> or run the entire thing in a function with local IFS. Also, I'd use
> "${MAPFILE[*]}" to reinforce that you are joining an array into a string,
> rather than expanding the array as a l
ARGH! You dropped the list address! This was on bug-bash, right??
On Fri, Jun 09, 2017 at 03:14:10AM +0700, PePa wrote:
> On 09/06/2560 02:14, Greg Wooledge wrote:
> > Well, it leaves IFS changed, because you didn't revert or unset it,
> > or run the entire thing in a function with local IFS. A
On Fri, Jun 09, 2017 at 01:52:44AM +0700, Peter & Kelly Passchier wrote:
> On 09/06/2560 00:42, Greg Wooledge wrote:
> > foo=$(cat "$file"; printf x) foo=${foo%x}
>
> The workaround I came up with is:
> mapfile <"$file"; IFS= foo=${MAPFILE[@]}
>
> This seems to be faster, but it probably has othe
On 09/06/2560 00:42, Greg Wooledge wrote:
> It's not a bug. This is how command substitution has worked since
> the original Bourne shell.
>
> The workaround is to put something inside the command substitution,
> so that the newlines aren't trailing any more, and then strip it away
> afterward:
>
On Fri, Jun 09, 2017 at 12:38:19AM +0700, PePa wrote:
> I would think this is a bug:
> 4.3.48(1)-release> printf "q\n\n\n" >w
> 4.3.48(1)-release> printf "$(cat w)"
> q
> 4.3.48(1)-release>
>
> Is there some workaround to somehow preserve the trailing newlines?
It's not a bug. This is how comma
I would think this is a bug:
4.3.48(1)-release> printf "q\n\n\n" >w
4.3.48(1)-release> cat w
q
4.3.48(1)-release> printf "$(cat w)"
q
4.3.48(1)-release>
Is there some workaround to somehow preserve the trailing newlines?
Peter
On 6/8/17 11:09 AM, dualbus wrote:
> On Fri, Jun 02, 2017 at 12:07:34AM -0500, dualbus wrote:
> [...]
>> #1 _rl_get_char_len / update_line
> [...]
>> ==5781==ERROR: AddressSanitizer: heap-buffer-overflow on address
>> 0x6190cc80 at pc 0x7f400d00b063 bp 0x7ffcbce72250 sp 0x7ffcbce71a00
>> R
On Fri, Jun 02, 2017 at 12:07:34AM -0500, dualbus wrote:
[...]
> #1 _rl_get_char_len / update_line
[...]
> ==5781==ERROR: AddressSanitizer: heap-buffer-overflow on address
> 0x6190cc80 at pc 0x7f400d00b063 bp 0x7ffcbce72250 sp 0x7ffcbce71a00
> READ of size 851 at 0x6190cc80 thread T0
>
On Thu, Jun 08, 2017 at 10:30:34AM -0400, Chet Ramey wrote:
[...]
> That would be strange behavior. If it complains about that, why doesn't it
> complain about all memory that bash holds onto but doesn't free before it
> exits?
Hm. You're right. It seems to be glibc's fault here. The leak happens
On 6/8/17 10:24 AM, dualbus wrote:
> After a closer reading, I think the Address Sanitizer is complaining
> about bash's local copy (the one created with `savestring`) not being
> released.
>
> It's not a real issue, but it makes running the tests with ASAN a bit
> less useful.
That would be str
On Thu, Jun 08, 2017 at 09:59:39AM -0400, Chet Ramey wrote:
[...]
> Even though glibc allocates the memory for the current locale, the man page
> warns not to assume that:
>
> "A successful call to setlocale() returns an opaque string that corre-
> sponds to the locale set. This string may be a
On 6/7/17 9:46 PM, dualbus wrote:
> *** /tmp/R6GbnO_locale.c 2017-06-07 20:40:25.575118629 -0500
> --- locale.c 2017-06-07 20:39:59.054419575 -0500
> ***
> *** 85,91
> textdomain (PACKAGE);
>
> locale_mb_cur_max = MB_CUR_MAX;
> ! locale_utf8locale = locale_isutf
19 matches
Mail list logo
