It's not efficient.
It's not elegant. It's ridiculous and stupid.
Bash itself IS RIDICULOUSLY HUGE and SLOW not just brace expansion.
The whole binary takes up almost 1 mb which is gigantic,
everything is a string and the only
consistency is that it IS INCONSISTENT.
But, I love it
OK. This starts out as one word: "{1..10}'+' +0". Brace expansion
Ok, that's obviously a dumb mistake. And everything you wrote is right.
Just to clean up the mistake:
$ (( {1..10}'+' 0)) # spaces before { and 0
So, as you described, what bash actually does is it takes
$ (( {1..10}'+' 0))
go
From my previous mail:
$ echo $(({1..10}’+’ +0)) # with a space between the first + and the
second one
I'm sorry, I assumed that $(()) and (( )) so the exact same thing so I only
included the $(()) version instead of what I tested on my machine.
Apparently both versions do not behave the same.
If your commands "work" in your shell, but then magically transform into
unusable curly quote glyphs in your mail client, then it's probably your
mail client performing the transformation. Or your text editor, or your
web browser if you're using web-mail.
Your apostrophes in the words "don't" an
her like you to save your recommendations regarding how I am supposed to
do things.
> Am 01.05.2017 um 15:10 schrieb Greg Wooledge :
>
> On Sun, Apr 30, 2017 at 08:31:30PM +0200, Florian Mayer wrote:
>> I want to add up all numbers from 1 to 10,
>
> sum=0; for ((i=1; i<=1
I want to add up all numbers from 1 to 10, but when I do
$ echo $(({1,10}’+’ +0)) # with a space between the first + and the second one
I get an error:
bash: ((: 1+ ,3 10+ ,3: syntax error: operand expected (error token is ",3 10+
,3“)
It seems as if brace expansion gets executed first (as expec
wow..., ok thanks for the quick reply
> On 26 Apr 2017, at 12:17, Pierre Gaston wrote:
>
>
>
>> On Wed, Apr 26, 2017 at 1:13 PM, Florian Mayer wrote:
>> $ echo $BASH_VERSION
>> 4.4.12(1)-release
>> $ echo $BASH_VERSION{nobraceexpansion}
>> 4.4
$ echo $BASH_VERSION
4.4.12(1)-release
$ echo $BASH_VERSION{nobraceexpansion}
4.4.12(1)-release{nobraceexpansion}
$ echo ${BASH_VERSION}{brace,expansion}
4.4.12(1)-releasebrace 4.4.12(1)-releaseexpansion
$ echo $BASH_VERSION{brace,expansion}
=> no output. Unexpected
$ echo $BASH_VERSIONfoo
=> no ou
w, it has something to
do
with (()) or $(()). Merely the visible behavior is similar in the cases I
showed.
> Am 24.04.2017 um 01:43 schrieb Chet Ramey :
>
> On 4/23/17 4:25 PM, Florian Mayer wrote:
>>> That's not a reasonable expectation.
>> Why not? Why is it not rea
I think it does, but on my system
$ foo=bar; bar=moo; echo ${!foo}
really produces the string moo. Therefore, I referred to it as indirection.
> Am 23.04.2017 um 20:02 schrieb Chet Ramey :
>
> On 4/23/17 8:28 AM, Florian Mayer wrote:
>> What I’m saying is, that if bash d
r=moo
> echo $((foo++))
> echo $moo
Thank you.
> Am 23.04.2017 um 15:19 schrieb Pierre Gaston :
>
>
>
> On Sun, Apr 23, 2017 at 4:07 PM, Florian Mayer <mailto:mayerflor...@me.com>> wrote:
> It does not matter, how this construct in this particular con
of what I expanded in order to get a number"
which it does not…
I know that (()) probably was never intended for such a thing, but
it’d be a nice-to-have addition, while being certainly doable :)
> Am 23.04.2017 um 15:07 schrieb Florian Mayer :
>
> It does not matter, how this
not matter whether those constructs actually expand to some
string
or not. The side effects are what matter here. And in my opinion those are not
correct...
> Am 23.04.2017 um 14:43 schrieb Pierre Gaston :
>
>
>
> On Sun, Apr 23, 2017 at 3:28 PM, Florian Mayer <mailto:m
What I’m saying is, that if bash does recursively apply expansion
mechanisms on the identifiers until it can retrieve a number,
it should do it symmetrically. That is,
it should remember what chain of expansion had been necessary for
a particular number to appear at the end of the expansion.
So i
Consider
$ foo=bar; bar=moo; moo=123
$ echo $foo $bar $moo
=> bar moo 123
$ echo $((foo))
=> 123
$ echo $foo $bar $moo
=> bar moo 123
$ # so far so good but
$ ((foo++))
$ echo $foo $bar $moo
=> 123 moo 123
Now my chain of indirections is broken…
> /dev/null | cat
which uses basem. Call basem --h for concrete syntax.
On 02/21/2017 02:55 PM, Greg Wooledge wrote:
On Tue, Feb 21, 2017 at 02:18:03PM +0100, Florian Mayer wrote:
for mutex --lock I use a tool which I wrote myself.
What does it do?
The following code assumes the lock to b
e:
On Mon, Feb 20, 2017 at 11:25:22PM +0100, Florian Mayer wrote:
echo foo | tee >(echo $$) >(echo $$) >/dev/null | cat
returns the same PID twice.
$$ is the PID of the main shell. I think what you want is the PID of
each subshell, $BASHPID.
imadev:~$ cat <(echo $$) <(echo $
echo foo | tee >(echo $$) >(echo $$) >/dev/null | cat
returns the same PID twice. I'm using the version 4.4.11.
Why is there only one process for all the expansions?
Why wasn't that documented?
I think the only right way to do multiple process expansions in one command
is by actually _starting o
Hello,
doing the following yields an segmentation fault.
I am using bash 4.3.42(1) under Archlinux.
/prlimit --nproc=1 bash//
//[florian@kurerm ~]$ pwd//
///home/florian//
//[florian@kurerm ~]$ ls//
//bash: fork: retry: No child processes//
//bash: fork: retry: No child processes//
//bash: fork:
Ah thanks! Sadly paragraph
https://www.gnu.org/software/bash/manual/bash.html#Command-Substitution
doesn't mention this behaviour. Would it be possible to add a line
describing this?
I know that it's in the manual somewhere else, but maybe you could
prevent some
unnecessary questions on this mai
(){
if [ "${FOO["oldval"]}" != "${FOO["data"]}" ]; then
FOO["oldval"]=${FOO["data"]}
return 0
else
return 1
fi
}
file end
Best regards
Florian Mayer
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-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACK
22 matches
Mail list logo
