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 con
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 '<$[|]&#
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
r: gcc
Compilation CFLAGS: -g -O2
uname output: Linux 839141c7e5ba 6.8.0-40-generic #40~22.04.3-Ubuntu SMP
PREEMPT_DYNAMIC Tue Jul 30 17:30:19 UTC 2 x86_64 Linux
Machine Type: x86_64-pc-linux-musl
Bash Version: 5.3
Patch Level: 0
Release Status: alpha
POC:
$ cat poc.sh
eval '<${;}'
can create a Segmentation Fault
eval '<$[;]'
eval '<${;}'
eval '<$[|]'
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 th
tation Fault
>
> eval '<$[;]'
> eval '<${;}'
> eval '<$[|]'
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
From: Youheng Lü
To: bug-bash@gnu.org
Subject: eval '<$(;)' causes Segmentation Fault
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -flto=auto
-ffa
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
>
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 '`' is still waiting for some input?
On 10/12/22 10:25 AM, Chet Ramey wrote:
Then run this test script with 'errexit' option set:
$ ./bash -e test_script
test_script: line 5: pop_var_context: head of shell_variables not
a function context
It's an internal message warning that something might be wrong. We'll see
if
On 10/12/22 12:58 AM, Xavier Delaruelle wrote:
Bash Version: 5.2
Patch Level: 2
Release Status: release
Description:
Starting version 5.2, when evaluating bash code (with eval builtin
command) with 'errexit' option set, a pop_var_context message appears
if the evaluating code l
isting features, why add one more?
>
>
> > [...] With your syntax you still have to be aware of what's
> > in that trap [...]
> >
>
> Not really. If, for some reason, I didn't know what's in that trap and were
> super paranoiac about it, I could do
&g
-linux-gnu
Bash Version: 5.2
Patch Level: 2
Release Status: release
Description:
Starting version 5.2, when evaluating bash code (with eval builtin
command) with 'errexit' option set, a pop_var_context message appears
if the evaluating code leads to an error:
test_scri
o miss that next
thing that isn't `defer` as it comes up.
> > I'm not saying
> > defer necessarily meets the same bar as usefulness, but I think it'd
> > be wrong to dismiss new features just because they can be accomplished
> > today, with relatively few lines.
>
ing
> defer necessarily meets the same bar as usefulness, but I think it'd
> be wrong to dismiss new features just because they can be accomplished
> today, with relatively few lines.
In my point of view, the suggested "new" feature is *already
implemented in Bash as th
to be aware of what's
> in that trap [...]
>
Not really. If, for some reason, I didn't know what's in that trap and were
super paranoiac about it, I could do
oldaction=$(trap -P EXIT)
trap 'eval "$oldaction"; bar' EXIT
I've never been in su
with relatively few lines. If we find something lots of people
are doing, it might be worth discussing adding it in (and again: I'm
totally willing to admit defer/defer-like might not meet that bar)!
> Could you describe it in more detail or could you provide an example
> of how this can
Hi Lawrence,
2022年10月8日(土) 16:04 Lawrence Velázquez :
> On Sat, Oct 8, 2022, at 2:11 AM, Koichi Murase wrote:
> > [...]. One thing to note is that the RETURN trap
> > should be cleaned up inside the RETURN trap itself by running `trap -
> > RETURN', or otherwise the RETURN trap is erroneously cons
Let me update the example implementation of ``defer''. I think this is
more readable:
function defer {
local trap
eval "trap=($(trap -p RETURN))"
trap -- "
if [[ \$FUNCNAME != defer ]]; then
trap - RETURN
$1
${trap[2]-}
fi" RETURN
}
de
util.hook.sh#L42-L61
> (yours
> in particular can mess up with certain quoting rules, but is nothing a
> quick sed can't fix).
Could you describe it in more detail or could you provide an example
of how this can mess up? For example, the quoting of the trap string
in the output of `tr
On Sat, Oct 8, 2022, at 2:11 AM, Koichi Murase wrote:
> 2022年10月8日(土) 12:04 Cynthia Coan :
>> [...]
>>
>> Otherwise, I think we can perhaps reword this into two smaller
>> features: "function local trap signals",
>
> The existing RETURN trap is exactly the trap that can be used to clean
> up resour
> I don't think this would be a feature worth the time to implement and
> the complexity it would introduce. Is there any other use case for this
> than cleaning up temporary files on function return?
Yeah! I think that's a fair point since it seems like we're landing on
traps being the way forwar
, be careful that the function
> needs to be marked with the trace attribute by ``declare -ft
> ''. Also, the RETURN trap needs to be suppressed for
> such a function itself. I haven't really tested it but something like
> this should work as you expect:
>
&g
to perform that. In that case, be careful that the function
needs to be marked with the trace attribute by ``declare -ft
''. Also, the RETURN trap needs to be suppressed for
such a function itself. I haven't really tested it but something like
this should work as you expect:
function
On 10/8/22 6:03 AM, Cynthia Coan wrote:
Otherwise, I think we can perhaps reword this into two smaller
features: "function local trap signals", and
I don't think this would be a feature worth the time to implement and
the complexity it would introduce. Is there any other use case for this
than
I definitely got the inspiration of the name from the Go programming
language. There are several other languages who use similar concepts
when dealing with cleanup where something like an RAII pattern to free
resources.
It sounds like we're leaning towards trap, over a new built-in which I
think i
The Go programming language has a "defer" statement which is used
considerably for exactly this purpose. So we know that it's useful in
practice. The question remains what is a good way to introduce it into
Bash.
As others have noted, there is already a "trap" with similar
functionality. I'm no
e" with the
existing practices. I still think defer might be more simple, but that
is just my opinion! I think both are totally workable.
- Cynthia
On Thu, Oct 6, 2022 at 4:05 PM Lawrence Velázquez wrote:
>
> On Thu, Oct 6, 2022, at 4:08 PM, Cynthia Coan wrote:
> > I'd specific
On Thu, Oct 6, 2022, at 4:08 PM, Cynthia Coan wrote:
> I'd specifically like to propose a new built-in called `defer` which
> acts like `eval` however is not parsed/expanded/run until it's scope
> is leaving. Hopefully "scope" is the correct word, I'm imagini
Hey all,
I've started working on this idea, and before getting too far I'd like
to get general feedback on the feature before going too far. I'd
specifically like to propose a new built-in called `defer` which acts
like `eval` however is not parsed/expanded/run until it
On 9/22/21 2:27 PM, dfsm...@us.ibm.com wrote:
Bash Version: 5.0
Patch Level: 3
Release Status: release
Description:
When running commands through eval, the script's line counter
is incremented, even though the eval line is fixed.
Thanks for the report. This is a trick
output: Linux porter 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2
(2020-11-28) x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.0
Patch Level: 3
Release Status: release
Description:
When running commands through eval, the script's line counter
is incremented,
On 8/27/20 8:33 PM, Koichi Murase wrote:
> Bash Version: 5.1
> Patch Level: 0
> Release Status: release
>
> Description:
>
> When a command string with an incomplete construct is supplied to
> the `eval' builtin in interactive sessions, the process will be
&
-linux-gnu
Bash Version: 5.1
Patch Level: 0
Release Status: release
Description:
When a command string with an incomplete construct is supplied to
the `eval' builtin in interactive sessions, the process will be
terminated. This does not happen before Bash 5.0. This does not
happen i
On 7/15/19 6:19 PM, astian wrote:
>> I doubt it makes any difference to the timing, which I think
>> Chet has already answered, but it is worth pointing out that these
>> two commands ...
>>
>> printf '%s\n' "`printf %s "$i"`"
>> printf '%s\n' "$(printf %s
On Jul 16 2019, Ilkka Virta wrote:
> On 15.7. 20:49, Robert Elz wrote:
>
>> printf '%s\n' "`printf %s "$i"`"
>> printf '%s\n' "$(printf %s "$i")"
>>
>> aren't actually the same. In the first $i is unquoted, in the second it is
>> quoted.
>
> Huh, rea
On 15.7. 20:49, Robert Elz wrote:
printf '%s\n' "`printf %s "$i"`"
printf '%s\n' "$(printf %s "$i")"
aren't actually the same. In the first $i is unquoted, in the second it is
quoted.
Huh, really? It looks to me like the first one treats $i
Robert Elz:
> Date:Wed, 10 Jul 2019 17:21:00 +
> From:astian
> Message-ID:
>
> I doubt it makes any difference to the timing, which I think
> Chet has already answered, but it is worth pointing out that these
> two commands ...
>
> printf '
Date:Wed, 10 Jul 2019 17:21:00 +
From:astian
Message-ID:
I doubt it makes any difference to the timing, which I think
Chet has already answered, but it is worth pointing out that these
two commands ...
printf '%s\n' "`printf %s "$i"`"
On 7/13/19 1:36 PM, astian wrote:
> Chet Ramey:
>>> - $() seems generally slightly slower than ``, but becomes
>>> pathologically
>>> so when preceded with "eval set -- ...".
>>
>> It is slightly slower -- POSIX requires that the she
(probably not very useful, feel
free to ignore them).
Chet Ramey:
>> - $() seems generally slightly slower than ``, but becomes pathologically
>> so when preceded with "eval set -- ...".
>
> It is slightly slower -- POSIX requires that the shell parse
On 7/10/19 1:21 PM, astian wrote:
> Bash Version: 5.0
> Patch Level: 3
> Release Status: release
>
> Description:
>
> I discovered a curious performance degradation in the combined usage of the
> constructs "eval set -- ..." and new-style command substi
: Linux $nodename 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u2
(2019-05-13) x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.0
Patch Level: 3
Release Status: release
Description:
I discovered a curious performance degradation in the combined usage of the
constructs "eva
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
o history" should
>>> have no effect; yet lines before are not recorded, and lines
>>> after are recorded.
>>
>> Bash temporarily stops recording commands in the history when you use
>> `eval', but if you turn history back on explicitly using `set
t; yet lines before are not recorded, and lines
>> after are recorded.
>
> Bash temporarily stops recording commands in the history when you use
> `eval', but if you turn history back on explicitly using `set -o history',
> it will honor that.
In that case, shouldn’t `eva
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&#x
rsion: 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.
This breaks the following coding pattern:
saved_options="$(set +o)" #
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 built
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'
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
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.
$ bash -o posix -c 'eval "(" || echo woops'
bash: eval: regel 1: syntaxfout: onverwacht best
On 4/13/18 11:29 PM, Martijn Dekker wrote:
> Op 14-04-18 om 03:49 schreef Chet Ramey:
>> On 4/10/18 5:56 AM, Martijn Dekker wrote:
>>> It seems odd that the RETURN trap would be triggered while a RETURN trap
>>> action is still being executed. Might it be better to temporarily
>>> deactivate the ef
Op 14-04-18 om 03:49 schreef Chet Ramey:
On 4/10/18 5:56 AM, Martijn Dekker wrote:
It seems odd that the RETURN trap would be triggered while a RETURN trap
action is still being executed. Might it be better to temporarily
deactivate the effect of '-o functrace' while a RETURN trap action is bein
On 4/10/18 5:56 AM, Martijn Dekker wrote:
> $ bash -o functrace -c 'fn() { eval "return"; }; trap "fn" RETURN; fn'
>
> Result: segfault due to infinite recursion.
Thanks for the report; I'll fix this.
______
>
> Even apart from this b
$ bash -o functrace -c 'fn() { eval "return"; }; trap "fn" RETURN; fn'
Result: segfault due to infinite recursion.
__
Even apart from this bug with 'eval return', the effect of '-o
functrace' is a bit strange:
$ bash -o functrace -c
On 6/18/17 8:06 PM, Martijn Dekker wrote:
> (eval '(');echo $?
Thanks for the report. The parse error followed by EOF needs to call
YYABORT when the shell isn't reading input interactively.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
bash-snap-20170616
$ (eval '(');echo $?
bash: eval: line 2: syntax error: unexpected end of file
0
The exit status is 0, but should be 1.
As far as I can trace it, this bug seems to have been introduced in
bash-20170511 snapshot.
- M.
On 3/19/17 10:58 PM, Martijn Dekker wrote:
> Test script:
> printf "$LINENO "
> printf "$LINENO "
> eval 'printf "$LINENO "
> printf "$LINENO "
> printf "$LINENO " '
> printf "$LINENO\n"
Test script:
printf "$LINENO "
printf "$LINENO "
eval ' printf "$LINENO "
printf "$LINENO "
printf "$LINENO " '
printf "$LINENO\n"
Output on various shells:
bash: 1 2 5 6 7 6 (?!)
{m,l,pd}ksh
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
$ eval '\'
exit
I am wondering if this is a bug or intentional behavior.
identical results of setting a variable to a
> value with a space in it?
dualbus@hp ~ % for sh in bash zsh; do "$sh" -c 'echodo(){ echo "$*"; eval "$@";
}; echodo a=b\\ c; echo "$a"'; done
a=b\ c
b c
a=b\ c
b c
--
Eduardo Bustamante
https://dualbus.me/
-26, at 1:04 AM, Andreas Schwab wrote:
>
> d...@yost.com writes:
>
>>eval$@
>
> You are expanding a shell parameter unquoted. Never do that unless you
> know what you are doing.
>
> eval "$@"
>
> Andreas.
>
> --
> Andre
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
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 -
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
64 #1 SMP Wed
Apr 22 06:48:29 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.3
Patch Level: 39
Release Status: release
Description:
# Echo the arguments, then execute them as a command.
function echodo() {
if [[ -n $ZSH_VERSION ]] ; then
ec
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:
qu
9 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.3
Patch Level: 39
Release Status: release
Description:
# Echo the arguments, then execute them as a command.
function echodo() {
if [[ -n $ZSH_VERSION ]] ; then
echo "[ ${(q)@} ]"
d the message as
> spam,
> but if not, please accept my appoligies for the dup.
>
> \ is supposed to be effectively ignored, but if it appears at
> the
> end of the script then parse errors sometimes occur with previous
> statements.
> In partic
_64-unknown-linux-gnu
Bash Version: 4.3
Patch Level: 0
Release Status: release
Description:
A \ is supposed to be ignored, but if it occurs at the very end of the
input then it causes a prior eval containing an array assignment to be
mis-parsed.
However if the eval contains something other th
for the dup.
\ is supposed to be effectively ignored, but if it appears at
the
end of the script then parse errors sometimes occur with previous
statements.
In particular eval "array=(values...)" is mis-parsed if a subsequent
statement
ends with and there is n
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
et 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 (
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:
> >
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/
>&g
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 th
hy would I want the fd in a variable
otherwise.)
Too bad the "natural" syntax 'llfd $x>&-' doesn't work, but I guess this
will do.
On Tue, Feb 12, 2013 at 11:12 AM, Greg Wooledge wrote:
> On Tue, Feb 12, 2013 at 11:07:06AM -0500, Matei David wrote:
> > On a d
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
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 fi
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
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
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?
Thanks,
M
$ bash -c 'llfd () { l
On 8/10/12 3:05 AM, Clark WANG wrote:
> For quite a long time I don't know why my bash stops remembering command
> history. I just figured out it was caused by some code like `eval return'
> in the .bashrc/.bash_profile.
Thanks for the report. As you suspected, the combination
For quite a long time I don't know why my bash stops remembering command
history. I just figured out it was caused by some code like `eval return'
in the .bashrc/.bash_profile.
Steps to reproduce (tested with 3.2.25, 4.0.28, 4.1.11 and 4.2.29):
$ cp .bashrc .bashrc.old
$ echo e
Linda Walsh writes:
> - YESTERDAY=$(date -r $((`date +%s` - 86400 )) +%d/%m/%Y
This fails around autumn DST transition (assuming s/-r /-d @/).
YESTERDAY=$(date -d '12:00 yesterday' +%d/%m/%Y)
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756
Greg Wooledge wrote:
On Wed, Apr 11, 2012 at 02:34:01AM -0700, Linda Walsh wrote:
- for ((vl=$((v_level - 1)); $vl > 0; --vl))
The inside of the for ((...)) is already a math context. You don't need
another $((...)) inside it.
for ((vl = v_level - 1; vl > 0; --vl))
Or is that another "ir
On Wed, Apr 11, 2012 at 02:34:01AM -0700, Linda Walsh wrote:
> - for ((vl=$((v_level - 1)); $vl > 0; --vl))
The inside of the for ((...)) is already a math context. You don't need
another $((...)) inside it.
for ((vl = v_level - 1; vl > 0; --vl))
Or is that another "irrelevant detail"?
Chet Ramey wrote:
On 4/9/12 9:07 PM, Linda Walsh wrote:
** linux-kernel -- all over the place...
At that point, I was getting too many to keep up with ... so I stopped
searching...
$[] has is -- I would bet, Universally, used MORE than $(())...
I believe you'd lose, but it's unprovable e
On 4/10/12 12:22 AM, Elliott Forney wrote:
> My two cents, would be to add a bit to the man page that says something like:
>
> ---
> For historical reasons, the following format is also supported for
> arithmetic evaluation:
>
> $[expression]
>
> Note, however, that this format is non-standa
On 4/10/12 3:33 AM, Maarten Billemont wrote:
> If we were to move to $[ ... ]
But we're not. It's ludicrous to think we would. How far down the rabbit
hole are we going to go on this?
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' -
1 - 100 of 191 matches
Mail list logo
