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 compoun
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 *
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
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'
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' end
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> "
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
> scop
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 a
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):
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
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
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'
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
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 f
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 Dou
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/200
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 "t
Here 'terminated' is related to shell syntax, as in: 'the command line is
terminated by the & character'
You can terminate commands with & ; \n ...
18 matches
Mail list logo
