ot me involved all those years ago in this
field and which I am still happy to be a tiny part of.
Keep up the good work!
On 04.11.24 16:20, Chet Ramey wrote:
On 11/4/24 10:15 AM, Christoph Zimmermann wrote:
Thanks for pointing me in the right direction. When checking the info and man (bash.1)
fil
on as apparently I'm missing
something? Thanks!
On 04.11.24 16:03, Chet Ramey wrote:
On 11/4/24 3:20 AM, Christoph Zimmermann wrote:
Hi Chat,
As I can't seem to find this: You are referring to the 'devel' branch at https://
github.com/bminor/bash (files doc/bash.info and doc/bash.
Hi Chat,
As I can't seem to find this: You are referring to the 'devel' branch at
https://github.com/bminor/bash (files doc/bash.info and doc/bash.1)?
Cheers, Chris
On 03.11.24 21:00, Chet Ramey wrote:
On 11/3/24 5:28 AM, Christoph Zimmermann wrote:
Thanks fo
Thanks for all the quick reactions on that issue (including microsuxx's suggestion which
unfortunately does require a CB change).
If this is intended behaviour, it should be clearly documented on the corresponding man
page (which doesn't seem to be case ATM).
On 02.11.24 19:57, Chet Ramey wro
Configuration Information [Automatically generated, do not change]:
Machine: aarch64
OS: darwin24.0.0
Compiler: clang
Compilation CFLAGS: -DSSH_SOURCE_BASHRC
-DDEFAULT_LOADABLE_BUILTINS_PATH='/opt/homebrew/Cellar/bash/5.2.37/lib/bash:/usr/local/lib/bash:/usr/lib/bash:/opt/local/lib/bash:/usr/pkg/l
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 Sat, Oct 10, 2015 at 8:24 PM, Chet Ramey wrote:
> I will consider adding an option to change the behavior of command
> substitution inheriting the -e option, since there doesn't seem to be
> any way to decouple this behavior from posix mode.
I added a patch:
https://savannah.gnu.org/patch/inde
> I know you don't want to hear this, but you really need to stop thinking
> of set -e as "error checking". It is an obsolescent historical anomaly
> that bash is required to support because POSIX specifies it. It isn't
> useful for any purpose, and people who insist on using it are simply
> caus
> I think you're overlooking what I referred to above: that the exit status
> of a command substitution doesn't have any effect on whether the parent's
> command succeeds or fails except in one case: the right-hand-side of an
> assignment statement that is the last assignment in a command consistin
> The parent shell (the one that enabled -e) should be the one to make the
> decision about whether or not the shell exits. The exit status of the
> command substitution doesn't make a difference except in one special case,
> so inheriting errexit and exiting (possibly prematurely) doesn't really
> Chet can give the definitive answer, but my take is that it's a huge
> surprise to someone writing a function independent of the script, or
> using a function that was written independently of the script. If the
> function does not expect set -e to be in effect (which is not the default,
> and i
> Since it's a function, I would recommend return instead of exit. Also,
> you don't need the $? there. exit (or return) with no arguments will
> retain the exit status of the previous command.
Yes, $? is not needed.
exit or return is equivalent in this case though because of set -e.
> Putting
> Yes, it's how bash has always behaved, at least back to bash-1.14 when
> I stopped looking. Around bash-2.05, it changed to preserve the -e
> option when in Posix mode.
Is there any reason not to preserve it?
> That exception from default bash behavior is documented in the Posix
> Mode section
> Whether e disappears from $- may be unintended, but what IS documented
> is that there are contexts in which set -e has no effect, and when in
> one of those contexts, you cannot re-enable set -e. One such context is
> on the left side of && or ||. Even more non-intuitively, if you have a
> fun
It seems that set -e is stripped from the options ($-) when executing
commands with command substitution:
$ bash -euc 'echo $-; f(){ false; echo $->&2; }; x=$(f)'
ehuBc
huBc
I would expect the shell to exit as soon as it executes 'false'.
Is this intended? Is it documented somewhere?
I'm trying
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
On 07/27/2010 02:35 PM, Greg Wooledge wrote:
> On Tue, Jul 27, 2010 at 01:44:26PM +0200, Christoph Dittmann wrote:
>> What I was going for was a script which executes another command with a
>> timeout.
>
> http://mywiki.wooledge.org/BashFAQ/068
The process I want to put under
On 07/27/2010 02:05 PM, Eric Blake wrote:
> On 07/27/2010 05:44 AM, Christoph Dittmann wrote:
>> What I was going for was a script which executes another command with a
>> timeout.
>
> If you can assume the presence of GNU coreutils, use timeout(1). Much
> nicer for this
cripts, I'd be very interested to know if there are any obvious
blunders in the way I did it (or more subtle mistakes).
Also, is there a more elegant way to achieve the same effect? I thought
running a process with a time limit would not be such an unlikely thing
to do.
Christoph
minates due to the kill, no matter if it was in curly
braces or not.
How can the wait call affect a job it's not supposed to wait for?
Christoph
(I use "GNU bash, version 4.1.5(1)-release (x86_64-pc-linux-gnu)" on
Ubuntu 10.04.)
Command prompt:
Abbreviation of home path by tilde is not working when $HOME has a trailing
slash
reproduce:
export HOME=$HOME/
watch prompt
cheers
Christoph
For your info:
echo $PS1
${debian_chroot:+($debian_chroot)}...@\h:\w\$
From: [EMAIL PROTECTED]
To: bug-bash@gnu.org
Subject: Builtin command echo does not work properly.
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: cygwin
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash.exe' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='cygwin' -DCO
39 matches
Mail list logo
