Re: consistency probs var & function re-use

On Fri, 9 Jun 2017, L A Walsh wrote: Chris F.A. Johnson wrote: On Fri, 9 Jun 2017, L A Walsh wrote: First problem: If you are assigning a string to a variable, you need to put quotes around the string. You don't need to quote it unless it contains literal whitespace. Not exactly

Re: consistency probs var & function re-use

On Fri, 9 Jun 2017, L A Walsh wrote: Chris F.A. Johnson wrote: On Fri, 9 Jun 2017, L A Walsh wrote: First problem: If you are assigning a string to a variable, you need to put quotes around the string. You don't need to quote it unless it contains literal whitespace. Not exactly

Re: consistency probs var & function re-use

Chris F.A. Johnson wrote: On Fri, 9 Jun 2017, L A Walsh wrote: First problem: If you are assigning a string to a variable, you need to put quotes around the string. You don't need to quote it unless it contains literal whitespace. Not exactly true -- "any" type of white space,

Re: consistency probs var & function re-use

On Fri, 9 Jun 2017, L A Walsh wrote: First problem: If you are assigning a string to a variable, you need to put quotes around the string. You don't need to quote it unless it contains literal whitespace. -- Chris F.A. Johnson,

Storing NUL in variables

On Fri, 2017-06-09 at 20:58 +0300, Pierre Gaston wrote: > On Fri, Jun 9, 2017 at 8:40 PM, Peter & Kelly Passchier < > peterke...@passchier.net> wrote: > > > > > On 09/06/2560 23:38, L A Walsh wrote: > > > > > > Chet Ramey wrote: > > > > > > > > > > > >  Should mapfile silently drop the NULs?

Re: Patch for unicode in varnames...

Dethrophes wrote: This would be a bad idea in the same way that having control characters in filenames is a bad idea, just because you can do something doesn't mean you should. Not true. While POSIX has *discussed* disallowing control characters in filenames, using Unicode in filenames is

Re: consistency probs var & function re-use

Greg Wooledge wrote: What are you talking about? Consistency between what two things? Are you allergic to newlines? declare -p uses raw newlines in its output whenever it feels they are appropriate. Even in ordinary shell variables: imadev:~$ x=$'foo\nbar' imadev:~$ declare -p x declare --

Re: Remaining memory corruption bugs in readline

On Fri, Jun 9, 2017 at 4:59 PM, Chet Ramey wrote: [...] > It's an off-by-one error. Thank you! Do you have a patch? I want to run the patched version against the corpus of crashing inputs that I have to see if there are any remaining.

Re: Remaining memory corruption bugs in readline

On 6/8/17 11:34 AM, Chet Ramey wrote: > 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

Re: Trailing newlines disappear

On Fri, Jun 09, 2017 at 08:58:05PM +0300, Pierre Gaston wrote: > Even if they don't realize it, few people would expect: > > var=$(wc -l file);echo "$var" > > to print 2 lines. imadev:~$ file=$'a\nb\nc\nd\ne'; touch "$file" imadev:~$ var=$(wc -l "$file"); echo "$var" 0 a b c d e > Trailing

Re: Trailing newlines disappear

On Fri, Jun 9, 2017 at 8:40 PM, Peter & Kelly Passchier < peterke...@passchier.net> wrote: > On 09/06/2560 23:38, L A Walsh wrote: > > Chet Ramey wrote: > >> > >> Should mapfile silently drop the NULs? > > > > Maybe add a flag to ignore NUL bytes that could be used in the 'read' > > statement as

Re: Trailing newlines disappear

On 09/06/2560 23:38, L A Walsh wrote: > Chet Ramey wrote: >> >> Should mapfile silently drop the NULs? > > Maybe add a flag to ignore NUL bytes that could be used in the 'read' > statement as well? If not specified, keep same behavior? That sounds like it might be useful. It might be more

Re: Trailing newlines disappear

On 09/06/2560 19:06, Greg Wooledge wrote: > imadev:~$ a=$(printf 'foo\0bar\nbaz\nquux\n'; printf x) a=${a%x} > bash: warning: command substitution: ignored null byte in input > imadev:~$ declare -p a > declare -- a="foobar > baz > quux > " > > imadev:~$ IFS= read -rd '' a < <(printf

Re: Trailing newlines disappear

Chet Ramey wrote: Should mapfile silently drop the NULs? Maybe add a flag to ignore NUL bytes that could be used in the 'read' statement as well? If not specified, keep same behavior?

Re: consistency probs w/ 'readonly -f' & 'export -f

Greg Wooledge wrote: I don't know what you mean. A function is not a name=value pair. The name is the name of the function, the value is what the function does. declare -f hw='() { echo "Hello World\n"; }' The above has a name on the left side, and the value of the name is on the right

Re: Trailing newlines disappear

On 6/9/17 9:36 AM, Greg Wooledge wrote: > If anything, the fact that $() drops NUL bytes is the surprising outlier. > But it's definitely too late to change that. Remember how many people > bitched and complained when 4.4 added a warning? How could I forget? But the complaining came because

Re: Trailing newlines disappear

On Fri, Jun 09, 2017 at 09:22:58AM -0400, Chet Ramey wrote: > On 6/9/17 8:06 AM, Greg Wooledge wrote: > > imadev:~$ mapfile -t a < <(printf 'foo\0bar\nbaz\nquux\n') > > imadev:~$ declare -p a > > declare -a a=([0]="foo" [1]="baz" [2]="quux") > > There's no mystery here. Mapfile reads lines

Re: Trailing newlines disappear

On 6/9/17 8:06 AM, Greg Wooledge wrote: > Actually, it looks like the mapfile variant also has its own... let's > call it "idiosyncratic" NUL handling: > > imadev:~$ unset a > imadev:~$ mapfile -t a < <(printf 'foo\0bar\nbaz\nquux\n') > imadev:~$ declare -p a > declare -a a=([0]="foo" [1]="baz"

Re: consistency probs w/ 'readonly -f' & 'export -f

On Thu, Jun 08, 2017 at 03:48:21PM -0700, L A Walsh wrote: > >Second) What is the official way to list functions w/their > >flags+definitions > > in a way reusable as input? declare -fp funcname > >Third) How can one print the flags on a single function? > using> declare -pf Why are you

Re: Trailing newlines disappear

On Fri, Jun 09, 2017 at 08:06:28AM +0700, Peter & Kelly Passchier wrote: > On 09/06/2560 05:26, Eduardo Bustamante wrote: > > What's wrong with: > > > > IFS= read -rd '' foo < "$file" > > I think that's the winner! So long as you know the file doesn't contain any NUL bytes. The other variants