Hi Chet
I have worked up a patch that considerably simplifies the logic for
setting and displaying the shopt compatXX settings, by getting rid of
the numberous boolean variables and simply computing the setting level
directly.
However before I submit my compatXX patch, I would like to ensure I've
On Fri, 23 Feb 2024, Robert Elz wrote:
> | Yes, that's exactly the point, to *avoid* dynamic scoping. I want the
> | equivalent of Perl's "my", rather than Perl's "local".
>
> Lexical scoping does not, that is, cannot, work with the shell
> language as it is defined, if you want that you need
On Wed, 13 Jan 2016, Chet Ramey wrote:
> On 1/13/16 4:08 AM, Andreas Schwab wrote:
> > Martin Kealey writes:
> >
> >> What do other shells do? Ksh? Dash? Zsh?
> >
> > $ ksh -c 'printf "foo1\nfoo2\n" | { (read x; echo 1: $x) & (read x; echo
On Wed, 13 Jan 2016, Andreas Schwab wrote:
> What does "take them as read" mean?
Taking something as read means that the author thought we would understand
it without them actually writing it down.
Or more prosaically, it means to pretend that they're written there, even
though they're not, becau
On 13 Jan 2016 8:14 p.m., "Andreas Schwab" wrote:
> I don't think so.
>
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07
> doesn't mention pipelines.
That was rather my point. Given that they aren't mentioned, one has to take
them as read, otherwise even ( ( foo
On Mon, 11 Jan 2016, Chet Ramey wrote:
> "The standard input for an asynchronous list, before any explicit
> redirections are performed, shall be considered to be assigned to a file
> that has the same properties as /dev/null."
I thought the (only) point of that to avoid a background job reading
Surely a pipe counts as an explicit redirection?
And even if it didn't, the inconsistency between the first and subsequent
asynchronous elements is confusing.
On 12 Jan 2016 02:41, "Chet Ramey" wrote:
> On 1/10/16 12:54 PM, Piotr Grzybowski wrote:
> > hey,
> >
> > I am quite sure it happens her
I wrote:
> Description:
> The value of $? after starting a backgrounded command is inconsistent:
> $? is unchanged after starting a sufficiently complex command, but
> after starting a simpler command it is set to 0.
> From: Chet Ramey
> Thanks for the report. The exit status of any asynchronous
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' -DPACKAGE
