Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #15617

Re: bash loses control of jobs inside a command substitution

Path csiph.com!eternal-september.org!feeder.eternal-september.org!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From Oğuz <oguzismailuysal@gmail.com>
Newsgroups gnu.bash.bug
Subject Re: bash loses control of jobs inside a command substitution
Date Wed, 20 Nov 2019 15:18:35 +0300
Lines 24
Approved bug-bash@gnu.org
Message-ID <mailman.2082.1574252331.13325.bug-bash@gnu.org> (permalink)
References <CAH7i3LqejwmNBPLOXHaesjXi9PA=+oU2jGxL7CGOE8cbEJyxzg@mail.gmail.com> <CAH7i3LpK_4NTF1z_Dy=6yy19NW9=RGZBbTwOV-G_DMqxJu77rA@mail.gmail.com>
NNTP-Posting-Host lists.gnu.org
Mime-Version 1.0
Content-Type text/plain; charset="UTF-8"
Content-Transfer-Encoding quoted-printable
X-Trace usenet.stanford.edu 1574252331 7748 209.51.188.17 (20 Nov 2019 12:18:51 GMT)
X-Complaints-To action@cs.stanford.edu
Cc bug-bash@gnu.org
To luizluca@gmail.com
Envelope-to bug-bash@gnu.org
DKIM-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=D3KV7oGMM+QmGGx1wiyW0W4f6oq3JUbgcwwRotkluWM=; b=a1f0B3z9jbum1lONN/B8KYjiDcY3Y/m+eeQ5Z8M6PETzRo/r/oBtCDZxyqInGGifqp crpDlHOdFOQDn4CWhbDSoHyWIf8C9jw8IPqik+70HTEhc+MMtttJMWg5kX8yV7r+7eaR qxGUrscuT27SwBGvPqrv9pbMNNUwbYTXotUgCArW/j/atcjQ/IbyHHTlSGJVs61DaSZE WdvZwJshhzUTOR4274s39izSEes4zptuH+/Epl0bFZ/B+fhhJr8pxxCrVHSsWyRF4VhV 1ZWmP8XKYo7CexRY95xYlJhxFu/YC6jDTNyDycwLWXRt1heeaHE+dPVgL1RWlKapfW7G 4dqA==
X-Google-DKIM-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=D3KV7oGMM+QmGGx1wiyW0W4f6oq3JUbgcwwRotkluWM=; b=f0kAI+oE8EBIIVJHx7tW1og/oC8AESP3OGbY4sM0NDHz+e4w34o3CRrN3OoG2nKBaI Fl5SzaUwZ4humUpE+AASTQOuJKFq/W4EKJKnLqYcDsyInGDvuPmAIUBHjJTBZDxrcloq 1o93Ue19YT3FXriLs7jk28wiEZ86m1PUoPLMeM9A0Ptt3r537RVZtqH2Vdy2OWiOiQd/ FWnn1rwn1ug1Jgcpa0FV/1SeknDywuhCnIk78kxL9RUDJ2AyWcCkXzkRiIGwUEgsgwhV HihvJSjk3WZxB0RwSKafQDUsxNN2U6gwvA0W+s95nJX98MBVZPkjjCzumEckXJVKdKKM tWww==
X-Gm-Message-State APjAAAUzu+SbFBT6avXq16AAlse4uHDlTqGL4LM379daO+FwotJqasf1 e/3dLI1pW5HjIk3xnzrnbrYymt++o8T9G+cZE8c=
X-Google-Smtp-Source APXvYqymeN9JPZhyQKsNyr1zbuPoD/T9s9VLzAK+v2Y+ojL8Y6cnx1VmOurPtgqCdlhiAHGHMxOWvpWve3k87FSqIGk=
X-Received by 2002:a0c:a9cc:: with SMTP id c12mr2248995qvb.222.1574252327185; Wed, 20 Nov 2019 04:18:47 -0800 (PST)
In-Reply-To <CAH7i3LqejwmNBPLOXHaesjXi9PA=+oU2jGxL7CGOE8cbEJyxzg@mail.gmail.com>
X-detected-operating-system by eggs.gnu.org: Genre and OS details not recognized.
X-Received-From 2607:f8b0:4864:20::f34
X-Content-Filtered-By Mailman/MimeDel 2.1.23
X-BeenThere bug-bash@gnu.org
X-Mailman-Version 2.1.23
Precedence list
List-Id Bug reports for the GNU Bourne Again SHell <bug-bash.gnu.org>
List-Unsubscribe <https://lists.gnu.org/mailman/options/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=unsubscribe>
List-Archive <https://lists.gnu.org/archive/html/bug-bash>
List-Post <mailto:bug-bash@gnu.org>
List-Help <mailto:bug-bash-request@gnu.org?subject=help>
List-Subscribe <https://lists.gnu.org/mailman/listinfo/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=subscribe>
X-Mailman-Original-Message-ID <CAH7i3LpK_4NTF1z_Dy=6yy19NW9=RGZBbTwOV-G_DMqxJu77rA@mail.gmail.com>
X-Mailman-Original-References <CAH7i3LqejwmNBPLOXHaesjXi9PA=+oU2jGxL7CGOE8cbEJyxzg@mail.gmail.com>
Xref csiph.com gnu.bash.bug:15617

Show key headers only | View raw


Behavior of wait -n differs on interactive and non-interactive sessions
though, maybe this really is a bug

    $ bash -ic '( ( sleep 0.1; exit 13 ) & sleep 0; wait -n; echo $? )'
    0
    $ bash -c '( ( sleep 0.1; exit 13 ) & sleep 0; wait -n; echo $? )'
    13

On Wed, Nov 20, 2019 at 1:01 PM Oğuz <oguzismailuysal@gmail.com> wrote:

> This seems more like a race condition, see:
>
>     $ f() { ( sleep 0.1; exit 13 ) & "$@"; wait -n; echo $?; }
>     $
>     $ f sleep 0.0
>     [1] 30612
>     [1]+  Exit 13                 ( sleep 0.1; exit 13 )
>     13
>     $ f sleep 0.2
>     [1] 30617
>     [1]+  Exit 13                 ( sleep 0.1; exit 13 )
>     127
>

Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread


Thread

Re: bash loses control of jobs inside a command substitution Oğuz <oguzismailuysal@gmail.com> - 2019-11-20 15:18 +0300

csiph-web