On Wed, 23 Sep 2020 at 14:24, Chet Ramey wrote:
> "Expanded and executed similarly to BASH_ENV when an interactive shell is
> invoked in POSIX Mode."
>
Yes, that's better than my suggestions, thanks!
--
https://rrt.sc3d.org
The documentation says:
'ENV'
Similar to 'BASH_ENV'; used when the shell is invoked in POSIX Mode
(*note Bash POSIX Mode::).
However, as described elsewhere in the manual, BASH_ENV is used
specifically for non-interactive shells, whereas ENV is used specifically
for interactive shells.
On 13 April 2017 at 22:05, Reuben Thomas wrote:
>
> On 13 April 2017 at 21:17, Chet Ramey wrote:
>
>> On 4/13/17 3:57 PM, Reuben Thomas wrote:
>>
>> > Meanwhile, in the valgrind bug report, Mark Wielaard observed:
>> >
>> > "I think the
On 13 April 2017 at 21:17, Chet Ramey wrote:
> On 4/13/17 3:57 PM, Reuben Thomas wrote:
>
> > Meanwhile, in the valgrind bug report, Mark Wielaard observed:
> >
> > "I think the problem is that bash not only has its own malloc/free
> > implementation (valgr
Here they are. I guess you probably won't care about them as as far as I
can see they are all one-off allocations at initialization:
==1289== 276 bytes in 1 blocks are definitely lost in loss record 230 of 249
==1289==at 0x4C2DB2F: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so
On 13 April 2017 at 16:46, Chet Ramey wrote:
> On 4/13/17 11:41 AM, Reuben Thomas wrote:
>
> > This is not the result I obtained. I simply ran gdb on the bash binary,
> > valgrind was not involved.
>
> If you didn't build the binary yourself,
I did, from git ma
O
n 13 April 2017 at 16:27, Chet Ramey wrote:
> On 4/13/17 11:18 AM, Reuben Thomas wrote:
> > On 13 April 2017 at 16:11, Chet Ramey > <mailto:chet.ra...@case.edu>> wrote:
> >
> >
> > I see no reason why, since all of these things are defined in the
On 13 April 2017 at 16:11, Chet Ramey wrote:
>
> I see no reason why, since all of these things are defined in the same
> file and are statically linked, `free' would resolve to the glibc free
> when malloc resolves to the bash malloc.
So this is the real problem?
Do you have any suggestions
O
n 13 April 2017 at 15:33, Reuben Thomas wrote:
> On 12 April 2017 at 15:49, Chet Ramey wrote:
>
>>
>> It's a false positive, or a bug in valgrind. I took a quick look. There's
>> one place in this code path where free() gets called.
>
>
>
On 12 April 2017 at 15:49, Chet Ramey wrote:
>
> It's a false positive, or a bug in valgrind. I took a quick look. There's
> one place in this code path where free() gets called.
Julian Seward (valgrind author) pointed out:
"
…
what you report is symptomatic of bash
using its own mall
On 13 April 2017 at 09:15, Reuben Thomas wrote:
>
> Having confirmed Chet's analysis with a few printfs added to bash (i.e.
> just to check the address being allocated and the one complained about were
> the same) I've filed a bug report against valgrind:
> https://bug
On 12 April 2017 at 17:58, Hanno Böck wrote:
> On Wed, 12 Apr 2017 14:59:26 +0100
> Reuben Thomas wrote:
>
> > frequently, it's the only tool that shows up bugs of this sort, as
> > it's rather more powerful than a debugging malloc library.)
>
> Try addres
On Apr 12, 2017 4:56 PM, "Chet Ramey" wrote:
[snip]
> Maybe update the Debian bug report you cited as well. There's still stuff
> there from 2005.
The report is from December 2016. I can't find "2005" in the page.
I'll certainly send an update to point to the upstream bug I file.
O
n 12 April 2017 at 15:49, Chet Ramey wrote:
>
> It's a false positive, or a bug in valgrind. I took a quick look. There's
> one place in this code path where free() gets called. Here's the trace:
>
[analysis snipped]
Thanks very much, looks like it's time for me to file a Valgrind bug re
O
n 12 April 2017 at 14:50, Chet Ramey wrote:
> On 4/12/17 8:57 AM, Reuben Thomas wrote:
> > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849517
> >
> > I can reproduce this also in bash 4.3 as supplied with Ubuntu 16.04, and
> > in a build of 4.4 from
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849517
I can reproduce this also in bash 4.3 as supplied with Ubuntu 16.04, and
in a build of 4.4 from source on my Ubuntu system.
As stated in the bug report, the bug causes problems beyond bash, as it
causes build systems to think that val
The default HISTSIZE and HISTFILESIZE have been set for as long as I can
remember (and the repo only seems to back to bash 3.2).
For those concerned about privacy or security, 500 lines is probably too
much.
For those concerned about disk space, it's hard to come up with a sensible
default. My ro
On 18 January 2016 at 22:21, Chet Ramey wrote:
> On 1/18/16 11:53 AM, Reuben Thomas wrote:
>
> > So, how about instead interpreting a missing/0 date as a NaD (Not A
> Date),
> > rather as readline does anyway with time 0, and providing a slightly more
> > meaningf
[
Forwarding reply erroneously not sent to the list.]
On 15 January 2016 at 15:26, Chet Ramey wrote:
> On 1/11/16 11:54 AM, Reuben Thomas wrote:
> > On 11 January 2016 at 14:22, Chet Ramey > <mailto:chet.ra...@case.edu>> wrote:
> >
> > For a history f
On 11 January 2016 at 14:22, Chet Ramey wrote:
> For a history file without any timestamps, using
> the current default and setting the history entry timestamp to the current
> time is more appropriate.
>
Why is that? The only similar thing I can think of is file systems, where
if you zero the
On 8 January 2016 at 04:21, Eduardo A. Bustamante López
wrote:
>
> I now understand your points.
>
Thanks very much for taking a look at this.
> dualbus@hp ...src/gnu/bash % cat ~/.bash_history
> echo 1
> #1452197044
> echo a; sleep 1
> #1452197045
> echo b; sleep 1
>
On 7 January 2016 at 20:07, Eduardo A. Bustamante López
wrote:
> (2) The history should be ordered monotonically (increasing?)
>
Yes, and it's not at the moment (or wasn't, until I added timestamps to
every line in my history), because the lines at the start of the history,
with no timestamp, w
At least in bash 4.3, the documentation for history -a says:
Append the new history lines (history lines entered since the
beginning of the current Bash session) to the history file.
This is unfortunately misleading, since it suggests that the technique of
adding "history -a"
On 18 March 2014 08:04, Linda Walsh wrote:
>
>
> Chet Ramey wrote:
>
>> Because the execution fails in a child process. You'd be able to fix it
>> for that process, but would do nothing about the contents of the parent
>> shell's hash table.
>>
>> The way the option works now is to check the has
On 17 March 2014 20:46, Chet Ramey wrote:
> Because the execution fails in a child process. You'd be able to fix it
> for that process, but would do nothing about the contents of the parent
> shell's hash table.
>
Thanks for the explanation.
--
http://rrt.sc3d.org
On 17 March 2014 20:30, Chet Ramey wrote:
> On 3/17/14 10:17 AM, Dave Rutherford wrote:
> > On Mon, Mar 17, 2014 at 10:12 AM, Chet Ramey
> wrote:
> >> On 3/15/14 2:44 PM, Reuben Thomas wrote:
> >>> On 15 March 2014 18:23, Chet Ramey >>> <mailto:
On 17 March 2014 14:12, Chet Ramey wrote:
> On 3/15/14 2:44 PM, Reuben Thomas wrote:
> > On 15 March 2014 18:23, Chet Ramey > <mailto:chet.ra...@case.edu>> wrote:
> >
> > It's not been a problem, really. The existence of the `checkhash'
> opt
On 15 March 2014 18:23, Chet Ramey wrote:
> It's not been a problem, really. The existence of the `checkhash' option
> has been enough. How often do you remove binaries in directories in $PATH?
>
Fairly often: I frequently rename or retire scripts in my per-user bin
directory.
Since bash is h
On 14 March 2014 18:23, Chet Ramey wrote:
> On 3/14/14 12:11 PM, Reuben Thomas wrote:
> > Tested in bash 4.3.
> >
> > $ foo
> > ... a command is run
> > $ hash
> > hits command
> >0 /home/rrt/bin/foo
> > $ rm `which foo`
> > $ which f
Tested in bash 4.3.
$ foo
... a command is run
$ hash
hits command
0 /home/rrt/bin/foo
$ rm `which foo`
$ which foo
/usr/bin/foo
$ foo
bash: /home/rrt/bin/foo: No such file or directory
Why doesn't bash just remove the hashed path and do a normal PATH search? I
have to remove it manually.
--
(Checked against bash 4.2; for some reason, the manual on gnu.org is only 4.1.)
The top node, "Bash Features", says:
"The following menu breaks the features up into categories based upon which
one of these other shells inspired the feature."
But the following menu doesn't seem to bear that out.
The syntax for the "for" command is misleading, as although correct for
bash, it is not POSIX-compliant.
I am using GNU bash, version 3.2.48(1)-release (i486-pc-linux-gnu)
The man page says:
for name [ in word ] ; do list ; done
which conflicts with the POSIX syntax definition, given in
http
32 matches
Mail list logo
