On Thu, 07 Sep 2023 05:50:49 -0700
hacke...@member.fsf.org wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat
> -Werror=format-security -Wall
> uname output:
> On Jul 13, 2021, at 4:37 PM, Paul Gilmartin wrote:
>
> Description:
> When "word" in here-document contains command substitution,
> bash reports an error:
> here: line 4: warning: here-document at line 2 delimited by end-of-file
> (wanted `foo$( true )bar')
> Man bash shows:
Eli Schwartz writes:
> Perhaps you meant to say "executes the same command process" instead of
> "has the same effect"?
Ah, yes, that's what I meant, "Executes the same command with the same
arguments, regardless of what the output of command2 is."
Dale
On Tue, Jun 02, 2020 at 09:44:45PM -0400, Dale R. Worley wrote:
> Naively, I expect that
> FOO="$( command2 )"
> command1 "$FOO"
>
> has the same effect as
>
> command1 "$( command2 )"
>
> Has anyone pushed the boundaries of this and can tell me whether there
> are gotchas?
The mai
> On Jun 3, 2020, at 3:18 AM, Martin Schulte
> wrote:
>
>> Unfortunely, I don't retrieve this behaviour in man page.
>
> Me neither, maybe the manual should read
>
> If the substitution appears within double quotes *or as the right-hand
> side of an variable assignment*, word splitting and file
Hello Felix!
> Quoting is useless when assigning variable from ouptut of command or
> another variable:
Yes, I assume you are right.
> Unfortunely, I don't retrieve this behaviour in man page.
Me neither, maybe the manual should read
If the substitution appears within double quotes *or as the
Quoting is useless when assigning variable from ouptut of command or
another variable:
$ foo=1 2 3 4
bash: 2: command not found
Ok. But
$ foo=$(seq 1 3)
$ declare -p foo
declare -- foo="1
2
3"
$ foo="$(seq 1 3)"
$ declare -p foo
declare -- foo="1
2
On 6/2/20 9:44 PM, Dale R. Worley wrote:
> Naively, I expect that
>
> FOO="$( command2 )"
> command1 $FOO
>
> has the same effect as
>
> command1 $( command2 )
>
> and
>
> FOO="$( command2 )"
> command1 "$FOO"
>
> has the same effect as
>
> command1 "$( command2 )"
>
I see. Thank you for your answers.
Best regards,
Krystian Wojtas
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
środa, kwiecień 1, 2020 8:20 PM, Chet Ramey napisał(a):
> On 4/1/20 1:47 PM, Andreas Schwab wrote:
>
> > On Apr 01 2020, Krystian Wojtas via Bug reports for the
On 4/1/20 1:47 PM, Andreas Schwab wrote:
> On Apr 01 2020, Krystian Wojtas via Bug reports for the GNU Bourne Again
> SHell wrote:
>
>> Making comments in pipes using command substitution is very helpful.
>> But there is syntax error it it is done just before while loop. Could it be
>>
On Apr 01 2020, Krystian Wojtas via Bug reports for the GNU Bourne Again SHell
wrote:
> Making comments in pipes using command substitution is very helpful.
> But there is syntax error it it is done just before while loop. Could it be
> considered as bug?
Not a bug. Reserved words are
On 11/15/17 5:13 AM, Stephane Chazelas wrote:
> I also noticed that cmd was not run in ${x#`cmd`} if x happens
> to be empty (it's also the case in dash and ksh93 though only if
> x is unset; zsh, mksh and yash are fine)
It looks like bash/dash/ksh93 give more weight to the "If word is not
needed
On 11/15/17 5:13 AM, Stephane Chazelas wrote:
> Hello,
>
> $ bash -c 'for ((i = 0; $(echo 0); i++)); do echo x; done'
>
> (OK)
>
> $ bash -c 'for ((i = 0; ${x-`echo 0`}; i++)); do echo x; done'
>
> (OK)
>
> $ bash -c 'for ((i = 0; ${x-$(echo 0)}; i++)); do echo x; done'
> bash: -c: line 0: syn
On 12/2/16 6:23 AM, parasite parasite wrote:
> GNU bash, version 4.3.46(1)-release (x86_64-unknown-linux-gnu)
> GCC: (GNU) 6.1.1
> On archlinux 4.4.27-1-lts
>
> Hello, today i tried something simple but it leads to what seems to be a bug.
>
> $ var="$(for ((i=0;i<$#;i++));do echo line;done)"
> le
On Wed, Oct 05, 2016 at 09:20:58AM -0400, Chet Ramey wrote:
> Try the attached patch, which reduces the number of warnings to 1 per call
> to command substitution.
I don't agree with this approach -- I think you should be able to turn
off the warning completely, so I am not interested in testing t
On 9/16/16 1:51 AM, Eric Pruitt wrote:
> Bash Version: 4.4
> Patch Level: 0
> Release Status: release
>
> Description:
> I have a script that execute `if [[ "$(<"/proc/$1/cmdline")" = tmux*
> ]];`.
> All /proc/*/cmdline include null bytes, and as of Bash 4.4, this
> results in
>
On 9/29/16 11:49 PM, Martijn Dekker wrote:
> I detected an oddity (possible bug) in bash: the usual optimisation for
> launching external processes in simple command substitutions is turned
> off while executing a dot script.
Thanks for the suggestion. I added the optimization to command
substitu
On 9/29/16 11:49 PM, Martijn Dekker wrote:
> I detected an oddity (possible bug) in bash: the usual optimisation for
> launching external processes in simple command substitutions is turned
> off while executing a dot script.
>
> Background: For reasons that would take too much space to explain he
2016-09-30 04:49:33 +0100, Martijn Dekker:
[...]
> my_subshell_pid=$(sh -c 'echo $PPID')
>
> This works fine on every shell, except on bash when a dot script is
> being executed.
[...]
While it does look like a bug, you could always do:
my_subshell_pid=$(exec sh -c 'echo $PPID')
To be sur
The script is 5 years old. I don't remember any of the
design decisions that went in to it -- so you wanna pick it apart, go
ahead. I am already quite able to do so myself on stuff I wrote
even 3 years ago, often, so 5 years, hey, go for it.
I wasn't even using aliases to help my coding back th
On Tue, Sep 20, 2016 at 12:17:37PM -0700, L. A. Walsh wrote:
> /sys/class/net/br0> /tmp/showvals
> addr_assign_type: 1
> addr_len: 6
> address: 00:15:17:bf:be:b2
> /tmp/showvals: line 63: printf: `invalid format character
> brforward:
Ooops -- that script does try to run w/sudo.. forgot about that...
Like I said, fast & dirty
Greg Wooledge wrote:
I probably shouldn't even bother at this point, but morbid curiosity
compels me to foolish ends.
What are you DOING with these files that contain NUL bytes that makes
it permissible to simply drop the NUL bytes on the floor, with no
explicit step like tr -d \\0 to remove t
I probably shouldn't even bother at this point, but morbid curiosity
compels me to foolish ends.
What are you DOING with these files that contain NUL bytes that makes
it permissible to simply drop the NUL bytes on the floor, with no
explicit step like tr -d \\0 to remove them?
How is your script
Chet Ramey wrote:
Don't assume that every use of something like this has to do with /proc.
Here's a representative report:
"I was wondering what would happen if I'd do something like that:
$ foo="$(cat file_containing_ascii_null_byte)"
or faster
$ foo="$(http://www.gnu.org/software/bash/manual
On 9/19/16 12:28 PM, L. A. Walsh wrote:
>
>
> Chet Ramey wrote:
>> On 9/16/16 1:51 AM, Eric Pruitt wrote:
>>
>>
>>> Bash Version: 4.4
>>> Patch Level: 0
>>> Release Status: release
>>>
>>> Description:
>>> I have a script that execute `if [[ "$(<"/proc/$1/cmdline")" = tmux*
>>> ]];`.
>>>
On Mon, Sep 19, 2016 at 01:10:56PM -0700, L. A. Walsh wrote:
> Does readarray allow specifying the nulls as line-terminators?
Yes, as of bash 4.4.
Chet Ramey wrote:
On 9/19/16 2:41 PM, Greg Wooledge wrote:
Bash has only three choices that I can think of: it can silently drop the
NUL bytes (4.3 behavior), it can drop ALL of the bytes and return an
error, or it can drop the NUL bytes with a warning (4.4 behavior).
There is a fou
On 9/19/16 2:41 PM, Greg Wooledge wrote:
> Bash has only three choices that I can think of: it can silently drop the
> NUL bytes (4.3 behavior), it can drop ALL of the bytes and return an
> error, or it can drop the NUL bytes with a warning (4.4 behavior).
There is a fourth choice: terminate the
Greg Wooledge wrote:
Bash has only three choices that I can think of: it can silently drop the
NUL bytes behavior), it can drop ALL of the bytes and return an
error, or it can drop the NUL bytes with a warning (4.4 behavior).
now who is being disingenuous? It was silent not just in 4.3, b
On Mon, Sep 19, 2016 at 11:30:56AM -0700, Linda Walsh wrote:
> How about, w/r/t the new warning -- I complain because the null bytes
> are missing after bash knowingly detected them and illegally modified
> the input. Putting out a warning about null bytes, doesn't mean it's
> "ok" to drop them.
Eric Blake wrote:
On 09/19/2016 11:58 AM, Greg Wooledge wrote:
wooledg@wooledg:~$ x=$(< /proc/$$/cmdline)
bash-4.4: warning: command substitution: ignored null byte in input
wooledg@wooledg:~$ x=$(< /proc/$$/cmdline 2>/dev/null)
wooledg@wooledg:~$
Or:
$ x=$(< /proc/$$/cmdline tr -d
On 09/19/2016 11:58 AM, Greg Wooledge wrote:
> On Mon, Sep 19, 2016 at 09:28:53AM -0700, L. A. Walsh wrote:
>>If users were relying on this behavior (I know I have scripts that read
>> things from proc -- a text interface that uses \0 to display values similar
>> to MS's multi-string Values in
Greg Wooledge wrote:
On Mon, Sep 19, 2016 at 09:28:53AM -0700, L. A. Walsh wrote:
Could you change it back or provide a way to suppress "kiddy-scripter"
seatbelts?
wooledg@wooledg:~$ x=$(< /proc/$$/cmdline)
bash-4.4: warning: command substitution: ignored null byte in input
wooled
On Mon, Sep 19, 2016 at 09:28:53AM -0700, L. A. Walsh wrote:
>If users were relying on this behavior (I know I have scripts that read
> things from proc -- a text interface that uses \0 to display values similar
> to MS's multi-string Values in the Windows registry.
>Could you change it ba
Chet Ramey wrote:
On 9/16/16 1:51 AM, Eric Pruitt wrote:
Bash Version: 4.4
Patch Level: 0
Release Status: release
Description:
I have a script that execute `if [[ "$(<"/proc/$1/cmdline")" = tmux*
]];`.
All /proc/*/cmdline include null bytes, and as of Bash 4.4, this
resu
On 9/16/16 1:51 AM, Eric Pruitt wrote:
> Bash Version: 4.4
> Patch Level: 0
> Release Status: release
>
> Description:
> I have a script that execute `if [[ "$(<"/proc/$1/cmdline")" = tmux*
> ]];`.
> All /proc/*/cmdline include null bytes, and as of Bash 4.4, this
> results in
>
On Thu, Sep 15, 2016 at 10:51:22PM -0700, Eric Pruitt wrote:
> Fix:
> Is this even an intentional change? I looked at some of the other
> internal_warning invocations, and they were commented out using "#if 0
> ...
> #endif."
In 4.4-beta2, I see them in subst.c and parse.y and y
On 1/31/16 7:26 PM, Michael Diamond wrote:
> Bash Version: 4.3
> Patch Level: 39
> Release Status: release
>
> Description:
> I'm told $((( $exit_code == 0 )) && echo GREEN || echo RED) should fail
> to parse, because $(( should be the first token, not $(.
The way I read Posix, the bash behavior
On 10/13/15 2:04 AM, Christoph Gysin wrote:
> On Sat, Oct 10, 2015 at 8:24 PM, Chet Ramey wrote:
>> I will consider adding an option to change the behavior of command
>> substitution inheriting the -e option, since there doesn't seem to be
>> any way to decouple this behavior from posix mode.
>
>
On Sat, Oct 10, 2015 at 8:24 PM, Chet Ramey wrote:
> I will consider adding an option to change the behavior of command
> substitution inheriting the -e option, since there doesn't seem to be
> any way to decouple this behavior from posix mode.
I added a patch:
https://savannah.gnu.org/patch/inde
Chet Ramey wrote:
On 10/2/15 9:22 AM, Greg Wooledge wrote:
On Fri, Oct 02, 2015 at 03:53:42PM +0300, Christoph Gysin wrote:
I'm still curious as to why set -e is stripped in the first place?
Chet can give the definitive answer, but my take is that it's a huge
surprise to someone writing a fu
On 10/8/15 2:36 PM, Christoph Gysin wrote:
>> I think you're overlooking what I referred to above: that the exit status
>> of a command substitution doesn't have any effect on whether the parent's
>> command succeeds or fails except in one case: the right-hand-side of an
>> assignment statement tha
On Thu, Oct 08, 2015 at 09:36:59PM +0300, Christoph Gysin wrote:
> But this issue brings a new corner case:
>
> func() {
> cmd1
> cmd2
> }
>
> var=$(func)
>
> This won't work, because set -e is stripped inside the substitution,
> so the whole function runs without error checking.
> I know you don't want to hear this, but you really need to stop thinking
> of set -e as "error checking". It is an obsolescent historical anomaly
> that bash is required to support because POSIX specifies it. It isn't
> useful for any purpose, and people who insist on using it are simply
> caus
On 10/5/15 5:37 PM, Christoph Gysin wrote:
>> The parent shell (the one that enabled -e) should be the one to make the
>> decision about whether or not the shell exits. The exit status of the
>> command substitution doesn't make a difference except in one special case,
>> so inheriting errexit and
> I think you're overlooking what I referred to above: that the exit status
> of a command substitution doesn't have any effect on whether the parent's
> command succeeds or fails except in one case: the right-hand-side of an
> assignment statement that is the last assignment in a command consistin
> The parent shell (the one that enabled -e) should be the one to make the
> decision about whether or not the shell exits. The exit status of the
> command substitution doesn't make a difference except in one special case,
> so inheriting errexit and exiting (possibly prematurely) doesn't really
On 10/2/15 9:22 AM, Greg Wooledge wrote:
> On Fri, Oct 02, 2015 at 03:53:42PM +0300, Christoph Gysin wrote:
>> I'm still curious as to why set -e is stripped in the first place?
>
> Chet can give the definitive answer, but my take is that it's a huge
> surprise to someone writing a function indepe
> Chet can give the definitive answer, but my take is that it's a huge
> surprise to someone writing a function independent of the script, or
> using a function that was written independently of the script. If the
> function does not expect set -e to be in effect (which is not the default,
> and i
On Fri, Oct 02, 2015 at 03:53:42PM +0300, Christoph Gysin wrote:
> I'm still curious as to why set -e is stripped in the first place?
Chet can give the definitive answer, but my take is that it's a huge
surprise to someone writing a function independent of the script, or
using a function that was
> Since it's a function, I would recommend return instead of exit. Also,
> you don't need the $? there. exit (or return) with no arguments will
> retain the exit status of the previous command.
Yes, $? is not needed.
exit or return is equivalent in this case though because of set -e.
> Putting
On Fri, Oct 02, 2015 at 02:09:21PM +0300, Christoph Gysin wrote:
> Since set -e does not work, it means I have to postfix every command
> with "|| exit $?":
>
> f() {
> some command || exit $?
> more commands --with-args || exit $?
> }
>
> output=$(f)
Since it's a function, I would recommend
> Yes, it's how bash has always behaved, at least back to bash-1.14 when
> I stopped looking. Around bash-2.05, it changed to preserve the -e
> option when in Posix mode.
Is there any reason not to preserve it?
> That exception from default bash behavior is documented in the Posix
> Mode section
> Whether e disappears from $- may be unintended, but what IS documented
> is that there are contexts in which set -e has no effect, and when in
> one of those contexts, you cannot re-enable set -e. One such context is
> on the left side of && or ||. Even more non-intuitively, if you have a
> fun
On 10/1/15 6:24 AM, Christoph Gysin wrote:
> It seems that set -e is stripped from the options ($-) when executing
> commands with command substitution:
>
> $ bash -euc 'echo $-; f(){ false; echo $->&2; }; x=$(f)'
> ehuBc
> huBc
>
> I would expect the shell to exit as soon as it executes 'false'.
On 10/01/2015 04:24 AM, Christoph Gysin wrote:
> It seems that set -e is stripped from the options ($-) when executing
> commands with command substitution:
>
> $ bash -euc 'echo $-; f(){ false; echo $->&2; }; x=$(f)'
> ehuBc
> huBc
>
> I would expect the shell to exit as soon as it executes 'fal
On 8/2/14, 7:27 PM, EmanueL Czirai wrote:
> Repeat-By:
> 1. start a bash shell
> 2. put this in .bashrc
>
> PS1='$(date)\
> '
>
> put no spaces after \
> the entire thing is 2 lines - may add new line after ' though, and prior to
> PS1
>
> 3. start a new bash
> the error is:
> bash: command su
On Mon, Oct 07, 2013 at 11:58:48AM -0300, Carlos Pita wrote:
> > Exiting in a subshell will never cause the parent shell to exit,
> > regardless of depth.
>
> This is not true in general.
> set -e; (exit 1); echo "I don't exist"
In this case, it is the "set -e" which may or may not cause the pare
> $(xxx) is a word expansion, not a command. Bash will only pay attention to
> the exit status of command substitution in one case (x=$(foo)). This
> command substitution doesn't contribute to any other command's exit status,
> especially `echo', and `set -e' doesn't cause the shell to pay attent
On 10/6/13 8:37 PM, Carlos Pita wrote:
> I'm not completely sure whether this is a bug or not but it seems
> not possible to immediately exit a shell when an error happens at 2+
> levels of subshell nesting. Specifically, there is a command at the
> top-level shell waiting for the results of a
On Sun, Oct 06, 2013 at 09:37:00PM -0300, Carlos Pita wrote:
> I'm not completely sure whether this is a bug or not but it seems
> not possible to immediately exit a shell when an error happens at 2+
> levels of subshell nesting.
Exiting in a subshell will never cause the parent shell to exit,
r
On 10/16/2012 03:16 PM, Greg Wooledge wrote:
On Mon, Oct 15, 2012 at 08:08:10PM -0400, DJ Mills wrote:
done< <(set -o)
Huh... that's interesting. I wouldn't have expected it, but it turns
out you don't "lose" the value of errexit in a process substitution the
way you do in a command substitu
On Mon, Oct 15, 2012 at 08:08:10PM -0400, DJ Mills wrote:
> done < <(set -o)
Huh... that's interesting. I wouldn't have expected it, but it turns
out you don't "lose" the value of errexit in a process substitution the
way you do in a command substitution.
imadev:~$ bash -c 'set -e; x=$(set +o);
Hi Chet,
On 10/16/2012 02:13 AM, Chet Ramey wrote:
On 10/15/12 11:23 AM, Nikolai Kondrashov wrote:
I've noticed that errexit is disabled inside command substitution.
Is this intentional?
Yes. It's been that way since bash-1.14. The reasons why are lost in
time -- it was 17 years ago, after
On 10/16/2012 03:08 AM, DJ Mills wrote:
Do not use for to iterate over the output of an unquoted command
substitution.
Well, I wanted to keep it simple in this case.
Instead, use a while read loop.
See http://mywiki.wooledge.org/DontReadLinesWithFor and
http://mywiki.wooledge.org/BashFAQ/001
On 10/16/2012 03:21 AM, DJ Mills wrote:
On Mon, Oct 15, 2012 at 8:08 PM, DJ Mills wrote:
while read -r attr state; do
if [[ $shellopts = *:"$attr":* ]]; then
set -o "$attr"
else
set +o "$attr"
fi
done< <(set -o)
Erm, correction, that won't work for the first and last value
On Mon, Oct 15, 2012 at 8:08 PM, DJ Mills wrote:
> while read -r attr state; do
> if [[ $shellopts = *:"$attr":* ]]; then
> set -o "$attr"
> else
> set +o "$attr"
> fi
> done < <(set -o)
Erm, correction, that won't work for the first and last values in shellopts.
You could add colon
On Mon, Oct 15, 2012 at 5:18 PM, Nikolai Kondrashov
wrote:
> On 10/16/2012 12:08 AM, Greg Wooledge wrote:
>>
>> Sidestepping the direct question for a moment, you could use a temporary
>> file instead of a command substitution to store the output. Then there
>> would be no subshell involved.
>
>
On 10/15/12 11:23 AM, Nikolai Kondrashov wrote:
> Hi everyone,
>
> I've noticed that errexit is disabled inside command substitution.
> Is this intentional?
Yes. It's been that way since bash-1.14. The reasons why are lost in
time -- it was 17 years ago, after all -- but probably go something l
On 10/16/2012 12:08 AM, Greg Wooledge wrote:
Sidestepping the direct question for a moment, you could use a temporary
file instead of a command substitution to store the output. Then there
would be no subshell involved.
Thanks, Greg. I don't like creating temporary files unnecessarily, so I we
Hi Andreas,
On 10/16/2012 12:20 AM, Andreas Schwab wrote:
Nikolai Kondrashov writes:
Actually, I'm writing it for myself and I want to *disable* errexit
temporarily for other's code
o=$-; set +e; ...; case $o in *e*) set -e;; esac
Thanks, I considered the usage of $- (only found it today).
Nikolai Kondrashov writes:
> Actually, I'm writing it for myself and I want to *disable* errexit
> temporarily for other's code
o=$-; set +e; ...; case $o in *e*) set -e;; esac
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 827
Hi Greg,
On 10/15/2012 11:13 PM, Greg Wooledge wrote:
On Mon, Oct 15, 2012 at 04:00:01PM -0400, DJ Mills wrote:
I'm also not entirely sure what you mean by "errexit will always be
stored as off."
My interpretation is that he wants to write a "portable function" for
someone else to use, and th
On Tue, Oct 16, 2012 at 12:01:56AM +0300, Nikolai Kondrashov wrote:
> I'm trying to implement a pair of functions that would save/restore option
> state onto/from a stack, so I could modify options temporarily for some
> parts
> of code. I've worked around this problem already and it is not the su
On 10/15/2012 11:00 PM, DJ Mills wrote:
I'm also not entirely sure what you mean by "errexit will always be
stored as off."
I mean that if I try to capture option state with, for example: opts=`set +o`,
the errexit status will be lost.
It's on there... Do you not understand that command subst
Hi Daniel,
On 10/15/2012 10:44 PM, DJ Mills wrote:
On Mon, Oct 15, 2012 at 11:23 AM, Nikolai Kondrashov
wrote:
I've noticed that errexit is disabled inside command substitution.
Is this intentional?
It makes it hard to save and restore errexit state. I.e. you can't simply
say
opts=`set +o`,
On Mon, Oct 15, 2012 at 04:00:01PM -0400, DJ Mills wrote:
> I'm also not entirely sure what you mean by "errexit will always be
> stored as off."
My interpretation is that he wants to write a "portable function" for
someone else to use, and that he wants to use errexit while inside it,
and therefo
On Mon, Oct 15, 2012 at 11:23 AM, Nikolai Kondrashov
wrote:
> Hi everyone,
>
> I've noticed that errexit is disabled inside command substitution.
> Is this intentional?
>
> It makes it hard to save and restore errexit state. I.e. you can't simply
> say
> opts=`set +o`, because errexit will always
On Mon, Oct 15, 2012 at 11:23 AM, Nikolai Kondrashov
wrote:
> Hi everyone,
>
> I've noticed that errexit is disabled inside command substitution.
> Is this intentional?
>
> It makes it hard to save and restore errexit state. I.e. you can't simply
> say
> opts=`set +o`, because errexit will always
On Jan 5, 12:18 pm, Eric Blake wrote:
> On 01/05/2011 09:57 AM, Greg Wooledge wrote:
>
>
>
> > On Wed, Jan 05, 2011 at 08:21:18AM -0800, chengiz wrote:
> >> So if I get this right, the only time this is a problem is when the
> >> command substitution runs more than once.
>
> > I'd actually charact
On 01/05/2011 09:57 AM, Greg Wooledge wrote:
> On Wed, Jan 05, 2011 at 08:21:18AM -0800, chengiz wrote:
>> So if I get this right, the only time this is a problem is when the
>> command substitution runs more than once.
>
> I'd actually characterize it differently: it's unsafe to run arbitrary
> c
On Wed, Jan 05, 2011 at 08:21:18AM -0800, chengiz wrote:
> So if I get this right, the only time this is a problem is when the
> command substitution runs more than once.
I'd actually characterize it differently: it's unsafe to run arbitrary
commands during tab completion, because bash doesn't kno
On Jan 1, 11:20 pm, Chet Ramey wrote:
> On 12/31/10 11:01 PM, Sven Mascheck wrote:
>
> > On Fri, Dec 31, 2010 at 12:20:38PM -0800, chengiz wrote:
> >> On Dec 31, 12:20 pm, Sven Mascheck wrote:
>
> >>> (see alsohttp://lists.gnu.org/archive/html/bug-bash/2008-01/msg00049.html)
> >>> [...]
>
> >> I
On 12/31/10 11:01 PM, Sven Mascheck wrote:
> On Fri, Dec 31, 2010 at 12:20:38PM -0800, chengiz wrote:
>> On Dec 31, 12:20 pm, Sven Mascheck wrote:
>
>>> (see also http://lists.gnu.org/archive/html/bug-bash/2008-01/msg00049.html)
>>> [...]
>>
>> I dont see how that's related - I dont doubt you tha
On Fri, Dec 31, 2010 at 12:20:38PM -0800, chengiz wrote:
> On Dec 31, 12:20 pm, Sven Mascheck wrote:
> > (see also http://lists.gnu.org/archive/html/bug-bash/2008-01/msg00049.html)
> > [...]
>
> I dont see how that's related - I dont doubt you that the fix to this
> issue "broke" my example, but
On Dec 31, 11:57 am, Eric Blake wrote:
> On 12/31/2010 09:49 AM, Chris F.A. Johnson wrote:
>
> > Fri, 31 Dec 2010 11:49:26 -0500 (EST) linux system
> >>> with default installation settings.
>
> >>> In an earlier version of bash (3.2), the following works
> >>> ls `pwd`/ (expands pwd).
>
> >>> In b
On Dec 31, 12:20 pm, Sven Mascheck wrote:
> On Dec 30, 12:59 pm, chengiz wrote:
>
> > > In an earlier version of bash (3.2), the following works
> > > ls `pwd`/ (expands pwd).
>
> > > In bash 4.1 it does not. Am I missing a setting or something?
> > > Thank you.
>
> This changed with bash-3.2.37
You can get similar results:
`shell-expand-line (M-C-e)'
Expand the line as the shell does. This performs alias and
history expansion as well as all of the shell word expansions
(*note Shell Expansions::).
http://tiswww.case.edu/php/chet/bash/bashref.html#SEC115
On my system that
On Dec 30, 12:59 pm, chengiz wrote:
> > In an earlier version of bash (3.2), the following works
> > ls `pwd`/ (expands pwd).
> >
> > In bash 4.1 it does not. Am I missing a setting or something?
> > Thank you.
This changed with bash-3.2.37
"Bash inappropriately evaluates command substitutions
On 12/31/2010 09:49 AM, Chris F.A. Johnson wrote:
> Fri, 31 Dec 2010 11:49:26 -0500 (EST) linux system
>>> with default installation settings.
>>>
>>> In an earlier version of bash (3.2), the following works
>>> ls `pwd`/ (expands pwd).
>>>
>>> In bash 4.1 it does not. Am I missing a setting or som
Fri, 31 Dec 2010 11:49:26 -0500 (EST) linux system
with default installation settings.
In an earlier version of bash (3.2), the following works
ls `pwd`/ (expands pwd).
In bash 4.1 it does not. Am I missing a setting or something?
Thank you.
Anybody that can at least verify this? Thanks.
On Dec 30, 12:59 pm, chengiz wrote:
> Command substitution and auto completion are not working well together
> in the latest version of bash (4.1). This was on an x64 linux system
> with default installation settings.
>
> In an earlier version of bash (3.2), the following works
> ls `pwd`/ (expand
On 4/23/10 4:17 AM, Binarus wrote:
> The script
>
> echo 'line1' > file
> echo 'line2' >> file
> RESULT=$(cat file)
> echo "$RESULT"
>
> gives the following output:
>
> line1
> line2
>
> I don't understand why: the command substitution $(cat file) is not
> within double quotes, so word splitti
Binarus wrote:
> The script
>
> echo 'line1' > file
> echo 'line2' >> file
> RESULT=$(cat file)
> echo "$RESULT"
>
> gives the following output:
>
> line1
> line2
>
> I don't understand why: the command substitution $(cat file) is not
> within double quotes, so word splitting should be applied
ma...@fiz15.jupiter.vein.hu a écrit :
> Short example:
> $ echo $(echo "'alfa beta'")
> 'alfa beta'
>
> Instead of 'alfa beta' with double space.
Always try tracing to understand what is going on:
echo $(set -x ;echo "'alfa beta'")
++ echo ''\''alfa beta'\'''
http://www.mpi-inf.mpg.de/~u
On Tue, Dec 08, 2009 at 02:01:23PM +0100, ma...@fiz15.jupiter.vein.hu wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: i686
> OS: linux-gnu
> Compiler: i686-pc-linux-gnu-gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
> -DCONF_OSTYPE='linux
On Tue, 08 Dec 2009 14:01:23 +0100
ma...@fiz15.jupiter.vein.hu wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: i686
> OS: linux-gnu
> Compiler: i686-pc-linux-gnu-gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
> -DCONF_OSTYPE='linux-gnu'
On Tue, Dec 08, 2009 at 02:01:23PM +0100, ma...@fiz15.jupiter.vein.hu wrote:
> $ echo $(echo "'alfa beta'")
> 'alfa beta'
>
> Instead of 'alfa beta' with double space.
echo "$(echo "'alfa beta'")"
On Sat, Dec 13, 2008 at 09:30:27AM +0100, Andreas Schwab wrote:
> "S. Sevki Dincer" writes:
>
> > i want to start building a project with ./configure --prefix=... $(myflags)
> > where myflags is an executable text file on my path. myflags has the
> > following in it:
> > printf 'CFLAGS="-O2 -fomi
1 - 100 of 101 matches
Mail list logo
