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
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 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 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
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 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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 ...)
28 matches
Mail list logo