Re: bash man page needs more examples...(i.e. >0)
> OK. How about if that sentence began with `When specifying n, the > digits greater ...'? declare -i foo; foo=20#a2; echo "$foo" 202 [base#]n, 'base' is a INTEGER 2-64, then '#', followed by the number.
How to enable infinite command history
Hi everyone, I got an admittedly basic question but I'm really at my wits' end with this. How do I enable infinite command history ? One simple suggestion I've seen online is to set HISTSIZE and HISTFILESIZE to a large number. This is not what I need, I want genuinely unconstrained history file growth. Another idea I've seen is to unset HISTSIZE and HISTFILESIZE. This doesn't seem to work, the history file is being cropped to the default of 500 lines. I'm probably missing something obvious but any help is appreciated. I'm running Bash 4.1.5 (Debian Squeeze). Kind regards, Ivan Yosifov
Re: How to enable infinite command history
On Mon, Jan 30, 2012 at 8:01 PM, Ivan Yosifov wrote: > Hi everyone, > > I got an admittedly basic question but I'm really at my wits' end with > this. > > How do I enable infinite command history ? > > One simple suggestion I've seen online is to set HISTSIZE and > HISTFILESIZE to a large number. This is not what I need, I want > genuinely unconstrained history file growth. > > Another idea I've seen is to unset HISTSIZE and HISTFILESIZE. This > doesn't seem to work, the history file is being cropped to the default > of 500 lines. > > I'm probably missing something obvious but any help is appreciated. I'm > running Bash 4.1.5 (Debian Squeeze). I don't think there is a way. But do you plan to use bash normally? Setting HISTFILESIZE to 2147483647 gives you 68 years of history at one command per seconds (I hope I got my math right) with say 5 chars per commands it's something like 5GB of history.
Re: bash man page needs more examples...(i.e. >0)
DJ Mills wrote: OK. �How about if that sentence began with `When specifying n, the digits greater ...'? declare -i foo; foo=20#a2; echo "$foo" 202 [base#]n, 'base' is a INTEGER 2-64, then '#', followed by the number. ^^^ That's much more clear!
Re: bash man page needs more examples...(i.e. >0)
On Mon, Jan 30, 2012 at 9:02 PM, Linda Walsh wrote: > > > DJ Mills wrote: > >>> OK. �How about if that sentence began with `When specifying n, the >>> digits greater ...'? >> >> >> declare -i foo; foo=20#a2; echo "$foo" >> 202 >> >> [base#]n, 'base' is a INTEGER 2-64, then '#', followed by the number. > > > > ^^^ That's much more clear! But then one could think that the integer 0xa is a valid base which is not the case since it's not a decimal number
Re: bash man page needs more examples...(i.e. >0)
> > OK. How about if that sentence began with `When specifying n, the > > digits greater ...'? > > declare -i foo; foo=20#a2; echo "$foo" > 202 > > [base#]n, 'base' is a INTEGER 2-64, then '#', followed by the number. How is `INTEGER' any clearer? Integer constants can be specified as octal or hex. -- ``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: bash man page needs more examples...(i.e. >0)
> How is `INTEGER' any clearer? Integer constants can be specified as octal > or hex. Well, ok. The quoted section from the man page specifies a decimal.
Re: bash man page needs more examples...(i.e. >0)
DJ Mills wrote:
OK. �How about if that sentence began with `When specifying n, the
digits greater ...'?
declare -i foo; foo=20#a2; echo "$foo"
202
[base#]n, 'base' is a INTEGER 2-64, then '#', followed by the number.
---
Slightly more exact/pedantic, how about:
Syntax for integer constants is "[BASE#]STRING", where BASE is in set {2..64},
'#' is the literal, 'hash' or 'crosshatch' (U+0023), and STRING represents a
value in the BASE, using ordered characters: 0-9a-zA-Z@_, where
a = 11, b = 12, ... A = 37, B = 38, Z = 61, @ = 62, _ = 63.
Re: bash man page needs more examples...(i.e. >0)
On 1/30/12 2:24 PM, DJ Mills wrote: >> How is `INTEGER' any clearer? Integer constants can be specified as octal >> or hex. > > Well, ok. The quoted section from the man page specifies a decimal. How about `decimal whole number between 2 and 64'? -- ``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/
(low priority) BUG: too large history=nohistory? (was: Re: How to enable infinite command history)
It seems there is a a platform dependent bug somewhere: > HISTSIZE=$(((3**15)) echo $HISTSIZE 1000 --- but you have no history... Pierre Gaston wrote: Setting HISTFILESIZE to 2147483647 gives you 68 years of history at one command per seconds (I hope I got my math right) with say 5 chars per commands it's something like 5GB of history.
Re: set -e in (subshells) does not work independently of outer context
Chet Ramey wrote: As Eric said, the other parts of the Posix description make it clear that the `ignoring set -e' status is inherited by subshells. The original POSIX standard made this clear -- in that it was only a failure of a 'simple' command that resulted' in an err-exit'. Since a subshell is not a 'simple command', it would not qualify just like ((n=0)) isn't a simple command, so shouldn't trigger an error exit...(but has in some recent versions) Is that fixed in bash now?
Re: set -e in (subshells) does not work independently of outer context
On 01/30/2012 02:27 PM, Linda Walsh wrote: > > > Chet Ramey wrote: > >> As Eric said, the other parts of the Posix description make it clear that >> the `ignoring set -e' status is inherited by subshells. > > > The original POSIX standard made this clear -- in that > it was only a failure of a 'simple' command that resulted' in > an err-exit'. Have you not read the link I pointed to? The whole point of http://austingroupbugs.net/view.php?id=52 is a claim that the POSIX 2001 wording for 'set -e' was buggy, because it was inconsistent with traditional practice, and therefore that particular bug report provides the approved TC1 wording for how 'set -e' must behave, when using only the shell features documented by POSIX. > Since a subshell is not a 'simple command', it would not qualify > just like ((n=0)) isn't a simple command, so shouldn't trigger an > error exit...(but has in some recent versions) The corrected POSIX wording makes it clear that any command, simple or otherwise, that does not meet the list of three exclusions, causes the shell to exit. It's just that the three exclusions are quite broad (anything on the left side of a pipe && or ||, anything in the conditional statement of a compound command, and anything except subshells that has non-zero status due to a failed inner command in a context where set -e did not abort the inner command). Bash 4.2 took great pains to comply to the POSIX wording in that particular bug report, seeing as how the original wording in POSIX 2001 was deemed buggy. > > Is that fixed in bash now? Yes, bash 4.2 strives to obey the POSIX wording as set forth in POSIX bug 52. The fact that earlier bash versions did not obey the later POSIX wording, and were therefore incompatible with ksh behavior, is a historical wart due to the wording bug in POSIX. That said, ((n=0)) is not described by POSIX. Here, bash might do better to treat ((n=0)) the same way as ksh, even though in isolation, it is a command exiting with non-zero status. $ bash -c 'set -e; ((foo=0)); echo $?.$foo' $ ksh -c 'set -e; ((foo=0)); echo $?.$foo' 1.0 Or, put another way, if POSIX were to standardize (()), then it would probably have to amend bug 52 to describe whether (()) forms a fourth exception to the list of commands where set -e does not cause an exit on non-zero status. But without a standard to follow, the fact that ksh and bash differ in behavior is a fact of life, and you shouldn't be using non-POSIX extensions if you want your script to be portable to both shells. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: (low priority) BUG: too large history=nohistory?
On 1/30/12 4:14 PM, Linda Walsh wrote: > It seems there is a a platform dependent bug somewhere: > >> HISTSIZE=$(((3**15)) > echo $HISTSIZE > 1000 > --- but you have no history... It depends on how the platform does integer truncation. Bash uses intmax_t for its numbers internally; the readline and history libraries use ints. On a platform where sizeof(intmax_t) == 8 and sizeof(int)==4, you'll get truncation. On a RHEL5 box I happen to have handy, that still means you get a max history size of 14348907 after correcting and performing the assignment above. -- ``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/
