On Tue, 2023-10-17 at 00:26 -0400, Grisha Levit wrote:
> The array subscript can an arbitrary arithmetic expression with side
> effects, so it makes sense to perform the expansion even if the array
> whose subscript is being expanded is unset:
Okay... that's all pretty convoluted. I assume it boil
Hey.
On Mon, 2023-10-16 at 22:05 -0400, Lawrence Velázquez wrote:
> Under no circumstances should your examples complain about "array"
> because they do not attempt to expand it. As I demonstrated, your
> examples do not even complain about unset scalar variables.
Okay I realise now, why it work
Hey.
On 5.2.15 I've noticed the following:
$ set -u
$ [ -n "${array[key]+is_set}" ] && echo is set || echo not set
bash: key: unbound variable
$ [[ -v array[key] ]] && echo is set || echo not set
bash: key: unbound variable
$ declare -A array
$ [ -n "${array[key]+is_set}" ] && echo is set || ech
On Fri, 2015-03-27 at 01:44 -0600, Eduardo A. Bustamante López wrote:
> Why would the user set BASH_VERSION in the environment? That sounds like
> asking
> for trouble!
Murphy's law! :D
> - try to unset BASHOPTS (did it work? then it's not bash)
> - Now, store the value of BASHOPTS in a temp va
On Fri, 2015-03-27 at 15:11 -0400, Greg Wooledge wrote:
> OK, this is for some personal configuration management.
Well it's rather for some 1000 institute workstations,...
> Not as part of
> a product you're deploying, etc. As such, presumably you are not trying
> to trick yourself into breaki
On Fri, 2015-03-27 at 14:56 -0400, Greg Wooledge wrote:
> ... why are you running test suites in your .bashrc??
As said, I'd find it nice to have one aliases file for all shells, and
that would in turn then be sourced from either .profile or
rather .bashrc... so while tests wouldn't run in .bashr
On Fri, 2015-03-27 at 08:13 -0600, Eric Blake wrote:
> As the autoconf
Autotools... not really the saviour of the world ;-)
> world has proven, it's better to test for features
Well, it's not that I'd have something against that per se, but:
- keeping a complex test suite for many cases up-to-da
On Fri, 2015-03-27 at 08:56 +0100, Andreas Schwab wrote:
> Why do you need to know that?
Well there are so many use cases... my particular one is, that many
shells share config files (e.g. .profile) and for other cases (e.g.
aliases definitions) it would be handy if one could set up a sourcable
sc
Hey.
There are a lot of articles on the web about detecting the actually
running shell.
Unfortunately, just relying on $SHELL doesn't really work since when I
invoke e.g. csh from bash, it would be still $SHELL=bash and I guess I
won't be able to convince all shell upstreams to overwrite $SHELL (w
On Thu, 2015-03-26 at 16:54 -0400, Chet Ramey wrote:
> The solution cannot be bash-specific; the history library is used by many
> other applications.
One, design-wise ugly, idea:
Couldn't you abuse the history comment char another time for that?
Like consider anything between a ^#[[:digit:]] to b
On Thu, 2015-03-26 at 15:21 -0400, Chet Ramey wrote:
> What do you mean "ignore its effect"? You have newlines embedded in
> history entries; what do you plan to do about them?
Well that was just the uneducated idea based on blind assumptions by
*not* having read the code O:-)
AFAIU, both alread
On Thu, 2015-03-26 at 16:26 -0400, Chet Ramey wrote:
> > And b) it seems kinda ugly that one needs to explicitly set a default
> > value that would be set later anyway.
> Maybe.
Okay, keep me tuned if you should plan to actually do that, cause then I
can revise manually setting it :)
> It is wh
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 a
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
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 preserv
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
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.
Hey.
On Sun, 2015-03-22 at 22:08 -0400, Chet Ramey wrote:
> It does when you call the exit builtin. EOF to an interactive shell
> executes the exit builtin, but you have to explicitly call it when in
> a non-interactive shell.
Ah... tricky :D
Okay could you then please add this? Guess many other
Hey.
The bash manpage says:
>When a login shell exits, bash reads and executes commands from the
>file ~/.bash_logout, if it exists.
However, it seems that this happens only for interactive login
shells,... at least I couldn't get it executed for non-interactive login
shells with the --login opti
19 matches
Mail list logo
