About the coprocess article of the Bash man page

Hello. My name is Kazuhiro Takenaka and have used Bash for more than a decade years. In consideration of the purpose of the this maling list, I report a problem in concise. The following sentence is written in the ./doc/bash.html of bash-4.3.tar.gz. A coprocess is executed asynchronously in a s

Re: declare a="$b" if $a previously set as array

On Mon, Dec 15, 2014 at 5:05 AM, Chet Ramey wrote: > On 12/9/14 5:51 PM, konsolebox wrote: >> On Tue, Dec 9, 2014 at 7:29 AM, Linda Walsh wrote: >> >>> Instead of dumbing down bash, why not lobby for bash to record >>> which variables contain tainted input -- and throw an error they are e

Re: declare a="$b" if $a previously set as array

On Mon, Dec 15, 2014 at 5:12 AM, Chet Ramey wrote: > On 12/10/14 8:27 AM, konsolebox wrote: > >>> Note that that's the Bourne shell, not a POSIX sh. >> >> I was actually wanting to say that heirloom-sh is still a modernized >> shell (in code) despite being a strict clone of the original sh. > > It

Re: syntax error near unexpected token `time'

On 12/14/14 11:44 AM, Andre Majorel wrote: > Funny one : > > $ bash -c 'echo a | time cat' > a > [/usr/bin/time output deleted] > > On the other hand : > > $ bash -c 'echo a | > time cat' > bash: -c: line 1: syntax error near unexpected token `time' > bash: -c: line 1: `time cat' >

Re: declare a="$b" if $a previously set as array

On 12/14/2014 08:45 PM, Chet Ramey wrote: On 12/7/14 11:16 PM, Eduardo A. Bustamante López wrote: On Sun, Dec 07, 2014 at 07:34:53PM -0800, Linda Walsh wrote: Only if you properly quote "external input". Well, that's the whole point, as a script writer, I don't expect to get arbitrary code exe

Re: declare a="$b" if $a previously set as array

2014-12-14 20:48:45 +, Stephane Chazelas: [...] > $ bash -c 'declare a[1]="(1 2 3)"; declare -p a' > declare -a a='([0]="1" [1]="2" [2]="3")' > > $ bash -c 'declare a+=([1]="1 2 3"); declare -p a' > bash: line 0: declare: `a+': not a valid identifier > declare -a a='([1]="1 2 3")' > > How do

Re: declare a="$b" if $a previously set as array

On 12/14/14 4:19 PM, Stephane Chazelas wrote: > Yes I don't know what Mint (Ubuntu?) did, but it's a bit broken > see also: > > $ bash -c 'f() { declare a[1]=foo; declare -p a; }; a[0]=x; f; declare -p a' > bash: line 0: declare: a: not found > declare -a a='([0]="x")' > > (sorry about the conf

Re: Bash "bug" - in "read -e -r var"

On 12/13/14 12:06 AM, Daniel A. Gauthier wrote: > > If you do a "read -e -r var" in bash, and use tab completion to fill-in > a filename, it fills in "My\ File\ Name.txt" and that's exactly > what's read into the variable. The fix is simple, in tab completion, > the text placed into the buffer sh

Re: declare a="$b" if $a previously set as array

2014-12-14 14:39:29 -0500, Chet Ramey: [...] > > ~$ bash --version > > GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu) > > Copyright (C) 2013 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later > > > > > > This is free softwar

Re: declare a="$b" if $a previously set as array

On 12/10/14 8:27 AM, konsolebox wrote: >> Note that that's the Bourne shell, not a POSIX sh. > > I was actually wanting to say that heirloom-sh is still a modernized > shell (in code) despite being a strict clone of the original sh. It's not a `strict' clone'. It is a modified version of the SV

Re: declare a="$b" if $a previously set as array

On 12/10/14 5:43 AM, Stephane Chazelas wrote: > It's ironic that local scoping is now implemented in virtually > all POSIX shells but not specified by POSIX. It almost was, once. It's one of my great regrets that I got rid of my paper copy of Posix 1003.2 draft 9, which specified `local'. -- `

Re: declare a="$b" if $a previously set as array

On 12/9/14 5:51 PM, konsolebox wrote: > On Tue, Dec 9, 2014 at 7:29 AM, Linda Walsh wrote: > >> Instead of dumbing down bash, why not lobby for bash to record >> which variables contain tainted input -- and throw an error they are eval'ed >> (based on an option setting, of course)? > > F

Re: declare a="$b" if $a previously set as array

2014-12-14 14:57:15 -0500, Chet Ramey: [...] > Well, I don't think it's particularly a syntax issue. It's the question > I wrote in my previous message: how much further should we move compound > assignment away from the execution semantics associated with builtins. [...] IMO, the ksh behaviour i

Re: declare a="$b" if $a previously set as array

On 12/9/14 7:55 AM, konsolebox wrote: > Other shells certainly does not support local > scopes. Pretty much every other shell except the straight descendants of the System V Bourne shell supports local scopes. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars

Re: declare a="$b" if $a previously set as array

On 12/9/14 5:59 AM, Stephane Chazelas wrote: > BTW, it's worth noting (and maybe documenting) that word > splitting and filename generation are performed in: > > declare -g $var=$something > (or declare ''var=$something or declare f\oo=$bar...) > > So it must be indeed: > > declare -g "$var=$so

Re: declare a="$b" if $a previously set as array

On 12/8/14 9:51 PM, konsolebox wrote: > On Sun, Dec 7, 2014 at 7:24 AM, Stephane Chazelas > wrote: >> $ b='($(uname>&2))' bash -c 'a=(); declare -r a=$b' >> Linux > > I actually also don't like that form of implementation. Even if declare > is a builtin and not a reserved word, it still has some

Re: declare a="$b" if $a previously set as array

On 12/8/14 6:29 PM, Linda Walsh wrote: >> Also, it's *not* the way it's supposed to operate. Arrays are not POSIX, how >> can this be the way it's "supposed" to operate? Where do you get that from? > > Of the shells you mention, which implemented arrays first? ksh did. It certainly had

Re: declare a="$b" if $a previously set as array

On 12/8/14 4:31 PM, Eduardo A. Bustamante López wrote: > If you want delayed evaluation, use 'eval', that's what it's for. Your use > case > is a lame excuse for a "feature" that's clearly more evil than useful. I stopped reading right here. In the end, this is a minor argument about a relative

Re: declare a="$b" if $a previously set as array

On 12/8/14 3:48 PM, Linda Walsh wrote: >> intending to declare the *scalar* varible "$a" as a copy of the >> scalar variable "$b" > > How does the script writer **KNOW** $a and $b are scalar? I agree that the script writer needs to pay attention to the types and values of variables he i

Re: declare a="$b" if $a previously set as array

On 12/8/14 4:56 AM, Stephane Chazelas wrote: > I'm saying that if a script writer writes: > > declare a="$b" > > intending to declare the *scalar* varible "$a" as a copy of the > scalar variable "$b" (and remember that in ksh/bash, scalar > variables and arrays are not very differentiated, $

Re: syntax error near unexpected token `time'

hi Andre, it has been worked on: https://lists.gnu.org/archive/html/bug-bash/2014-11/msg00031.html https://lists.gnu.org/archive/html/bug-bash/2014-11/msg3.html https://lists.gnu.org/archive/html/bug-bash/2014-11/msg5.html cheers, pg On Sun, Dec 14, 2014 at 7:28 PM, Eduardo A. Bustama

Re: declare a="$b" if $a previously set as array

On 12/7/14 11:16 PM, Eduardo A. Bustamante López wrote: > On Sun, Dec 07, 2014 at 07:34:53PM -0800, Linda Walsh wrote: >> Only if you properly quote "external input". > Well, that's the whole point, as a script writer, I don't expect to get > arbitrary code execution here: > > | dualbus@hp:~/t$ un

Re: declare a="$b" if $a previously set as array

On 12/7/14 5:36 AM, Stephane Chazelas wrote: > In this case, it's not about sanitizing external input, at least > as far as the $external_input variable is concerned. In a way, it is. It's understanding the context in which external input is going to be used. However, I think that you're right,

Re: syntax error near unexpected token `time'

You might be interested in this thread: https://lists.gnu.org/archive/html/bug-bash/2014-10/msg00241.html The issue hasn't been worked on, but, this new thread seems like a continuation of that old one :)

syntax error near unexpected token `time'

Funny one : $ bash -c 'echo a | time cat' a [/usr/bin/time output deleted] On the other hand : $ bash -c 'echo a | time cat' bash: -c: line 1: syntax error near unexpected token `time' bash: -c: line 1: `time cat' [$PS2 deleted] Dash, ksh and zsh accept either form. That was wi