Re: feature-request: don't count history time comment lines when in HISTFILESIZE
On Wed, 2015-03-25 at 16:19 -0400, Chet Ramey wrote: > When you start bash, and source your .bashrc, the history comment character > is not set. You haven't set it in .bashrc, I assume Yes, I haven't. > Since that's not set, the lines beginning with > `#[digit]' are not recognized as timestamps and treated as ordinary history > entries. > You can fix this by assigning to histchars before setting HISTFILESIZE: > histchars='!^#' Okay that works in principle. But a) this means truncation of the history file happens immediately each the HISTFILESIZE is set and not just when the shell quits, right? And b) it seems kinda ugly that one needs to explicitly set a default value that would be set later anyway. Wasn't it possible to simply set the default for histchars earlier in the startup? If someone wants to set histchars he'd have to do it anyway, and for those who want to stick with the defaults, this would solve the above issue. Apart from that, it's not really directly obvious that histchars also affects the history itself and not just history expansion. E.g. it's normally not even set in my shell environment (not even the default value). Thanks, Chris.
Re: feature-request: don't count history time comment lines when in HISTFILESIZE
On Wed, 2015-03-25 at 16:21 -0400, Chet Ramey wrote: > https://lists.gnu.org/archive/html/bug-bash/2011-02/msg00042.html Maybe I've missed something but that thread basically just discussed the same issue without giving a solution, right? I understand you concerns about any format changes, that's why my idea was to allow "lithist" set but ignore it's effect when the history file is written... wouldn't that work out? Cheers, Chris.
mapfile segfaults when unsetting array in callback
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='/usr/local/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2
uname output: Linux shbot 3.13.0-44-generic #73-Ubuntu SMP Tue Dec 16 00:22:43
UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.3
Patch Level: 33
Release Status: release
Description:
When using mapfile's callback feature, and the callback unsets the
array mapfile is appending to, it segfaults.
Repeat-By:
callback() { unset MAPFILE; }
(mapfile -c 1 -C callback <<< x)
--
Geir Hauge
Re: feature-request: don't count history time comment lines when in HISTFILESIZE
On 3/25/15 3:50 PM, Christoph Anton Mitterer wrote: > There is the lithist thingy, to preserve newlines in commands which I'd > quite like. > But it doesn't work obviously when [re-]storing [from/]to the history > file. > > Would it be possible to have e.g. another option, so that things work > like lithist=on for the session history, but like lithist=of (i.e. ";" > added where possible) when storing to the history file? https://lists.gnu.org/archive/html/bug-bash/2011-02/msg00042.html The thread starts with https://lists.gnu.org/archive/html/bug-bash/2011-02/msg00025.html -- ``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: feature-request: don't count history time comment lines when in HISTFILESIZE
On 3/25/15 3:02 PM, Christoph Anton Mitterer wrote: > On Wed, 2015-03-25 at 14:48 -0400, Chet Ramey wrote: >> The history file truncation code already skips lines that look like history >> timestamps. Look at history.c:history_truncate_file(). > Ah? Hmm was that only recently introduced? > I'm having bash4.3 with patches up to including 33. And this time I > looked whether Debian added any of it's goodness ;-) > > > When I set e.g. in .bashrc: > HISTSIZE=50 > HISTFILESIZE=50 > HISTTIMEFORMAT=$'%c\t' Here's what happens. The history timestamp code depends on the setting of the history `comment character' -- that's the `#' that it uses to denote the start of a timestamp entry. The history comment character disables history expansion for every subsequent character on a line. When you start bash, and source your .bashrc, the history comment character is not set. You haven't set it in .bashrc, I assume, and it doesn't acquire its default value until later on in the interactive shell initialization process. Since that's not set, the lines beginning with `#[digit]' are not recognized as timestamps and treated as ordinary history entries. You can fix this by assigning to histchars before setting HISTFILESIZE: histchars='!^#' Those are the defaults. 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/
Re: feature-request: don't count history time comment lines when in HISTFILESIZE
On Wed, 2015-03-25 at 15:09 -0400, Chet Ramey wrote: > > I'm having bash4.3 with patches up to including 33. And this time I > > looked whether Debian added any of it's goodness ;-) > I'll take a look. Thanks :) Speaking of feature-requests and history... There is the lithist thingy, to preserve newlines in commands which I'd quite like. But it doesn't work obviously when [re-]storing [from/]to the history file. Would it be possible to have e.g. another option, so that things work like lithist=on for the session history, but like lithist=of (i.e. ";" added where possible) when storing to the history file? Cheers, Chris.
Re: feature-request: don't count history time comment lines when in HISTFILESIZE
On 3/25/15 3:02 PM, Christoph Anton Mitterer wrote: > On Wed, 2015-03-25 at 14:48 -0400, Chet Ramey wrote: >> The history file truncation code already skips lines that look like history >> timestamps. Look at history.c:history_truncate_file(). > Ah? Hmm was that only recently introduced? Bash-3.0. > I'm having bash4.3 with patches up to including 33. And this time I > looked whether Debian added any of it's goodness ;-) I'll take a look. -- ``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: feature-request: don't count history time comment lines when in HISTFILESIZE
On Wed, 2015-03-25 at 14:48 -0400, Chet Ramey wrote: > The history file truncation code already skips lines that look like history > timestamps. Look at history.c:history_truncate_file(). Ah? Hmm was that only recently introduced? I'm having bash4.3 with patches up to including 33. And this time I looked whether Debian added any of it's goodness ;-) When I set e.g. in .bashrc: HISTSIZE=50 HISTFILESIZE=50 HISTTIMEFORMAT=$'%c\t' Then: $ rm .bash_history $ history -c Then start a new shell and then enter commands $ echo 1 $ echo 2 ... $ echo 50 When I do now a: $ history I see all the 50 (+/- 1) But when I leave the shell and go into a new one: $ histroy gives me only about the last 25 (i.e. echo 27 to echo 50 + "history"), and these are also the only entries in .bash_history, i.e.: #1427309882 echo 27 #1427309882 echo 28 [snip snap] #1427309882 echo 50 #1427309884 history Cheers, Chris.
Re: feature-request: don't count history time comment lines when in HISTFILESIZE
On 3/25/15 2:07 PM, Christoph Anton Mitterer wrote: > Hey. > > When HISTTIMEFORMAT is used the history time comment lines are written > to HISTFILE. > Therefore, HISTFILESIZE is effectively only half as large. > > Would it be possible to simply not count the history time comment lines > when enforcing HISTFILESIZE? The history file truncation code already skips lines that look like history timestamps. Look at history.c:history_truncate_file(). -- ``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/
feature-request: don't count history time comment lines when in HISTFILESIZE
Hey. When HISTTIMEFORMAT is used the history time comment lines are written to HISTFILE. Therefore, HISTFILESIZE is effectively only half as large. Would it be possible to simply not count the history time comment lines when enforcing HISTFILESIZE? Cheers, Chris.
Re: read -e deletes extra characters
On 3/24/15 12:19 PM, isabella parakiss wrote: > On 3/24/15, Chet Ramey wrote: >> There are a number of unjustified expectations here. The biggest is that >> readline can know about characters printed to the screen by another >> program. Readline expects to be able to use the entire line and that it >> begins with the cursor in column 0. > > This cannot be right. Of course it can. > The other program's prompt is never deleted when i use read -p ' ', I > can only erase until the point where readline printed that space. > This means that readline _does_ know where to stop, right? No. Readline's redisplay algorithm is adaptive in the sense that it computes the least expensive way to update the screen. Sometimes that means sending the cursor to column 0 (or an arbitrary column) and reprinting the data, and sometimes it means using cursor motion primitives or simple backspace/reprint operations. You cannot a priori know which one readline will choose, and readline expects to be able to use an entire screen line to make that decision and perform redisplay. Readline also needs to know which column it starts in to perform redisplay, and it assumes that it starts in column 0. When you perform more complicated updates, do line wrapping, or have multibyte characters in the line, that information becomes important. > This is what I consider the "correct" behaviour. Is there any way to > achieve this without printing additional characters to the screen? This is what I mean by unjustified expectations. Readline has no way to know what is already on the screen when it runs and does redisplay -- and there is no good way for it to find out. > To summarize: > > Please explain why using read -e -p ' ' the other program's prompt won't > be deleted, but it will if i use read -e -p '' Readline's redisplay algorithm makes different choices in those two cases. You simply cannot count on readline not writing over text it does not know is there. -- ``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: sr #108708: fix for output of 'alias' command
On Wed, Mar 25, 2015 at 10:17:49AM -0400, Chet Ramey wrote: > On 3/25/15 6:35 AM, Eduardo A. Bustamante López wrote: > > Original-Report: https://savannah.gnu.org/support/index.php?108708 > > Reporter: Pasha Bolokhov > > > > Alias produces non-reusable output: > > This is fixed on the devel branch. Hm, awesome! Thanks. dualbus@yaqui:~/local/src/gnu/bash$ GNU bash, version 4.4.0(3)-devel (x86_64-unknown-linux-gnu) dualbus@yaqui:~/local/src/gnu/bash$ alias -- -i='echo i' dualbus@yaqui:~/local/src/gnu/bash$ alias -p alias -- -i='echo i' alias ls='ls --color=auto' I'll put a comment in Savannah to "mark" it as closed :-P
Re: sr #108708: fix for output of 'alias' command
On 3/25/15 6:35 AM, Eduardo A. Bustamante López wrote: > Original-Report: https://savannah.gnu.org/support/index.php?108708 > Reporter: Pasha Bolokhov > > Alias produces non-reusable output: This is fixed on the devel branch. -- ``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/
sr #108708: fix for output of 'alias' command
Original-Report: https://savannah.gnu.org/support/index.php?108708
Reporter: Pasha Bolokhov
Alias produces non-reusable output:
dualbus@yaqui:~$ alias -- -x='echo x'
dualbus@yaqui:~$ alias -p
alias -x='echo x'
alias ls='ls --color=auto'
'help alias' claims it's reusable:
alias -p|grep reusable
dualbus@yaqui:~$ help alias|grep reusable
Without arguments, `alias' prints the list of aliases in the reusable
-pPrint all defined aliases in a reusable format
The original report also contains the attached patch.
--
Eduardo Bustamante | https://dualbus.me/
>From a0e0690489aaa68cd93bc0eff7706c87c33caec7 Mon Sep 17 00:00:00 2001
From: Pasha Bolokhov
Date: Sat, 20 Dec 2014 16:45:05 -0800
Subject: [PATCH] Fix output for an alias starting with a dash
When an alias name starts with '-' the 'alias' command
now inserts a double-dash to make sure the name in not
treated as an option:
alias -- =
---
builtins/alias.def | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/builtins/alias.def b/builtins/alias.def
index d760ceb..892f165 100644
--- a/builtins/alias.def
+++ b/builtins/alias.def
@@ -232,7 +232,11 @@ print_alias (alias, flags)
value = sh_single_quote (alias->value);
if (flags & AL_REUSABLE)
-printf ("alias ");
+{
+ printf ("alias ");
+ if (alias->name && alias->name[0] == '-')
+printf("-- ");
+}
printf ("%s=%s\n", alias->name, value);
free (value);
--
2.1.0
sr #108732: named pipe leaks for systems not support DEV_FD
Original report here: https://savannah.gnu.org/support/index.php?108732
On systems without /dev/fd support, using procsub will generate a temporary
file.
In the case of bash -c 'cat <(echo yes)', the no-fork optimization will cause
this to not clean up the created temporary file.
Reproduced against latest devel branch:
dualbus@yaqui ...src/gnu/bash % strace -fo x -e open ./bash -c 'cat <(echo ok)'
ok
dualbus@yaqui ...src/gnu/bash % grep sh- x
25673 open("/tmp/sh-np-1050257607", O_WRONLY
25672 open("/tmp/sh-np-1050257607", O_RDONLY
dualbus@yaqui ...src/gnu/bash % ls -l /tmp/sh-np-1050257607
prw--- 1 dualbus dualbus 0 Mar 25 04:11 /tmp/sh-np-1050257607
dualbus@yaqui ...src/gnu/bash % rm -f /tmp/sh-np-1050257607
I forced the removal of /dev/fd support with:
dualbus@yaqui ...src/gnu/bash % grep undef config.h|grep DEV_FD
#undef HAVE_DEV_FD
#undef DEV_FD_PREFIX
--
Eduardo Bustamante | https://dualbus.me/
