Re: About the coprocess article of the Bash man page
Here 'terminated' is related to shell syntax, as in: 'the command line is terminated by the & character' You can terminate commands with & ; \n ...
Re: syntax error near unexpected token `time'
On 2014-12-14 21:12 -0500, Chet Ramey wrote: > Yes, `time' should not be recognized as a reserved word in this case, even > though the previous token is a newline. I'll take a look at it. Thanks > for the report. Note that the error occurs even if there is white space between the newline and "time". Thank you Chet, Eduardo and Piotr. -- André Majorel http://www.teaser.fr/~amajorel/
Re: declare a="$b" if $a previously set as array
So I'm still getting caught up on this thread, but hasn't this issue been done
to death in previous threads? Back when I was examining bash's strange declare
-a, you were the very first person I found to notice its quasi-keyword behavior
10 years ago
(https://lists.gnu.org/archive/html/bug-bash/2004-09/msg00110.html). Perhaps
you didn't realize what this was doing at the time?
To me the biggest problem is what happens when you explicitly request a scalar
assignment. (I even specified a[1] to ensure it's not an "a vs. a[0]" issue.)
bash -c 'typeset -a a; b="(foo bar)"; typeset a[1]=$b; typeset -p a;
printf "<%s> " "${a[@]}"; echo'
declare -a a='([0]="foo" [1]="bar")'
This doesn't fit with my understanding of how it should work. Otherwise I think
the way declare's arguments are interpreted based upon their form and current
set of attributes is pretty well understood, albeit undocumented.
I agree that ksh sometimes makes more sense. I'd add that although ksh's
typeset will never evaluate its non-literal parts of assignment arguments as
assignment syntax after the initial expansion, in ksh it isn't possible to
modify the _type_ of a variable after declaration to begin with, because ksh
has a confusing distinction between "types" and "attributes". Every time you
use a _different_ declaration command, you're wiping all attributes and
effectively unsetting then declaring a whole new variable, while attributes
remain mutable.
# In this case we're modifying attributes
$ ksh -c 'typeset -a x=(foo); print "${@x}"; typeset -r x=; print
"${@x}"'
typeset -a
typeset -r -a
# In this case we're modifying an attribute, then declaring a new
variable
# (and then implicitly modifying its attribute, though "${@a}" fails to
# report it correctly).
$ ksh -c 'typeset -a a=(foo); print "${@a}"; typeset -T A=(typeset x);
A a=(x=foo); print "${@a}"; a+=(x=bar); print "${@a}"; typeset -p a'
typeset -a A
A
A -a a=((x=foo) (x=bar))
If it were redesigned today there would surely be no attributes, only types.
--
Dan Douglas
Re: declare a="$b" if $a previously set as array
Sorry I did a bad job copy/pasting then editing that last example.
ksh -c 'typeset -a x=(foo); print "${@x}"; typeset -T A=(typeset y); A
x=(y=foo); print "${@x}"; x+=(y=bar); print "${@x}"; typeset -p x'
typeset -a
A
A
A -a x=((y=foo) (y=bar))
--
Dan Douglas
Re: Bash "bug" - in "read -e -r var"
On Sunday, December 14, 2014 04:27:51 PM Chet Ramey wrote: > 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 should be in the same format that the > > read is expecting, so if "-r" is in effect for the read operation, the > > the filename should be added to the buffer unquoted. > > This seems like an awfully specific case (-r in effect, one or fewer > variables specified) to change readline for. I question whether it's of > general interest. > I'm generally interested in what read with (or without) -r combined with -e even means. I understand that read's now basically useless behavior without -r was originally there to make using it interactively without a line editor slightly easier. -- Dan Douglas
Error while building a static version of Bash 4.3.30
Hello, I've tried to build a static version of Bash 4.3.30 using these commands: export CFLAGS="-static -O2 -g" export PATH="/usr/bin:$PATH" ./configure --without-bash-malloc make and got this error: ./lib/sh/libsh.a(shmatch.o): In function `sh_regmatch': /home/serge/Downloads/bash-4.3.30/lib/sh/shmatch.c:111: undefined reference to `sh_xfree' /home/serge/Downloads/bash-4.3.30/lib/sh/shmatch.c:112: undefined reference to `sh_xfree' collect2: error: ld returned 1 exit status make: *** [bash] Error 1 Not sure, may be I overlooked something. Can it be some bug or missing dependency in the Bash source code? Regards, Sergey.
Re: Bash "bug" - in "read -e -r var"
On 12/15/14, 7:11 AM, Dan Douglas wrote: > I understand that read's now basically useless behavior without -r > was originally there to make using it interactively without a line editor > slightly easier. Ask David Korn, since he originally added options to the read builtin. None of the `pure' Bourne shells ever had it. It may be the case that it was easier to use \ to enter characters that were special to word splitting, since without it it's very difficult to read values containing spaces when using more than one variable. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Bash "bug" - in "read -e -r var"
On 12/15/14, 7:11 AM, Dan Douglas wrote: > I'm generally interested in what read with (or without) -r combined with -e > even means. I'm not sure what you're driving at. The -e option says how to read the line; the -r option affects how the characters are processed after being read. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Bash "bug" - in "read -e -r var"
On Monday, December 15, 2014 10:47:29 AM Chet Ramey wrote: > On 12/15/14, 7:11 AM, Dan Douglas wrote: > > > I'm generally interested in what read with (or without) -r combined with -e > > even means. > > I'm not sure what you're driving at. The -e option says how to read the > line; the -r option affects how the characters are processed after being > read. > Ah ok I thought -e basically negated the effect of -r for some reason but I guess not (like you can still use \ to escape line continuations without -r it seems). Long ago I assumed "read <<
Re: Error while building a static version of Bash 4.3.30
On 12/15/14, 6:59 AM, Sergey Mikhailov wrote: > Hello, > I've tried to build a static version of Bash 4.3.30 using these commands: > > export CFLAGS="-static -O2 -g" > export PATH="/usr/bin:$PATH" > ./configure --without-bash-malloc > make > > and got this error: > > ./lib/sh/libsh.a(shmatch.o): In function `sh_regmatch': > /home/serge/Downloads/bash-4.3.30/lib/sh/shmatch.c:111: undefined > reference to `sh_xfree' > /home/serge/Downloads/bash-4.3.30/lib/sh/shmatch.c:112: undefined > reference to `sh_xfree' > collect2: error: ld returned 1 exit status > make: *** [bash] Error 1 > > Not sure, may be I overlooked something. > Can it be some bug or missing dependency in the Bash source code? It looks like that's a good possibility. I'll take a look. In the meantime, you can always just do a `make clean' before rebuilding with new configure options. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: declare a="$b" if $a previously set as array
2014-12-15 05:41:51 -0600, Dan Douglas:
> So I'm still getting caught up on this thread, but hasn't this issue been done
> to death in previous threads? Back when I was examining bash's strange declare
> -a, you were the very first person I found to notice its quasi-keyword
> behavior
> 10 years ago
> (https://lists.gnu.org/archive/html/bug-bash/2004-09/msg00110.html). Perhaps
> you didn't realize what this was doing at the time?
[...]
I can't say I remember that one, but note that was a different
case that was later fixed. That was about:
declare -a a=("$b")
where the content of $b was further evaluated.
$ b='$(uname>&2)' bash-2.05b -c 'declare -a a=("$b")'
Linux
That one was more clearly a bug as no one could really be
expected to escape the content of $b there.
I probably did not notice at the time that it was also the case
with:
declare -a a="(...)"
though it would never have occurred to me to use that syntax
(although it's true that's the syntax that is used by declare -p)
As previously mentionned, another related bug that was also
reported over 10 years ago:
http://lists.gnu.org/archive/html/bug-bash/2003-10/msg00065.html
That one was about:
a=($var) or a=(*) (without or without "declare") where the
resulting words may be of the form: [0]=foo (and then, I had
not realised at the time that it was a code injection
vulnerability as well):
$ a='[0$(uname>&2)]=foo' bash-2.05b -c 'b=("$a")'
Linux
--
Stephane
Re: declare a="$b" if $a previously set as array
On Wednesday, December 10, 2014 10:43:45 AM Stephane Chazelas wrote:
> David Korn mentions that local scoping a la ksh was originally rejected by
> POSIX because ksh88 originally implemented "dynamic scoping" (like most
> shells now do, but most other languages don't). ksh changed to lexical
> scoping in ksh93 (probably partly to address that POSIX /requirement/) and
> now everyone else wants dynamic scoping because that's how most shells have
> implemented it in the interval.
A local builtin and dynamic scope is in the current beta of ksh.
I don't care very much for how it works though. It's only enabled as a part of
"bash mode", which actively disables a bunch of ksh features and doesn't allow
you to pick and choose. Bash mode is "all or nothing" at least as of the last
snapshot, with no tunables like zsh's setopt.
$ ksh -c 'function f { typeset x="in f"; g; typeset -p x; }; function
g { x="in g"; }; x=global; f; typeset -p x'
x='in f'
x='in g'
$ ( exec -a bash ksh -c 'function f { typeset x="in f"; g; typeset -p
x; }; function g { x="in g"; }; x=global; f; typeset -p x' )
x='in g'
x=global
I would have much preferred if David Korn followed his original proposal of
adding dynamic scope for only POSIX-style function definitions across the
board. At least porting bash scripts will be slightly easier in the very
specific case that ksh is invoked correctly.
--
Dan Douglas
Re: declare a="$b" if $a previously set as array
On 12/15/14 6:41 AM, Dan Douglas wrote:
> To me the biggest problem is what happens when you explicitly request a scalar
> assignment. (I even specified a[1] to ensure it's not an "a vs. a[0]" issue.)
>
> bash -c 'typeset -a a; b="(foo bar)"; typeset a[1]=$b; typeset -p a;
> printf "<%s> " "${a[@]}"; echo'
> declare -a a='([0]="foo" [1]="bar")'
>
>
> This doesn't fit with my understanding of how it should work. Otherwise I
> think
> the way declare's arguments are interpreted based upon their form and current
> set of attributes is pretty well understood, albeit undocumented.
If you use a subscript with typeset, even when you're attempting an
assignment, the following text from the manual page applies:
"To explicitly declare an indexed array, use declare -a name (see SHELL
BUILTIN COMMANDS below). declare -a name[subscript] is also accepted;
the subscript is ignored."
Bash treats `typeset name[subscript]' as identical to `typeset -a name'
or `typeset -a name[subscript]'.
It's syntax picked up from old versions of ksh, which actually used the
subscript to size the array. Maybe it should attempt subscript assignment,
but it never has.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Bash "bug" - in "read -e -r var"
On 12/15/14 11:13 AM, Dan Douglas wrote: > Ah ok I thought -e basically negated the effect of -r for some reason but I > guess not (like you can still use \ to escape line continuations without -r it > seems). They're separate but kind of clumsy to use together for line continuations. `read' ends up calling readline N times for every N-1 backslash-escaped newlines. If -r is supplied it doesn't need to do anything out of the ordinary for \. In terms of backslash escaping characters in the line read, backslash isn't really special to readline, it's just mapped to self-insert. You still have to use quoted-insert to insert characters that are bound to line editing commands. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: declare a="$b" if $a previously set as array
Chet Ramey wrote:
On 12/8/14 4:56 AM, Stephane Chazelas wrote:
I'm saying that if a script writer writes:
declare a="$b"
I don't think it's unreasonable for a script writer to expect that
this does not unset a; it's not documented to do that, and assignment
without the `declare' doesn't unset it. Assignment without declare
also pays attention to the variable's state: assigning to `a' as if it
were a scalar doesn't magically convert it from an array to a scalar;
it assigns element 0, as you know.
Similarly, if you use 'set', or 'shopt', they doesn't reset
all the state variables addressable w/those commands. declare can
be used to toggle those variable attributes w/o destroying the rest.
Though I just ran into a bit of weirdness (in 4.2.45)
(output is commented out and indented):
env -i /bin/bash --norc --noprofile
declare -a ar=(ONE TWO THREE)
declare -p ar
# declare -a ar='([0]="ONE" [1]="TWO" [2]="THREE")'
add 'l', and note output:
declare -al ar=(${ar[@]})
declare -p ar
# declare -al ar='([0]="ONE" [1]="TWO" [2]="THREE")' # Note - no
conversion
# ok, now set export:
declare -x ar=(${ar[@]})
declare -p ar
declare -axl ar='([0]="one" [1]="two" [2]="three")' # now "-l"
takes effect
---
Same thing happened w/integers... delayed conversion.
Weird. prolly fixed. (?)
- it will work in most of the cases (and that's one aspect why
it's dangerous, because it's hard to detect).
- but you've got a code injection vulnerability (in the very
special case where $b starts with "(".
- for no good reason. See ksh for a better syntax that doesn't
have the issue.
It is code injection because the script writer is using unchecked
input.
That's why I thought it might be a "way out" to "evolve" bash to
know what vars come from the user or the environment -- then
shopt -o no_eval_tainted
would throw an error on *any* eval (whether it uses 'eval' or
not). (obviously not happening overnight, but it would be
more than a simple band-aid correcting this one use case
It's still a script writer's responsibility to check input
before blindly using it: this isn't considered a bug in
the C language -- but it is considered unsafe practice:
char * buff = getenv("PATH");
printf(buff);
Do you really think BASH should be changed because of
bad practice?
Re: declare a="$b" if $a previously set as array
On 12/14/14 4:44 PM, Stephane Chazelas wrote: > There's still a (security) issue with > > declare -x/-l/-r > that may still be used in non-function contexts (not "export" or > "readonly"), and as result for things like: > > saved=$(export -p var) > ... > eval "$saved" > > And with declare -g in functions, so probably still worth > addressing. What's your proposal? Let's see if we can get to something concrete. Something like what I proposed in one of my previous messages would probably work to make declare -a var=value closer to declare -a var; var=value -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: declare a="$b" if $a previously set as array
On Sunday, December 14, 2014 09:44:16 PM Stephane Chazelas wrote:
> but:
>
> x='($(uname>&2))' bash -c 'f() { a[0]=x; declare a=$x; }; f'
>
> is not, because when in a function, declare ignores variables by
> the same name that have not been declared in that same scope
> (even if they have been *set* in that context)
>
> So it's more unlikely to be a problem than I thought it would be
> as "declare" is mostly used in functions.
Indeed I was just about to point this out. It's a rare scenario at least in my
code to either declare something twice in the same scope or rely upon a global
being in a particular state.
--
Dan Douglas
Re: declare a="$b" if $a previously set as array
On Sunday, December 14, 2014 02:39:29 PM Chet Ramey wrote:
> And we get to the fundamental issue. Is it appropriate to require
> arguments to declaration commands to be valid assignment statements when
> the parser sees them, instead of when the builtin sees them, at least
> when using the compound assignment syntax.
>
> I'm ok with tightening the rules and saying that it is, but it's not
> backwards compatible and changes the behavior of things like
>
> declare -a foo='(1 2 3)'
>
> which I imagine plenty of people have used and has been a supported way
> to do compound assignment for many years.
That would be one way but I think this can be solved without going quite
so far. How do you feel about these rules?
1. If a word that is an argument to declare is parsed as a valid
assignment, then perform the assignment immediately as it appears
lexically. If such a word is parsed as a simple assignment (with or
without an index) then bash treats it as a simple scalar assignment
to
the variable or array element as any ordinary assignment would. If
word
is parsed as an assignment with array initializer list then bash
treats
it as such.
2. Any words that do not parse as valid assignments lexically during
step
1 undergo the usual set of expansions for simple commands and the
resulting words are saved.
3. After evaluation of all words from steps 1-2, those that have
undergone
expansion per 2 are passed as arguments to declare. Declare then
parses
each of these arguments, testing for assignments that became valid as
a result of expansion. During this step, for assignments to variables
that have an array attribute set, or for all assignments if declare
has
been given the -a or -A option, declare will treat assignments that
have
initializer lists as array assignments accordingly. Otherwise,
declare
will treat all assignments as scalar assignments to a variable or
array
element. Words that still fail to parse as valid assignments are an
error.
I think this covers all the bases and is very close to the current behavior
with one exception. All of the problems Stephane and I have brought up deal
with the situation where a word that parses lexically as a scalar assignment
isn't treated as such, so that is the only required change. I don't think
that change will break many scripts.
Some observations:
* This solves the problem without breaking backwards compatibility and allows
declare -p output to continue to function.
* These rules will make the following become compatible with current ksh
versions:
$ ksh -c 'function f { typeset x[1]="(foo bar)"; typeset -p x; }; f'
typeset -a x=([1]='(foo bar)')
$ bash -c 'function f { typeset x[1]="(foo bar)"; typeset -p x; }; f'
declare -a x='([0]="foo" [1]="bar")'
* Treating words that parse as scalar assignments as scalar assignments is
consistent with bash's usual treatment of "a[idx]=(foo)". If bash sees
"declare foo[1]=(foo)", it should print:
"bash: foo[1]: cannot assign list to array member".
* Note the fine print in step 3. It deals with this case in bash's current
behavior and doesn't need to change (-a vs no -a):
$ bash -c 'x="[4]=foo [6]=bar"; declare -a "y=($x)"; declare -p y'
declare -a y='([4]="foo" [6]="bar")'
$ bash -c 'x="[4]=foo [6]=bar"; declare "y=($x)"; declare -p y'
declare -- y="([4]=foo [6]=bar)"
--
Dan Douglas
