On 02/12/2018 04:26 PM, Chet Ramey wrote:
On 2/12/18 1:41 AM, Nikolai Kondrashov wrote:
Hi Chet,
On 02/12/2018 01:31 AM, Chet Ramey wrote:
On 2/11/18 1:06 PM, Nikolai Kondrashov wrote:
Hi everyone,
I think I'm hitting a bug in Bash 4.4.12 (on Debian Stable): at some point
an "u
On 02/12/2018 10:03 AM, Clark Wang wrote:
On Mon, Feb 12, 2018 at 3:23 PM, Nikolai Kondrashov mailto:spbn...@gmail.com>> wrote:
Take a look at these links:
- http://wiki.bash-hackers.org/commands/builtin/unset
<http://wiki.bash-hackers.org/commands/buil
On 02/12/2018 09:06 AM, Clark Wang wrote:
On Mon, Feb 12, 2018 at 2:45 PM, Nikolai Kondrashov mailto:spbn...@gmail.com>> wrote:
On 02/12/2018 08:41 AM, Nikolai Kondrashov wrote:
inner() {
unset res
Oh, and duplicating this line fixes the issue.
On 02/12/2018 08:41 AM, Nikolai Kondrashov wrote:
inner() {
unset res
Oh, and duplicating this line fixes the issue.
Nick
Hi Chet,
On 02/12/2018 01:31 AM, Chet Ramey wrote:
On 2/11/18 1:06 PM, Nikolai Kondrashov wrote:
Hi everyone,
I think I'm hitting a bug in Bash 4.4.12 (on Debian Stable): at some point
an "unset" of a global array variable doesn't work inside a function, in
"dkms&
Hi everyone,
I think I'm hitting a bug in Bash 4.4.12 (on Debian Stable): at some point
an "unset" of a global array variable doesn't work inside a function, in
"dkms" script from DKMS package. Adding another "unset" of the same variable
next to it fixes the issue.
Does this sound familiar to an
On 01/28/2015 03:45 PM, Chet Ramey wrote:
On 1/28/15 4:48 AM, Nikolai Kondrashov wrote:
However, the newer versions would fail like this:
bash: command substitution: line 2: syntax error near unexpected token `('
bash: command substitution: line 2: `echo !(*))'
Is this in
Hi everyone,
I've noticed a change in Bash 4.3.30 and 4.3.33, compared to 4.2.53, which
looks like a bug.
With the older versions this:
bash -c 'cat < <(shopt -s extglob'$'\n''echo !(*))'
would output this:
!(*)
which is fine.
However, the newer versions would fail like this:
b
On 09/01/2013 05:52 PM, Chris Down wrote:
On 2013-09-01 12:45, Nikolai Kondrashov wrote:
1) With both nullglob and failglob enabled it is considered an error for a
glob not to match anything. I'd say it's more natural to not produce an
error in this case. Otherwise a fai
Hi everyone,
I'm trying to use "failglob" option in several projects of mine and noticed
the following strange behavior.
1) With both nullglob and failglob enabled it is considered an error for a
glob not to match anything. I'd say it's more natural to not produce an
error in this case. Ot
Chris Down, Chris F.A. Johnson and Pierre Gaston,
thank you all for quick replies!
I now see that this is a known behavior and is considered normal by
developers.
Although, I'd say that it feels unnatural.
On 04/03/2013 11:26 AM, Pierre Gaston wrote:
ok it has indeed been discussed, and this
On 04/03/2013 10:53 AM, Chris Down wrote:
On 2013-04-03 10:50, Nikolai Kondrashov wrote:
On 04/03/2013 10:43 AM, Chris F.A. Johnson wrote:
On Wed, 3 Apr 2013, Nikolai Kondrashov wrote:
I.e. this:
bash -c 'declare -r v; a() { declare -r v; }; a'
Results in:
bash: line 0:
On 04/03/2013 10:53 AM, Nikolai Kondrashov wrote:
Moreover, this:
bash -c 'a() { v=2; }; b () { v=1; a; echo "$v"; }; b'
Sorry, forgot "declare", should be this instead:
bash -c 'a() { v=2; }; b () { declare v=1; a; echo "$v"; }; b'
Sincerely,
Nick
It works because both instances are local to a function and don't
exist outside their own functions.
Not true.
This:
bash -c 'a() { echo "$v"; }; b() { declare -r v=123; a; }; b'
Produces this:
123
Moreover, this:
bash -c 'a() { v=2; }; b () { v=1; a; echo "$v"; }; b'
Produces this:
On 04/03/2013 10:43 AM, Chris F.A. Johnson wrote:
On Wed, 3 Apr 2013, Nikolai Kondrashov wrote:
I.e. this:
bash -c 'declare -r v; a() { declare -r v; }; a'
Results in:
bash: line 0: declare: v: readonly variable
It doesn't work because you are trying to redefine an ex
Hi everyone,
It seems Bash 4.2.37 doesn't allow functions to redefine global constants
locally, yet it allows redefining constants local to calling functions.
Is this as supposed to be, or is it a bug?
I.e. this:
bash -c 'declare -r v; a() { declare -r v; }; a'
Results in:
bash: line
On 11/28/2012 04:58 PM, Nikolai Kondrashov wrote:
Would it be possible to add another extended matching operator to already
supported ones? It's just we have "or" in @() and "not (or)" in !(), but no
"and". And combining patterns without it is awkward.
If I w
Hi everyone,
Would it be possible to add another extended matching operator to already
supported ones? It's just we have "or" in @() and "not (or)" in !(), but no
"and". And combining patterns without it is awkward.
If I want to say "a and not b", I have to write "not (not a or c)", like this:
Hi everyone,
I've encountered a very strange behavior regarding variable scope and traps,
which looks very much like a bug.
This command:
echo '
set -e;
tt() { declare -r v=; };t() { tt; };
ff() { declare -r v=; false; }; f() { ff; };
trap t EXIT;
f
' | bash
produce
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
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
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 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 foun
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 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
op
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 be stored as off. What's
interesting, $SHELLOPTS shows it still on inside
29 matches
Mail list logo
