On 8/26/24 10:57 PM, Zachary Santer wrote:
Bash Version: 5.3
Patch Level: 0
Release Status: alpha
This is devel, commit 2e01122fe7.
Really don't get what's going on here:
You have two instances of the shell fighting over terminal input.
--
``The lyf so short, the craft so long to lerne.'' -
On 8/26/24 6:44 PM, youheng@gmail.com wrote:
Bash Version: 5.3
Patch Level: 0
Release Status: alpha
POC:
$ cat poc.sh
eval '<${;}'
The specific case is an empty command containing only a redirection that
results in an expansion error read from a script or string.
I can confirm that the
On 8/26/24 9:52 PM, Dale R. Worley wrote:
writes:
Repeat-By:
1. Create a script, i.e. `poc.sh` with the problematic string
2. Execute `bash poc.sh`
Interestingly, when I run it (bash 5.1.0(1), which is pretty old), I
don't get the seg fault when I enter that string from the
On Sun, Aug 25, 2024 at 8:57 PM wrote:
>
> All the following scripts can create a Segmentation Fault
>
> eval '<$[;]'
>
> eval '<$(;)'
>
> eval '<${;}'
>
> eval '<$[|]'
>
> eval '<$(|)'
>
> eval '<${|}'
Configuration Information [Automatica
writes:
> Repeat-By:
> 1. Create a script, i.e. `poc.sh` with the problematic string
> 2. Execute `bash poc.sh`
Interestingly, when I run it (bash 5.1.0(1), which is pretty old), I
don't get the seg fault when I enter that string from the keyboard, only
when it's read from a scrip
>> These still cause the current devel branch to segfault, but (at least
>> for me, on macOS) only when invoked via argument, as OP directed. For
>> example, reading the scripts via stdin avoids the segfault.
Tested on commit cf694865de527e597de5a906643a74037341a431
I reproduced within a Docker
On 8/25/24 10:54 PM, Lawrence Velázquez wrote:
On Sun, Aug 25, 2024, at 6:24 PM, youheng@gmail.com wrote:
Bash Version: 5.1
Patch Level: 16
Note that this version of bash is outdated and will not receive
further updates. The current release is 5.2.
All the following scripts c
On Sun, Aug 25, 2024, at 6:24 PM, youheng@gmail.com wrote:
> Bash Version: 5.1
>
> Patch Level: 16
Note that this version of bash is outdated and will not receive
further updates. The current release is 5.2.
> All the following scripts can create a Segmentation Fault
>
> eva
On Wed, May 10, 2023 at 09:05:20PM +0800, Clark Wang wrote:
> See the following example (with 5.2.15):
>
> bash-5.2$ PS1='$? >> '
> 0 >> eval '`'
> bash: unexpected EOF while looking for matching ``'
> 0 >><-- press ENTER
> 2 >><-- now $? is 2
>
>
> It looks like the failed eval
On 6/11/19 10:07 AM, Andreas Schwab wrote:
> On Jun 11 2019, Chet Ramey wrote:
>
>> Maybe. But the user-visible option that says whether or not to save
>> commands in the history is decoupled from the internal set of flags that
>> control it. The option should remain visibly on unless the user tu
On Jun 11 2019, Chet Ramey wrote:
> Maybe. But the user-visible option that says whether or not to save
> commands in the history is decoupled from the internal set of flags that
> control it. The option should remain visibly on unless the user turns it
> off, even if saving commands in the histo
On 6/11/19 9:38 AM, _...@crans.org wrote:
> Chet Ramey wrote (2019-06-10 15:22):
>> On 6/8/19 3:41 PM, _...@crans.org wrote:
>>>
>>> What makes me think it is an actual bug is that when the
>>> "history" option was already enabled, "set -o history" should
>>> have no effect; yet lines b
Chet Ramey wrote (2019-06-10 15:22):
> On 6/8/19 3:41 PM, _...@crans.org wrote:
>>
>> What makes me think it is an actual bug is that when the
>> "history" option was already enabled, "set -o history" should
>> have no effect; yet lines before are not recorded, and lines
>> afte
On 6/8/19 3:41 PM, _...@crans.org wrote:
> Bash Version: 5.0
> Patch Level: 7
> Release Status: release
>
> Description:
> When `eval` runs "set -o history", subsequent lines in the
> eval-ed string are recorded in the history.
Yes. History doesn't require an interactive shell to wor
On 12/23/18 7:42 PM, Martijn Dekker wrote:
> Op 14-12-18 om 14:29 schreef Chet Ramey:
>> On 12/14/18 6:46 AM, Martijn Dekker wrote:
>>> In current git, 'bash -o posix' no longer exits the shell on a syntax error
>>> in the argument to the special builtin 'eval'. Bash 4.2-4.4 exit as POSIX
>>> speci
Op 14-12-18 om 14:29 schreef Chet Ramey:
On 12/14/18 6:46 AM, Martijn Dekker wrote:
In current git, 'bash -o posix' no longer exits the shell on a syntax error
in the argument to the special builtin 'eval'. Bash 4.2-4.4 exit as POSIX
specifies.
Well, not quite. It's the specific case of an une
On 12/14/18 6:46 AM, Martijn Dekker wrote:
> In current git, 'bash -o posix' no longer exits the shell on a syntax error
> in the argument to the special builtin 'eval'. Bash 4.2-4.4 exit as POSIX
> specifies.
Well, not quite. It's the specific case of an unexpected end of file. ksh93
doesn't exit
On 9/29/15 11:48 AM, 紫云飞 wrote:
> $ eval '\'
> exit
>
> I am wondering if this is a bug or intentional behavior.
It's a bug in bash-4.3, already fixed for the next release.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocra
On Wed, May 27, 2015 at 12:59:53AM -0700, Dave Yost wrote:
> OK, I can make it to work in bash if I say
> echodo a=b\\ c
> but then zsh tries to execute c. Can’t win.
>
> The problem is: how do I write this function so that it can be invoked
> identically in zsh and bash with identical results
OK, I can make it to work in bash if I say
echodo a=b\\ c
but then zsh tries to execute c. Can’t win.
The problem is: how do I write this function so that it can be invoked
identically in zsh and bash with identical results of setting a variable to a
value with a space in it?
> On 2015-05-26,
On Mon, May 25, 2015 at 12:33:53PM -0700, d...@yost.com wrote:
> # Echo the arguments, then execute them as a command.
> I can't find a way to implement echodo in bash.
set -x
your code
set +x
d...@yost.com writes:
> eval$@
You are expanding a shell parameter unquoted. Never do that unless you
know what you are doing.
eval "$@"
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for s
Dennis Williamson wrote:
I'm trying to put a command in a variable, but the complex cases always
fail! : http://mywiki.wooledge.org/BashFAQ/050
Eval command and security issues : http://mywiki.wooledge.org/BashFAQ/048
Dunno, but I see nothing on that page about using
printf -v "%q" or
I'm trying to put a command in a variable, but the complex cases always
fail! : http://mywiki.wooledge.org/BashFAQ/050
Eval command and security issues : http://mywiki.wooledge.org/BashFAQ/048
On Mon, May 25, 2015 at 2:33 PM, wrote:
> Configuration Information [Automatically generated, do not c
d...@yost.com wrote:
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLO
On 25/05/15 20:33, d...@yost.com wrote:
> if [[ -n $ZSH_VERSION ]] ; then
> echo "[ ${(q)@} ]"
> eval${(q)@}
> else
> echo "[ $@ ]"
> eval$@
> fi
I believe the bash equivalent here would be something along the lines of:
quoted=$(printf '%q ' "$@")
quoted=${quoted% }
e
On 2/13/13 12:44 PM, Matei David wrote:
> Another thing I tried was to open a fd with <() and use it later in a shell
> function. Surprisingly, the fd disappears (is closed) if the shell executes
> something unrelated in subshell:
This was reported a while back
http://lists.gnu.org/archive/html/b
Another thing I tried was to open a fd with <() and use it later in a shell
function. Surprisingly, the fd disappears (is closed) if the shell executes
something unrelated in subshell:
$ bash -c 'xxx () { echo "got arg: $1" >&2; ls -gG /proc/$BASHPID/fd >&2;
(echo "subprocess" >&2); ls -gG /proc/$
Thank you for the explanation.
On Tue, Feb 12, 2013 at 8:32 PM, Chet Ramey wrote:
> On 2/12/13 11:40 AM, Pierre Gaston wrote:
> > On Tue, Feb 12, 2013 at 6:07 PM, Matei David
> wrote:
> >
> >> Ok, but I see the same behaviour when eval runs in a subshell:
> >>
> >> $ bash -c 'llfd () { echo "p
On 2/12/13 11:40 AM, Pierre Gaston wrote:
> On Tue, Feb 12, 2013 at 6:07 PM, Matei David wrote:
>
>> Ok, but I see the same behaviour when eval runs in a subshell:
>>
>> $ bash -c 'llfd () { echo "pid:$BASHPID" >&2; ls -l /proc/$BASHPID/fd/
>>> &2; }; x=3; eval "exec $x>/dev/null"; llfd; echo | e
On Tue, Feb 12, 2013 at 04:22:08PM -0500, Matei David wrote:
> Generally speaking, it took me quite some time to figure out how to
> properly create a "double pipe" without using any intermediate files or
> fifos. The concept is very easy: in -> tee -> two parallel, independent
> pipes -> join -> o
On 2/12/13 2:07 PM, Matei David wrote:
OK. Let me try this again. One key to the explanations is that child
processes inherit all of the parent's open file descriptors.
> ... there seem to be not 2 but 3(!) types of file descriptors:
> 1. fds which are copied across both subshells and exec; like
Hi Chet,
Conceptually, the availability of a single flag "close-on-exec" (BTW, is
there a way to check those flags in bash or using /proc?) should create
only 2, not 3 types of file descriptors- that's what I find confusing. Does
subprocess creation as in '(llfd)' entail an execve() call? My guess
On 2/12/13 2:07 PM, Matei David wrote:
> ... there seem to be not 2 but 3(!) types of file descriptors:
> 1. fds which are copied across both subshells and exec; like 4
> 2. fds which are not copied across subshells; like 60&63
> 3. fds which are copied across subshells, but not exec; like 10
>
>
So in other words, you're saying I should use '... | eval "exec $x>&-;
llfd"' instead of '... | eval "llfd $x>&-"'. This way the subshell won't be
assuming I might use $x later. That works, but I still find it
counterintuitive that with the original syntax the subshell doesn't realize
there's nothi
Wow, thanks, I didn't know that. So this syntax achieves a bit more than I
asked for- it allows you to get a new unused file descriptor, right? It
seems that the only useful way to use a non-closing form (>&-, <&-) is with
exec, as in 'exec {new_fd}>&2'. (Why would I want the fd in a variable
other
On Tue, Feb 12, 2013 at 6:07 PM, Matei David wrote:
> Ok, but I see the same behaviour when eval runs in a subshell:
>
> $ bash -c 'llfd () { echo "pid:$BASHPID" >&2; ls -l /proc/$BASHPID/fd/
> >&2; }; x=3; eval "exec $x>/dev/null"; llfd; echo | eval "llfd $x>&-"'
> [same output, fd 10 open, poin
On Tue, Feb 12, 2013 at 11:07:06AM -0500, Matei David wrote:
> On a different but related note, I hate having to do eval to manipulate an
> fd stored in a variable. Why doesn't 'llfd $x>&-' work, especially since
> 'llfd >&$x' works just fine... so by the time >& is handled, the variable
> substitu
Ok, but I see the same behaviour when eval runs in a subshell:
$ bash -c 'llfd () { echo "pid:$BASHPID" >&2; ls -l /proc/$BASHPID/fd/ >&2;
}; x=3; eval "exec $x>/dev/null"; llfd; echo | eval "llfd $x>&-"'
[same output, fd 10 open, pointing to /dev/null, even though it's a
subshell]
$ bash -c 'llf
On Tue, Feb 12, 2013 at 1:54 AM, wrote:
> With the script below, I'd expect any fd pointing to /dev/null to be
> closed when the second llfd() is executed. Surprisingly, fd 3 is closed,
> but fd 10 is now open, pointing to /dev/null, as if eval copied it instead
> of closing it. Is this a bug?
>
On 5/5/11 6:29 PM, Sven Mascheck wrote:
> 4.4BSD alpha '92 suddenly documented it,
> "...braces, which are optional except for positional parameters
> with more than one digit..."
> http://www.in-ulm.de/~mascheck/various/ash/44bsdalpha.1.html
> but interestingly had not implemented a
On Wed, May 04, 2011 at 03:40:01PM -0500, Rafael Fernandez wrote:
> [...] I am used to the behavior of sh on NetBSD which does not require
> enclosing positional parameters. I believe it is adequately expressed in the
> manual page,
The NetBSD manpage documents it as usually implemented. I guess
On 5/5/11 10:45 AM, Eric Blake wrote:
> On 05/05/2011 08:43 AM, Chet Ramey wrote:
>>> "The parameter name or symbol can be enclosed in braces, which are
>>> optional except for positional parameters with more than one digit or
>>> when parameter is followed by a character that could be interpreted
On 05/05/2011 08:43 AM, Chet Ramey wrote:
>> "The parameter name or symbol can be enclosed in braces, which are
>> optional except for positional parameters with more than one digit or
>> when parameter is followed by a character that could be interpreted as
>> part of the name."
>
> I agree with
On 5/5/11 10:11 AM, Eric Blake wrote:
> Also a POSIX violation:
>
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02
>
> "The parameter name or symbol can be enclosed in braces, which are
> optional except for positional parameters with more than one digit or
[adding bug-autoconf to document a NetBSD bug]
On 05/05/2011 07:23 AM, Chet Ramey wrote:
> On 5/4/11 4:40 PM, Rafael Fernandez wrote:
>> I am used to the behavior of sh on NetBSD which does not require
>> enclosing positional parameters.
>
> I'd call that a pretty serious incompatibility on the
On 5/4/11 4:40 PM, Rafael Fernandez wrote:
> I am used to the behavior of sh on NetBSD which does not require
> enclosing positional parameters.
I'd call that a pretty serious incompatibility on the part of ash and its
descendants (BSD sh, dash, etc.). There's no good reason that
set -- a b c d
I appreciate the links and information. I prematurely assumed it was a bug
as I am used to the behavior of sh on NetBSD which does not require
enclosing positional parameters. I believe it is adequately expressed in the
manual page, I just need to improve my reading comprehension. Thanks.
On Wed,
Thanks, I wasn't aware that positional parameters greater than nine have to
be enclosed in brackets.
On Tue, May 3, 2011 at 10:17 PM, DJ Mills wrote:
>
>
> On Tue, May 3, 2011 at 10:41 PM, Jonathan Nieder wrote:
>
>> Hi Rafael,
>>
>> Rafael Fernandez wrote:
>>
>> > set -- a b c d e f g h
On Tue, May 03, 2011 at 09:41:28PM -0500, Jonathan Nieder wrote:
> Rafael Fernandez wrote:
> > set -- a b c d e f g h i j k l m n o p q r s t u v w x y z
> > i=1
> > eval echo '$'$i # outputs an expected 'a'
I didn't see the original question yet, but it looks like
Jonathan Nieder writes:
> For the future, the sh specification at
> http://www.unix.org/2008edition/ (free registration required)
http://pubs.opengroup.org/onlinepubs/9699919799/
(no registration required)
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53
Rafael Fernandez wrote:
> Thanks, I wasn't aware that positional parameters greater than nine have to
> be enclosed in brackets.
No prob. The manpage says
When a positional parameter consisting of more than a single
digit is expanded, it must be enclosed in braces (see
E
On Tue, May 3, 2011 at 10:41 PM, Jonathan Nieder wrote:
> Hi Rafael,
>
> Rafael Fernandez wrote:
>
> > set -- a b c d e f g h i j k l m n o p q r s t u v w x y z
> > i=1
> > eval echo '$'$i # outputs an expected 'a'
> > i=10
> > eval echo '$'$i
Hi Rafael,
Rafael Fernandez wrote:
> set -- a b c d e f g h i j k l m n o p q r s t u v w x y z
> i=1
> eval echo '$'$i # outputs an expected 'a'
> i=10
> eval echo '$'$i # outputs 'a0'; expected 'j'
> i=11
> eval echo '$'$i
[EMAIL PROTECTED] wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
> -DCONF_VENDOR='u
antonio wrote:
#!/bin/bash
a=( 1 2 3 )
b=( 4 5 6 )
x=a
eval b=( [EMAIL PROTECTED] )
echo [EMAIL PROTECTED]
#output:
#1 2 3
x=b
eval $x=( [EMAIL PROTECTED] )
#output:
#./tst: line 15: syntax error near unexpected token `('
#./tst: line 15: `eval $x=( [EMAIL PROTECTED] ) '
Strictly speaking
On Mon, Feb 13, 2006 at 04:19:42PM +0100, [EMAIL PROTECTED] wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: sparc
> OS: solaris2.8
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='sparc'
> -DCONF_OSTYPE='solaris2.8' -DCONF_MACHTYPE='s
> Machine Type: sparc-sun-solaris2.8
>
> Bash Version: 3.1
> Patch Level: 0
> Release Status: release
>
> Description:
> Normally, the eval builtin used in functions to set variables
> makes these variables available globally otutside the function.
> However, when the function g
[EMAIL PROTECTED] wrote:
> Normally, the eval builtin used in functions to set variables
> makes these variables available globally otutside the function.
> However, when the function gets input from a pipline, the variables
> are set only locally.
Read the bash FAQ, entry
> Machine Type: sparc-sun-solaris2.8
>
> Bash Version: 3.1
> Patch Level: 0
> Release Status: release
>
> Description:
> Assigning arrays using
> testvar=( $(echo A) $(echo B) )
> is accepted in bash-3.1.0. However, using the
> same in an eval-construct
>
60 matches
Mail list logo
