Hi bash!
First of all, just want to thank you all for all the great work you are
doing.
I was reading the bash man page and found something that I think is a typo.
Under the paragraph of *Lists*, when talking about the AND list, it says:
command2 is executed if, and only if, command1 returns an
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-unknown-linux-gnu'
-DCONF_VENDOR='unknown'
-DLOCALEDIR='/home/konczi.ext/
On 3/2/18 7:14 AM, Koncz, Istvan (Extern) wrote:
> Bash Version: 4.4
> Patch Level: 18
> Release Status: release
>
> Description:
> when i use ~/ for home folder it works in command line e.g. ls
> -la ~/.vimrc works, but when i add it to a variable e.g. foo="~/.vimrc"
> then ~/ will not be replac
On 3/2/18, 9:03 AM, "bug-bash on behalf of Koncz, Istvan (Extern)"
wrote:
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='l
On 2/27/18 11:46 AM, don fong wrote:
> Chet, thanks for the suggestion.
>
> i still wonder what's the objection to changing .gitignore?
I don't think it will be useful to me, since I curate the commits I
make to the various branches, but I don't have any real objection if
it will help others.
--
On 2/28/18 2:00 PM, Robert Elz wrote:
> Date:Wed, 28 Feb 2018 10:27:23 -0500
> From:Chet Ramey
> Message-ID:
>
> | These are two different cases -- same context vs. a previous context. Your
> | example is not the same as the original poster's.
>
> OK, though I a
On 2/28/18 5:38 PM, Robert Elz wrote:
> I would change "appear" to "be" in the description of the current scope
> behaviour.
Now we're straying into semantics. If the variable were `really' unset,
as opposed to just appearing unset, that could be construed as meaning
the global instance (or any p
On 2/28/18 5:38 PM, Robert Elz wrote:
> Were I you, I would simply change the "in a previous scope" behaviour to
> match the "in the current scope" behaviour. That makes it consistent,
> and rational.
I can see doing that with the new behavior controlled by a shell option.
Chet
--
``The lyf s
On 3/2/18 10:00 AM, Fabrizio Di Pilla wrote:
> I think it should say:
>
> command2 is executed if, and only if, command1 returns a non-zero exit
> status.
>
> Notice the added ',' so it will be same as the AND example.
> I don't know if this is really a typo since English is not my primary
>
On 3/1/18 11:37 PM, don fong wrote:
> Chet, thanks. in subst.c there is code that looks similar to what i had
> suggested. but i don't see the tests that i submitted. i also don't see
> the change listed in CHANGES?
I didn't think the tests were necessary. And the ChangeLog file is the
one to l
Chet, thanks for the explanation about CHANGES. i am not familiar with the
bash release process.
as for this:
> I didn't think the tests were necessary.
what standard are you using to judge whether tests are necessary? does the
bash project have any coverage metrics?
on general principles, wh
Date:Fri, 2 Mar 2018 14:43:02 -0500
From:Chet Ramey
Message-ID: <4502a0e5-0600-d294-9af2-4e9eeb0a0...@case.edu>
My final comments on this subject:
| Perhaps. But bash has never done this. Not from day one. That's 30 years.
That a bug (be it a design bug, or a codi
12 matches
Mail list logo
