Date:Mon, 11 Mar 2019 23:15:14 -0500
From:Todd Lehman
Message-ID:
| In any case, please fix as you see fit.
First, to make one thing clear, I have nothing whatever to do
with maintaining bash (for reasons unrelated to anything here,
I won't even go close to its so
On Mar 11, 2019, at 11:03 PM, Robert Elz wrote:
> No, it was fine, I understood the context OK - it is just that this
> is one of those rock and hard place situations - the places where
> there is no period to end a sentence can just as easily be argued
> to be incorrect.
I would argue that reada
Date:Mon, 11 Mar 2019 22:08:47 -0500 (CDT)
From:Todd Lehman
Message-ID:
| Ah. Maybe my initial e-mail wasn't clear.
No, it was fine, I understood the context OK - it is just that this
is one of those rock and hard place situations - the places where
there is no p
On Tue, 12 Mar 2019, Robert Elz wrote:
| The period (".") after "name" should not be there.
Yet, the rules of grammar say it must be, as that is the end of the
sentence.
Ah. Maybe my initial e-mail wasn't clear. The second line is was actual
code sample. It's formatted as verbatim, monosp
Date:Mon, 11 Mar 2019 15:55:55 -0500 (CDT)
From:Todd Lehman
Message-ID:
| The period (".") after "name" should not be there.
Yet, the rules of grammar say it must be, as that is the end of the
sentence. This is the perennial issue with mixing code samples into
E
Hi!
In the version dated 2019-Jan-07, I noticed the following mistake in the
GNU Bash manual:
| Associative arrays are created using
| declare -A name.
The period (".") after "name" should not be there.
--Todd
On 3/11/19 4:15 PM, L A Walsh wrote:
>
>
> On 3/6/2019 7:18 AM, Chet Ramey wrote:
>>> Except that the bash debugger gets lost on files that don't
>>> have a real source file name. Environment is not the name of the file
>>> containing the function -- it is a nebulous, ephemeral area of a
>>>
On 3/11/2019 1:34 PM, Greg Wooledge wrote:
> It's not documented so much as blatantly obvious by looking at how it's
> implemented.
>
---
Undocumented features are subject to change at will. Those are called
'internals'. How they are implemented is not necessarily pertinent to
what documen
On Mon, Mar 11, 2019 at 01:15:16PM -0700, L A Walsh wrote:
> 1) Where is it documented that if you export a function, the original
> source location is thrown away by bash?
It's not documented so much as blatantly obvious by looking at how it's
implemented.
wooledg:~$ export -f title
wooledg:~$
On 3/6/2019 7:18 AM, Chet Ramey wrote:
>> Except that the bash debugger gets lost on files that don't
>> have a real source file name. Environment is not the name of the file
>> containing the function -- it is a nebulous, ephemeral area of a
>> process -- but it certainly is not the reposi
On 3/8/19 7:18 PM, Grisha Levit wrote:
> On Tue, Mar 5, 2019 at 11:26 AM Chet Ramey wrote:
>> This is still a WIP, keep the test cases coming.
>
> bash removes the surrounding space in these cases (all other shells
> print `< X >'):
Thanks for the report.
>
> IFS=; set -- X
> printf "<
On 3/11/19 8:04 AM, Yakup wrote:
> Bash Version: 4.3
> Patch Level: 30
> Release Status: release
>
> Description:
> Bash gets unresponsive when trying to autocomplete within the
> `pmount` command.
> Bash gets responsive again, after canceling the autocomplete `C-c`.
> So I can write agai
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
On Fri, Mar 08, 2019 at 09:53:39AM -0500, Chet Ramey wrote:
> On 3/7/19 9:42 AM, Dr. Werner Fink wrote:
>
> >> There is a slightly updated version of that patch attached to this message.
> >
> > OK ... the hidden directories do work now ... but in the test suite
> > of sed the test case sed-4.7/t
14 matches
Mail list logo
