Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #11519
| From | Chet Ramey <chet.ramey@case.edu> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Re: Segfault using HISTTIMEFORMAT |
| Date | 2015-09-20 17:59 -0400 |
| Organization | ITS, Case Western Reserve University |
| Message-ID | <mailman.1486.1442786379.19560.bug-bash@gnu.org> (permalink) |
| References | <05094877-b5a0-4f55-8284-08a27c601353@googlegroups.com> |
On 9/20/15 4:59 PM, rens@endoria.net wrote: > When using HISTTIMEFORMAT and a timestamp which is out of range bash seems to segfault. I've tested this with bash version 4.3.30(1)-release (x86_64-pc-linux-gnu) on Debian 8 stable. > > Here is how to reproduce: > * Change (or add) a timestamp in .bash_history to: > #999999999999999999 > > * Start a new bash shell > > * Run the following commands: > export HISTTIMEFORMAT="[%F %T] " > history > > When history gets executed bash segfaults. It segfaults in strftime() in the C library, which must not be prepared to handle LONG_MAX or LONG_MIN on that system. I'll take a look and see if we can trap that overflow, though you'd like to see strftime handle it better. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRU chet@case.edu http://cnswww.cns.cwru.edu/~chet/
Back to gnu.bash.bug | Previous | Next — Previous in thread | Find similar
Segfault using HISTTIMEFORMAT rens@endoria.net - 2015-09-20 13:59 -0700 Re: Segfault using HISTTIMEFORMAT Chet Ramey <chet.ramey@case.edu> - 2015-09-20 17:59 -0400
csiph-web