Re: PROMPT_COMMAND='history -a; history -n' causes shell hang in OX 10.10 Yosemite / bash 3.2.53
On Thu, Nov 6, 2014 at 3:28 AM, Chet Ramey wrote: > > In theory, one could change the functions in history.c and histfile.c to > change the in-memory history list to one that uses a file, possibly with > mmap(). > I'd be happy to look at contributed code to do this [..] would you accept a solution like this: 1. all running instances of bash with history support on, share history via shmem segment (some care as to its size should be taken) 2. $HISTFILE in every bash points to history file where every bash writes history in chronological (depending on settings) order 3. $HISTFILE is only read on startup, if there are no other bash instances running 4. sharing of history and synchronisation between instances is realised via standard ipc I have no idea how zsh does it, maybe it should be checked first. cheers, pg
Re: Shellshock-vulnerable version still most obvious on ftp.gnu.org
Chet Ramey writes ("Re: Shellshock-vulnerable version still most obvious on
ftp.gnu.org"):
> I will put tarballs with patches in the usual places within a few days.
Thanks, that would be very helpful.
For the future, it might be worth considering whether it's really
sensible, nowadays, to be distributing bash as `.0 tarball with
patches'. That made sense when bandwidth was much scarcer, disks (and
backup systems) much smaller in relation to source code releases, and
when most people would get bash directly from ftp.gnu.org.
But in the current environment it's looking rather quaint. We could
probably provide a full tarball for each patch release.
Ian.
Re: PROMPT_COMMAND='history -a; history -n' causes shell hang in OX 10.10 Yosemite / bash 3.2.53
On Thu, Nov 06, 2014 at 11:19:55AM +0100, Piotr Grzybowski wrote: > would you accept a solution like this: > > 1. all running instances of bash with history support on, share > history via shmem segment (some care as to its size should be taken) > ... As long as it is off by default. This is the worst feature of ksh, and one of the primary reasons I switched from ksh to bash. Doing ESC k ENTER in ksh with an account to which multiple human beings have shared access (like root) is playing Russian roulette. You never know what you're going to end up executing. It's truly, truly terrible. (And yes, there are systems where root's default shell is ksh. AIX is one of them, or at least it was, back in 1993-1995 when I worked with it extensively.)
Re: Shellshock-vulnerable version still most obvious on ftp.gnu.org
On 11/6/14, 7:47 AM, Ian Jackson wrote:
> Chet Ramey writes ("Re: Shellshock-vulnerable version still most obvious on
> ftp.gnu.org"):
>> I will put tarballs with patches in the usual places within a few days.
>
> Thanks, that would be very helpful.
>
> For the future, it might be worth considering whether it's really
> sensible, nowadays, to be distributing bash as `.0 tarball with
> patches'. That made sense when bandwidth was much scarcer, disks (and
> backup systems) much smaller in relation to source code releases, and
> when most people would get bash directly from ftp.gnu.org.
>
> But in the current environment it's looking rather quaint. We could
> probably provide a full tarball for each patch release.
That is supposed to be one of the advantages of using git. You can always
get a tarball of the latest release with all patches applied using
http://git.savannah.gnu.org/cgit/bash.git/snapshot/bash-master.tar.gz
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: PROMPT_COMMAND='history -a; history -n' causes shell hang in OX 10.10 Yosemite / bash 3.2.53
On 11/6/14, 5:19 AM, Piotr Grzybowski wrote: > On Thu, Nov 6, 2014 at 3:28 AM, Chet Ramey wrote: >> >> In theory, one could change the functions in history.c and histfile.c to >> change the in-memory history list to one that uses a file, possibly with >> mmap(). >> I'd be happy to look at contributed code to do this [..] > > would you accept a solution like this: > > 1. all running instances of bash with history support on, share > history via shmem segment (some care as to its size should be taken) > 2. $HISTFILE in every bash points to history file where every bash > writes history in chronological (depending on settings) order You could use mmap, but the synchronization between different shells writing to the same mmaped segment is a problem that has to be solved. > 3. $HISTFILE is only read on startup, if there are no other bash > instances running > 4. sharing of history and synchronisation between instances is > realised via standard ipc There is no "standard ipc" except pipes across the range of systems bash runs on. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Memory leak in wait
Hi all, A memory leak has been reported in a bash script I maintain [1]. After investigation, I was able to shrink the test case down to: while true do sleep 1 & wait $! done The above loop has an always-rising memory consumption (RSS value as reported by ps -o rss.) This one OTOH: while true do sleep 1 & wait done shows steady memory consumption, so it would seem that the leak only occurs when passing a parameter to "wait". I've seen the problem with bash versions 3.1.14, 4.2.53 and 4.3.30. Version 3.0.16 is not affected. If this a known problem? [1] http://lists.lm-sensors.org/pipermail/lm-sensors/2014-November/042913.html Thanks, -- Jean Delvare SUSE L3 Support
Re: Shellshock-vulnerable version still most obvious on ftp.gnu.org
Chet Ramey writes ("Re: Shellshock-vulnerable version still most obvious on
ftp.gnu.org"):
> On 11/6/14, 7:47 AM, Ian Jackson wrote:
> > But in the current environment it's looking rather quaint. We could
> > probably provide a full tarball for each patch release.
>
> That is supposed to be one of the advantages of using git. You can always
> get a tarball of the latest release with all patches applied using
>
> http://git.savannah.gnu.org/cgit/bash.git/snapshot/bash-master.tar.gz
Right. That's great. But that's not the official primary
distribution channel for bash, as I understand it.
Thanks,
Ian.
Re: Shellshock-vulnerable version still most obvious on ftp.gnu.org
On Nov 6, 2014, at 10:14 AM, Ian Jackson
wrote:
> Chet Ramey writes ("Re: Shellshock-vulnerable version still most obvious on
> ftp.gnu.org"):
>> On 11/6/14, 7:47 AM, Ian Jackson wrote:
>>> But in the current environment it's looking rather quaint. We could
>>> probably provide a full tarball for each patch release.
>>
>> That is supposed to be one of the advantages of using git. You can always
>> get a tarball of the latest release with all patches applied using
>>
>> http://git.savannah.gnu.org/cgit/bash.git/snapshot/bash-master.tar.gz
>
> Right. That's great. But that's not the official primary
> distribution channel for bash, as I understand it.
>
> Thanks,
> Ian.
Don't get me wrong, I love git and it's my mechanism of choice for updates. But
that requires folks to be pretty up-to-date themselves on how to do stuff. As
we were doing the shellshock updates here, I found it a helluva lot easier to
deal with legacy system owners who couldn't do much more than cut and paste of
gunzip bash-N.M.P.tgz
tar xpf bash-N.M.P.tar ; cd bash-N.M.P
./configure && make && make install
They've never run patch, and in some cases don't even have a patch command.
Luckily those folks have legacy admins like me.
For them I built up-to-date tarballs of all the bash-N.M.P versions. Not only
was it a big win for them, it also turned out to be useful for me when trying
to install onto hosts that didn't have git or reasonably recent autoconf chains.
There are a lot of systems out there with custom device drivers for ten- and
twenty-year-old equipment that are monitoring satellites nobody ever thought
would stay up this long, or controlling custom-built devices that need to run
for another 5 years to finish their longitudinal surveys. We're lucky that most
of them at least have a cc and make that works, and we for damned sure don't
have the money to go rebuild them in place with up-to-the-minute tool chains.
Making those folks happy and secure makes my life happier and more secure.
In short, current tarballs are a win, both for the relatively naive admin and
for the old guys. I'm fer it.
Steve
Re: Shellshock-vulnerable version still most obvious on ftp.gnu.org
Chet Ramey wrote: > (The link is to > http://git.savannah.gnu.org/cgit/bash.git/snapshot/bash-master.tar.gz). I > cannot change the main bash webpage to include that text. I'm not sure what you mean by that last sentence; but just in case you don't know, anyone with write access to the code repository for a gnu.org project on Savannah also has write access to the web pages repository. Simply follow the instructions at http://savannah.gnu.org/cvs/?group=bash to checkout the web-pages repository, ie: export CVS_RSH=ssh cvs -z3 -d:ext:@cvs.savannah.gnu.org:/web/bash co bash Simply committing a change to CVS will update the gnu.org web pages almost immediately.
Re: Shellshock-vulnerable version still most obvious on ftp.gnu.org
On 11/6/14, 12:02 PM, Glenn Morris wrote: > Chet Ramey wrote: > >> (The link is to >> http://git.savannah.gnu.org/cgit/bash.git/snapshot/bash-master.tar.gz). I >> cannot change the main bash webpage to include that text. > > I'm not sure what you mean by that last sentence; but just in case you > don't know, anyone with write access to the code repository for a > gnu.org project on Savannah also has write access to the web pages > repository. > > Simply follow the instructions at http://savannah.gnu.org/cvs/?group=bash > to checkout the web-pages repository, ie: Ah, that explains it. I use git; I don't use cvs. The web pages seemingly aren't accessible via git. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Hard-copy terminals
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: darwin14.0.0
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='darwin14.0.0' -DCONF_MACHTYPE='x86_64-apple-darwin14.0.0'
-DCONF_VENDOR='apple' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -DMACOSX -I. -I. -I./include -I./lib -I./lib/intl
-I/Users/reeves/Downloads/bash-4.3/lib/intl -g -O2
uname output: Darwin Kimberly-Reevess-MacBook-7.local 14.0.0 Darwin Kernel
Version 14.0.0: Sat Sep 27 03:58:47 PDT 2014;
root:xnu-2782.1.97~11/RELEASE_X86_64 x86_64
Machine Type: x86_64-apple-darwin14.0.0
Bash Version: 4.3
Patch Level: 30
Release Status: release
Description:
Some features of Bash don't recognize hard-copy terminals.
Repeat-By:
If you're on a hard-copy terminal, and you invoke Bash,
history recall and "readline" support will be invoked anyway
unless the compiler was told for some other reason not to
enable them.
This patch will adjust "configure" so that it disables those
features by default on hard-copy hosts. (Whether to disable
these features is dependent on the host's attributes---not
the guest's attributes, for cross-compiling purposes.)
Fix:
A patch against the Git HEAD is included below.
diff --git a/bash-master/builtins/fc.def b/bash-master/builtins/fc.def
index cf6b72c..801ede9 100644
--- a/bash-master/builtins/fc.def
+++ b/bash-master/builtins/fc.def
@@ -165,6 +165,13 @@ static void fc_addhist __P((char *));
#else
# define POSIX_FC_EDIT_COMMAND "${FCEDIT:-${EDITOR:-ed}}"
#endif
+/* "vi" is bad for hard-copy terminals. Use "ed" instead if we find that we
+ are running on a hard-copy terminal. */
+#include "strstr.h"
+if (reg_strstr(getenv(TERM), "^tty")) {
+# define FC_EDIT_COMMAND "ed"
+# define POSIX_FC_EDIT_COMMAND "${FCEDIT:-ed}"
+}
int
fc_builtin (list)
diff --git a/bash-master/configure b/bash-master/configure
index 98bf890..47c3e54 100755
--- a/bash-master/configure
+++ b/bash-master/configure
@@ -2970,8 +2970,10 @@ opt_minimal_config=no
opt_job_control=yes
opt_alias=yes
-opt_readline=yes
-opt_history=yes
+if ! echo "$TERM" | grep "^tty" >/dev/null; then
+opt_readline=yes
+opt_history=yes
+fi
opt_bang_history=yes
opt_dirstack=yes
opt_restricted=yes
diff --git a/bash-master/configure.ac b/bash-master/configure.ac
index 97e8e04..5bb831c 100644
--- a/bash-master/configure.ac
+++ b/bash-master/configure.ac
@@ -161,8 +161,10 @@ opt_minimal_config=no
opt_job_control=yes
opt_alias=yes
-opt_readline=yes
-opt_history=yes
+if ! echo "$TERM" | grep "^tty" >/dev/null; then
+opt_readline=yes
+opt_history=yes
+fi
opt_bang_history=yes
opt_dirstack=yes
opt_restricted=yes
diff --git a/bash-master/doc/bash.1 b/bash-master/doc/bash.1
index ec41462..df0de0d 100644
--- a/bash-master/doc/bash.1
+++ b/bash-master/doc/bash.1
@@ -7877,8 +7877,10 @@ if
.B FCEDIT
is not set. If neither variable is set,
.FN vi
-is used. When editing is complete, the edited commands are
-echoed and executed.
+is used. (On a hard-copy terminal,
+.FN ed
+is used, regardless.) When editing is complete, the edited commands
+are echoed and executed.
.sp 1
In the second form, \fIcommand\fP is re-executed after each instance
of \fIpat\fP is replaced by \fIrep\fP.
diff --git a/bash-master/include/strstr.h b/bash-master/include/strstr.h
new file mode 100644
index 000..b3fa0dd
--- /dev/null
+++ b/bash-master/include/strstr.h
@@ -0,0 +1,44 @@
+/* strstr.h -- A regular expression version of strstr(). */
+
+/* Copyright (C) 2011 Andreas W. Wylach, Stack Overflow.
+ Copyright (C) 2014 Free Software Foundation, Inc.
+
+ This file is part of GNU Bash, the Bourne Again SHell.
+
+ Bash is free software: you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation, either version 3 of the License, or
+ (at your option) any later version.
+
+ Bash is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with Bash. If not, see
Re: Memory leak in wait
On 11/6/14 8:09 AM, Jean Delvare wrote: > Hi all, > > A memory leak has been reported in a bash script I maintain [1]. After > investigation, I was able to shrink the test case down to: > > while true > do > sleep 1 & > wait $! > done This isn't a memory leak, and the memory use is bounded. The shell, as per Posix, keeps the statues of the last child_max processes. It gets child_max from the process's resource limit (ulimit -v, 709 (?) on my system). The list is FIFO, so when the number of background statuses equals child_max, the oldest statuses are discarded. Posix allows the shell to discard saved status values if $! isn't referenced before another async job is started, but bash doesn't try to do that. > The above loop has an always-rising memory consumption (RSS value as > reported by ps -o rss.) This one OTOH: > > while true > do > sleep 1 & > wait > done When you wait for all background processes, the shell, as per Posix, discards all saved statuses. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
