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