On 29/01/2021 19.50, Greg Wooledge wrote:
> Yes, there is a race condition bug, but it's in your script, not in bash.
It seems to come out in linear order. I think what we're seeing here is
what Oğuz observed:
$ echo -e 'dc30a6d79f3b47e310b8b9f5fbadba57
3DCm1587R+MQuLn1+626Vw==' |xxd -r -p
On 28/01/2021 03.29, Léa Gris wrote:
> Now if you want to preserve all the newlines you can use an ASCII EOF
> character (formerly Ctrl + Z) that is unlikely to be part of a legit
> string:
>
> a=$(printf $'hello\n\n\n\32'); a=${a%$'\32'}; declare -p a
When doing this there is no subshell
On 27/01/2021 16.07, Clark Wang wrote:
> $(|cmd ...) makes more sense for me. '|' is a pipe which means passthrough.
>
> For future extensions, use
>
> $([=value1][=value2] cmd ...)
>
> For example,
>
> $(_trailing_newlines cmd ...) is just the same as $(|cmd ...).
> $(_fork cmd ...)
On 27/01/2021 14.49, k...@plushkava.net wrote:
> That's why your .? glob doesn't match the .. pathname. Normally,
> GLOBIGNORE isn't set.
After unsetting GLOBIGNORE:
$ declare -p GLOBIGNORE
declare -x GLOBIGNORE=""
$ shopt -u extglob
$ echo @(?|.?)
-bash: syntax error near unexpected token `('
$
On 27/01/2021 14.30, k...@plushkava.net wrote:
> Note that declare -p BASH_VERSION would report the version of bash that
> you're currently running interactively.
$ declare -p BASH_VERSION
declare -- BASH_VERSION="5.0.17(1)-release"
> Does declare -p GLOBIGNORE show that the variable is set?
On 27/01/2021 12.57, Koichi Murase wrote:
> There was already a discussion to use ${ command } for no-fork command
> substitutions as ksh does.
I would find that syntax very confusing, as ${var} is used to access
variables, so then only the starting space (and the ending semicolon)
would
On 27/01/2021 04.00, k...@plushkava.net wrote:
> One example is that gregrwm claims the following outcome for 5.0.17(1)
> in Ubuntu 20.04:-
>
> $ echo @(?|.?) #. and .. are included
> . .. a .b
$ cat /etc/issue
Ubuntu 20.04.1 LTS \n \l
$ bash --version
GNU bash, version
On 1/26/21 2:46 AM, Chet Ramey wrote:
> On 1/25/21 12:58 PM, Oğuz wrote:
>> I rarely use eval, but when I do, it works just fine.
>
> Someone should create a meme with this text superimposed on an image of the
> Dos Equis most interesting man in the world.
Not sure whether attachments are
On 23/01/2021 05.16, Ángel wrote:
> Why do you want to avoid the subshell? Do you want to modify some
> variables there visible to the parent, or is it just for efficiency ?
Both reasons are good in valid. My concern is more with the former, as
variables within subshell cannot easily be accessed
On 23/01/2021 00.55, Greg Wooledge wrote:
> People just have a deep, almost religious, loathing
> against creating their own temp files.
>
> And yet, these same people are *perfectly* happy if some tool creates
> a temp file for them -- as long as they don't have to see any of the
> details or do
On 22/01/2021 23.10, Léa Gris wrote:
> I'd prefer a syntax based off:
>
> command-list > >(command-list)
> command-list < <(command-list)
>
> But with curly braces for the no sub-shell version:
>
> command-list > >{ command-list;}
> command-list < <{ command-list;}
>
> Which could be used to
On 22/01/2021 22.36, Greg Wooledge wrote:
> What are you talking about? <<< does not remove anything. It only adds
> a newline, which can admittedly be irritating in some situations.
Maybe the version <<<- can nor add a newline??
I was confused with trailing newlines being removed from
On 22/01/2021 21.57, Daniel Colascione wrote:
> Personally, I've found that scanf underpowered for parsing modern data
> formats. Bash's existing regular expression support seems perfectly
> adequate to me, and it can handle everything that scanf can. I'd only
> suggest extending the regular
On 14/01/2021 16.44, William Park wrote:
> Then, I just use variable "rev" and that would be equivalent to
> ${@:55:10}.
So you could just do: rev=(${template[@]:55:10})
With a little function like this, you could call:
Struct template date 7 dev 16 ver 32 rev 10
and get what you want with an
On 08/12/2020 19.55, Greg Wooledge wrote:
> Some terminals, when fed a tab character, will preserve that knowledge
> in memory; then, when you copy text from that part of the terminal
> window using your mouse, the terminal will put a tab byte into the
> selection/clipboard.
Interesting! Which
On 04/07/2020 04.39, Lawrence Velázquez wrote:
> It might tell you something that $[...] is not even mentioned in
> the man page for bash 3.2.57, which is decidedly not the current
> version.
About that, is it for sure that $[] is going to be obsoleted/removed in
the future? I happened to use it
On 23/02/2020 23.27, Chet Ramey wrote:
> On 2/21/20 3:31 AM, pepa65 wrote:
>> By the way, it seems that `local -p var` doesn't work like 'declare -p
>> var` even though `help local` suggests it should.
>
> How so? Do you mean that declare -p var in a function will show differ
On 21/02/2020 02.37, Chet Ramey wrote:
> It's unset because it doesn't have a value, but it retains the `local'
> attribute so it stays local if subsequently assigned one.
Is there any reason the local attribute cannot be unset? If it would be
possible then the "declare/typeset -p" would return 1
On 20/02/2020 19.48, Ulrich Mueller wrote:
> Still, I think it's sad that there isn't a command that can test for
> assigned vs void variable, without the need for parsing of declare -p
> output.
There is no need to parse, the return value of `declare -p var` or
`typeset -p var` will tell you
On 19/02/2020 23.18, Ulrich Mueller wrote:
> So, is there any syntax that allows to test if a value has been assigned
> to the array variable? Especially, to distinguish VARNAME=() (empty
> array) from VARNAME being unset?
Not `test` as such as we have just learned, but the returncode of
`declare
On 12/2/19 9:56 PM, Greg Wooledge wrote:> You're mistaken.
>
> wooledg:~$ set -- a b c
> wooledg:~$ for i do echo "$i"; done
> a
> b
> c
Foot in mouth. I was unfamiliar with this syntax that I guess only works
when no 'in' is used.
Still, for the other cases, it would be nice to be able to
On 12/2/19 9:38 PM, Andreas Kusalananda Kähäri wrote:> for dirpath do
> command mkdir -p "$dirpath" || return
> done
It is very sad that the 'do' is not optional (non-backwards
compatibility breaking feature request!), and it has to be the start of
the next commandline (after
In the arithmetic context, leading zeroes signify an octal base. Had you
used an 8 or 9, you would have gotten a message like:
bash: 08: value too great for base (error token is "08")
when trying: echo $((08))
So it's not a bug, it's a feature; make sure your base-10 numbers don't
have leading
> On Sat, Oct 05, 2019 at 06:48:35PM +, George R Goffe via Bug reports for
> the GNU Bourne Again SHell wrote:
>> I was expecting to see:
>> 12345
>
> If you want to create a *list* and iterate over that list, one element
> at a time, use arrays instead of string variables.
>
> x=(1 2 3 4
On 8/4/2019 22:53, Robert Elz wrote:
> [Aside: when the destination is a builtin, another strategy is to
> simply write the here doc into mem, and have the builtin read directly
> from the mem buffer - no actual I/O of any kind involved at all.]
When in the past I proposed this syntax: cmd
On 8/4/2019 21:19, Robert Elz wrote:
> In general here docs (and here strings) are overused - it is always
> possible to simply write a pipe instead
What is nice about here docs/strings is that there are no subshells
involved.
I think Linda's main drive is to seek improvement in how bash works.
On 20/1/2019 19:50, Eduardo A. Bustamante López wrote:
> Changing the behavior of `unset f' to only ever unset variables means
> potentially breaking existing scripts. Is the inconsistency reported severe
> enough to make this change?
The alternative would be to allow anything (that is not a
On 08/01/2018 07:12 PM, Greg Wooledge wrote:
> This just reinforces the point that unquoted $@ or $* (or the array
> equivalent) is a bug in the script. It gives unpredictable results.
If the results are unpredictable, isn't that a bug that wants fixing?
That would be a very noble goal, should
28 matches
Mail list logo
