Re: UP does not invoke line history immediately

Hi Andrea This would appear to be an issue with the readline library, rather than Bash itself. As you've noted that it's timing-sensitive, I'm wondering if it's related to bytes received immediately prior, so to investigate this would it be possible to run Bash inside a "script" session, until y

Re: Unfortunate error message for invalid executable

On Sun, 29 May 2022, 06:56 AA via Bug reports for the GNU Bourne Again SHell, wrote: > Maybe the concern is that any additional calls (such as checking for path > existence) may have unintended consequences [but that] seems unlikely. > > Therefore, IMHO it is very hard to argue with the fact that

Re: Revisiting Error handling (errexit)

On Wed, 6 Jul 2022 at 08:34, Yair Lenga wrote: > in general, for complex scripts, I prefer to move the ‘main’ logic into a > function (‘main’, ‘run’,…). This make it possible to keep clean name space. > Otherwise, all the main variables are becoming global: see below for ‘x’. > With many variable

Re: Revisiting Error handling (errexit)

Modules can have conflicting requirements of global settings that require weird contortions to interoperate; so starting out by making this yet another global setting seems like a retrograde step. So I would like to propose an alternative approach. Firstly, I would reduce the action to simply "re

Re: Revisiting Error handling (errexit)

The old errexit explicitly exempts any command prefaced by ! which is important so that one can write ! (( x++ )) without it blowing up when x is 0 and without paying the penalty for "|| true". Does this new proposal honour that? Aside from that, I still think that yet another global setting is p

Re: $(( )): binary/unary VAR/NUM inconsistency

On Sat, 9 Jul 2022, 02:08 Chet Ramey, wrote: > On 7/8/22 11:03 AM, Steffen Nurpmeso wrote: > > > So you seem to use your own itoa, and here is (another) bash bug. > > Yeah, that's where stricter integer constant parsing would flag an error. > It's just an extension; bash handles everything POSIX

Re: Revisiting Error handling (errexit)

On Sun, 10 Jul 2022 at 05:39, Yair Lenga wrote: > Re: command prefaced by ! which is important: > * The '!' operator 'normal' behavior is to reverse the exit status of a > command ('if ! check-something ; then ...'). > Unless that status is ignored, in which case, well, it's still ignored. > *

Re: Revisiting Error handling (errexit)

Hi Yair One other comment: On Sun, 10 Jul 2022 at 05:39, Yair Lenga wrote: > The old 'errexit' logic was spec'ed many years ago. As far as I can tell, > it existed in bash 2.0, from 1996. I think requirements/expectations are > different now. The 'exit on error' error handling was good for 1996

Re: Arithmetic expression: interest in unsigned right shift?

Hi Steffen, thanks for that. It will be especially useful for defining (( MAXINT = ~0 >>> 1 )). This reminds me of some other operations I've been meaning to implement, including true modulus +% (where the sign of the result always matches the divisor) with the corresponding flooring division +/

Re: Arithmetic expression: interest in unsigned right shift?

Printf %u already reveals the word size, as do most kinds of overflow - albeit messily, like $((3**40)) At least by explicitly exposing the word size in a controlled manner, we can write code that avoids unintended overflow. -Martin On Sun, 17 Jul 2022, 11:54 Dale R. Worley, wrote: > Steffen

Re: Arithmetic expression: interest in unsigned right shift?

On Sun, 17 Jul 2022 at 17:01, Robert Elz wrote: > For just getting the word size, a better solution would be to request a > new predefined variable (eg: BASH_ARITH_BITS) which contains the number > of bits used for arithmetic. Inventing new mechanisms so you can compute > it dynamically is craz

Re: functions can fully unset local vars in other scopes

On Fri, 29 Jul 2022 at 18:51, Kerin Millar wrote: > 5.0 added a localvar_unset option that impedes the behaviour of 'popping' > from the outermost scope. > > $ bash -c 'x=foo; f1() { local x=bar; f2; x=baz; }; f2() { unset x; > declare -p x; }; f1; declare -p x' > declare -- x="foo" > declare --

Re: return exit code in EXIT trap

On Wed, 3 Aug 2022 at 08:06, Koichi Murase wrote: > 2022年8月3日(水) 5:57 Chet Ramey : > >> Until then, I'm going by the plain language of the standard. It seems >> more strange that POSIX would have intended this to mean only a `return' in >> the actual action string (A) instead of while the trap ac

Re: cut loadable outputs extra newlines

I note that https://pubs.opengroup.org/onlinepubs/009696699/utilities/cut.html says: *> The elements in list can be repeated, can overlap, and can be specified in any order, but the bytes, characters, or fields selected shall be written in the order of the input data.* The intention behind this is

Re: Re: add custom environment variable in bash source code

If you expect LD_PRELOAD to incorporate code into Bash itself, then you need to set it before you launch Bash; setting it once Bash is running is too late. What exactly is the LD_PRELOAD loading for you, and what does THAT do? On Thu, 18 Aug 2022, 09:19 , wrote: > Because I'm using Android, And

Looking to the future (was Re: Light weight support for JSON)

Not that I fundamentally disagree with this (JSON) proposal, but I'd rather see the effort put into support for nested arrays (like ksh has), and generally having a more forward-looking view of Bash as an evolving language. I would see this proceeding somewhat like the transition from Perl4 to Per

Re: Bash Coding style - Adopting C99 declarations

On Mon, 29 Aug 2022 at 09:14, Dmitry Goncharov wrote: > On Sunday, August 28, 2022, Andreas Schwab wrote: > > Note that the next revision of the C standard removes support for K&R > > declarations > > The code will continue to compile, won't it? > I expect "gcc -std=c23" will reject such code.

Re: bug-bash Digest, Vol 238, Issue 2

Rather than var[i1.i2.i3] I suggest a C-like var[i1][i2][i3] as that avoids ambiguity for associative arrays whose keys might include ".", and makes it simpler to add floating point arithmetic later. I would like to allow space in the syntax to (eventually) distinguish between an object with a fai

Supporting structured data (was: Re: bug-bash Digest, Vol 238, Issue 2)

Some things do indeed come down to personal preference, where there are no right answers. Then Chet or his successor gets to pick. Keep in mind that most or all of my suggestions are gated on not being in backwards-compatibility mode, and that compat mode itself would be lexically scoped. With tha

Re: Supporting structured data (was: Re: bug-bash Digest, Vol 238, Issue 2)

On Wed, 7 Sept 2022 at 18:13, Yair Lenga wrote: > Thanks for providing feedback and expanding with new ideas. > > I believe the summary is: > > ${a.key1.key2} - Static fields > ${a.key1.$key2} - Mixed dynamic/static, simple substitution. > ${a.key1.{complex.$key2}} - For complex keys that may co

Re: Bash reference manual feedback

I believe you are correct on all points except this one: On Mon, 12 Sept 2022 at 01:30, David Apps wrote: > h3 6.12 Shell Compatibility Mode > > > * the shell does not print a warning message if an attempt is made to > > use a quoted compound assignment as an argument to declare (declare -a > >

Re: self-reference to assoc.-array variable

Regression appears to have occurred between bash-5.0.18 and bash-5.1-alpha at commit 712f80b0. (I note that this commit is missing from the master branch, which only includes bash-5.0.17 at commit.) I tried to find the change in the devel branch, but ugh, git diff between devel & master is unhelpf

Re: declare -F incorrect line number

I write nested functions quite often, usually with a subsequent `unset -f` but sometimes (necessarily) without. Being able to write `local -F funcname { ... }` or `function -L funcname { ... }` would be a nice replacement for the former, but the latter is usually about different phases of executio

Re: bash core dumps doing glob pattern on long string

On Sun, 9 Oct 2022 at 18:07, Phi Debian wrote: > I was looking at a bug on ksh93 that is "core dumps doing glob pattern on > long string" and it happen that bash > suffer the same. > > $ [[ $(printf '%010d' 0) == +(0) ]] > > I see 3 way of fixing this > > 1) [...] string should be limited to

Re: declare -F incorrect line number

You do realize that there are no "nested functions" in bash, right? Graycat, talk to me on Libera if you really doubt my understanding. All functions exist in a single, global function namespace. > > unicorn:~$ bash > unicorn:~$ f() { g() { echo I am g; }; } > unicorn:~$ f > unicorn:~$ type g >

Re: bash core dumps doing glob pattern on long string

d need a stack to be treated as magic match-never tokens. I say "extglob", but this would also speed up silly ordinary globs like [a-z]*[a-z]*[a-z]*[a-z]*[a-z]*[a-z]*[a-z]*[a-z]*[a-z]*[a-z]*[a-z]*[a-z]*[a-z] -Martin On Tue, 11 Oct 2022 at 15:57, Phi Debian wrote: > > > On Tue,

Re: bash "extglob" needs to upgrade at least like zsh "kshglob"

This seems like a good reason to simply translate extglobs into regexes, which should run in linear time, rather than put effort into building and debugging a parallel implementation. -Martin PS: While we're about it, can we please fix the expansion of « a/*/b/c/d/* » so it only calls readdir on

Re: Subsequent Here Doc/String Never Evaluated in Process Substitution

On Fri, 28 Oct 2022 at 20:37, wrote: > Thank you for the awesome shell. I noticed the following after upgrading > from 5.1.16-3 to 5.2.2-2 on Fedora. It actually resulted in a minor > amount > of data loss. After fixing the attached file to remove the carriage returns, I was able to reproduce

Re: Multiline editing breaks if the previous output doesn't end in newline

This sounds like a bug in whatever is producing the output. POSIX text files have a newline terminating every line; that description includes streams going through pipes and tty devices if they purport to be text. It's fairly simple to fix this by adding this to the end of your .bashrc (or the sys

Re: bash "extglob" needs to upgrade at least like zsh "kshglob"

On Sat, 29 Oct 2022 at 22:15, Greg Wooledge wrote: > On Sat, Oct 29, 2022 at 04:50:00PM +1100, Martin D Kealey wrote: > > This seems like a good reason to simply translate extglobs into regexes, > > which should run in linear time, rather than put effort into building and

Re: bash "extglob" needs to upgrade at least like zsh "kshglob"

the OS. The hard part is what to do with (!LIST), which was the point of my previous post. -Martin On Sun, 30 Oct 2022 at 23:35, Oğuz İsmail Uysal wrote: > On 10/30/22 3:25 PM, Martin D Kealey wrote: > > How much faster do you think it can be made? > I don't know, irrelevant though.

Re: string substitution broken since 5.2

I now very much regret not commenting on this proposal during the pre-release period, and I apologise for not having done so. On Fri, 4 Nov 2022, 05:50 Chet Ramey, wrote: > > The option is enabled by default. If you want to restore the previous > behavior, add `shopt -u patsub_replacement'. > I

Re: [bash 4] 'test -v 1' is never true

The expansion `$[var+replacement}` was part of the Bourne shell when I used it in 1985 (before POSIX was first published), whereas `test A -gt B` is rather newer, and `test -v` is only a Bash extension (and similarly wasn't added until later). The man and info pages have retained the rather terse

Re: declare XXX=$(false);echo $?

On Fri, 2 Dec 2022 at 20:28, Ulrich Windl wrote: > Surprisingly "declare XXX=$(false);echo $?" outputs "0" (not "1") > "Surprising" is subjective. There is no indication in the manual page that "declare" ignores the exit > code of commands being executed to set values. > Framing this as `decla

Re: BASH_XTRACEFD=1 read variable stdout flushing?

On Tue, 17 Jan 2023 at 03:36, wrote: > The following script attempts to read the first column of data, line by line, into a variable called `$var`. With `BASH_XTRACEFD` unset, it propertly prints r1c1, r2c1, r3c1, r4c1. With `BASH_XTRACEFD=1`, `$var` gets set to +, ++, r2c1, r3c1, r4c1. Maybe I a

Re: 'exec -a' and $0 substitution

On Thu, 26 Jan 2023, 09:37 Sergei Trofimovich, wrote: > To the bug: looks like 'exec -a' does not work for bash scripts, but does > work for other executables. > Be aware that the kernel is responsible for interpreting #! lines, not bash. The kernel does several steps when it encounters an exec

Re: SIGINT handling during async functions

Firstly, let's just leave aside "POSIX requires this" for a bit. I know that the requirement is there, and I think it is one of those broken things that ought to have been dropped from POSIX, or at least reduced to optional rather than required. On Tue, 24 Jan 2023 at 07:35, Chet Ramey wrote: >

Re: unset does not remove functions like a[b] unless -f is specified

> ...in posix mode, fname must be a valid shell name and may not be the name > of one of the POSIX special builtins. > In default mode, a function name can be any unquoted shell word that does > not contain $. ... > I'm guessing the intention is that it shouldn't contain any expansions, so it als

Re: SIGINT handling during async functions

On Fri, 3 Feb 2023 at 07:17, Chet Ramey wrote: > On 1/28/23 5:56 AM, Martin D Kealey wrote: > > Firstly, let's just leave aside "POSIX requires this" for a bit. > Be that as it may, POSIX exists and this is a requirement. It's also how > other shells behave. &

Re: Regression in pattern substitution with compat42

On 8 Feb 2023 at 18:50Z Tom Briden wrote: > Bash Version: 5.2 > Patch Level: 15 > Release Status: release > > As of version 5.2-beta, replacing a single backslash with a double backslash > is no longer possible when using BASH_COMPAT=4.2. On 9 Feb 2023 at 15:57Z Chet Ramey wrote: > shopt -u patsu

Re: "builtin jobs" does not output to stdout.

The contorted rules for reporting the state of the parent shell suggest that maybe the entire approach needs re-thinking. Several approaches come to mind. 1. Create a built-in “parent” command where “parent ulimit” or “parent trap” answers based on the parent shell rather than the subshell itself

Re: Regression in pattern substitution with compat42

On Tue, 14 Feb 2023 at 01:00, Chet Ramey wrote: In this case, the behavior is controlled by an option. You just don't like > the default setting. > We had this exact same discussion back in November. > Too right I don't like it, and the previous discussion was wholly unsatisfactory. I do not un

Re: Bash 5.2 breaks our Arch Linux devtools

On Wed, 15 Feb 2023 at 23:29, Tobias Powalowski via Bug reports for the GNU Bourne Again SHell wrote: > Hi, > latest 5.2.x seems to have introduced a change in shopt extglob: > https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/133 > I'm not sure if my proposed fix for this is corre

Re: Having an alias and a function with the same name leads to some sort of recursion

On 2/14/23 2:58 PM, Dale R. Worley wrote: > Though I think by "keyword" he means "reserved word". > Yes, though in my defense, the bash man page liberally uses the term "keyword". On Fri, 17 Feb 2023 at 01:14, Chet Ramey wrote > I think the issue is that he's applying a grammar interpretation

Re: Cmd history is not displaying correctly

I suspect the history file is corrupt; truncating a file while another process has it open for writing can do strange things. On Sun, 19 Feb 2023, 23:05 Mr. Dick Steel, wrote: > WARNING: The following will REPLACE your > current .bash_history file! Take care. > > 1. Start you term

Re: Document that here strings don't support brace expansion.

I suggest avoiding enumerating exclusions (including removing any existing ones), and adding an explanation that "expansions that can produce multiple words are excluded". On Wed, 15 Mar 2023, 15:52 Alex Bochannek, wrote: > Chet, > > Thank you for the thoughtful responses. My thoughts below got

Re: $SECONDS and timeout values use realtime `gettimeofday()`

On Fri, 24 Mar 2023 at 10:42, William Kennington via Bug reports for the GNU Bourne Again SHell wrote: > It would be nice if $SECONDS was using `clock_gettime(CLOCK_MONOTONIC, > &val)` as it would usually make the most sense when you want to know the > time since the script started. Generally n

Re: [PATCH 3/4] Port unwind protection to C23

While C has never guaranteed that pointers all have the same size & alignment, POSIX does provide this guarantee, although indirectly (it has to be true for dlsym() to work, for example). Bash seems to need an environment that's "kinda POSIX" (at least emulating the POSIX process & signal models),

Re: [PATCH 3/4] Port unwind protection to C23

On Mon, 27 Mar 2023 at 18:35, Paul Eggert wrote: > The problem can also occur on platforms where calling conventions differ > depending on type even if the two types have the same representation, and > this can (and has) occurred on platforms with linear address spaces. > Indeed, this is *normal

Re: Junk at the end on history

Is there any chance that your history contains a raw escape sequence that trigger the terminal to report attributes using `CSI…c` as described in the first answer to https://stackoverflow.com/questions/29939026/what-is-the-ansi-escape-code-sequence-escc Using "tail" would limit the output to just

Re: history fails with - in string

"Word" means something different in history expansion than it does in the rest of the shell, because it happens before the normal lexical processing. In effect, it means the same as an identifier in C. A history expansion consists of a line selector (!cmdname) optionally followed by colon and a wo

Fwd: EOF at PS2

On Thu, 4 May 2023 at 05:20, Chet Ramey wrote: > On 4/26/23 5:38 PM, Grisha Levit wrote: > > The setting of ignoreeof is ignored at PS2: > > > > bash --norc -o ignoreeof > > $ uname \ > >> ^D > > Linux > > (bash exits) > It's never been active in this situation, because it doesn't meet the > cri

Re: `wait -n` returns 127 when it shouldn't

On Wed, 17 May 2023 at 03:35, Aleksey Covacevice < aleksey.covacev...@gmail.com> wrote: > Description: > `wait -n` sometimes returns with status code 127 even though there are > unwaited-for children. > > Repeat-By: > The following script does finish after a while: > > waitjobs() { > local sta

Re: `wait -n` returns 127 when it shouldn't

On Thu, 18 May 2023 at 02:13, Chet Ramey wrote: > It's possible for the shell to reap both background jobs before `wait -n' > is called. The underlying function returns < 0 when there aren't any > unwaited-for jobs, which the wait builtin translates to 127. > I know that some platforms (used to?

Re: setarray[unsetkey] doesn't trigger nounset in arithmetic context

(I assume this is a continuation of the discussion in #bash on Libera.chat yesterday?) The primary use of `set -u` is to detect misspelled variable names, and misspelled keys for associative arrays seems like a reasonable extension of that, if you assume that they're in some sense a fixed list, li

Re: setarray[unsetkey] doesn't trigger nounset in arithmetic context

I was heading with my suggestion about non-sparse arrays. On Mon, 22 May 2023 at 07:01, Martin D Kealey wrote: [...] > 2. ${#array[@]} gives the number of elements rather than the last index > (minus 1). Being able to declare an array as non-sparse (so that all gaps > "exist" with some default value) would fix this. > -Martin

Re: setarray[unsetkey] doesn't trigger nounset in arithmetic context

On Mon, 22 May 2023, 12:59 Emanuele Torre, wrote: > I am not really proposing a major change to the behaviour of nounset, I > am only pointing out the incorrect bash behaviour for that case. I disagree: this would constitute a major change, breaking behaviour that is (for good reasons) depended

array size vs index of last element (was Re: setarray[unsetkey] doesn't trigger nounset in arithmetic context)

On Tue, 23 May 2023 at 23:32, Chet Ramey wrote: > On 5/22/23 10:56 PM, Martin D Kealey wrote: > > > For example, if one is filling an array in random order, rather than > > progressively adding to the end, then it is useful and makes sense to be > > able to ask the arr

bug-bash@gnu.org

On Sun, 11 Jun 2023, 09:31 Grisha Levit, wrote: > The command printing code can fail to add a required semicolon when the > last word in the command ends with `&' > This could be obviated by unconditionally outputting a newline instead of a semicolon. I acknowledge that this style isn't to ever

Re: Command execution by creating file.

The assertion "should just print the name of [the] file" is mistaken. You seem to have conflated autocompletion (which occurs while typing, usually in response to the TAB key, which is prior to parsing a command which in turn is prior to invoking it) with filename generation (which occurs as a lat

Re: problem with continuation prompt on newlines with history back

Hi Alex Is your history set to line mode or command mode? This changes whether recalling a multi-line history item gets put in the input buffer all at once or only one line of it, and that in turn changes whether you see PS2 in between the lines. On Sat, 24 Jun 2023, 03:34 alex xmb ratchev, wrot

Re: Enable compgen even when programmable completions are not available?

Hi Eli How about using the shell itself to parse the output of "typeset" (an alias for "declare"), but redefining "declare" to do something different. This is a bit verbose but it works cleanly: ``` ( function declare { while [[ $1 = -* ]] ; do shift ; done printf %s\\n "${@%%=*}" }

Re: Enable compgen even when programmable completions are not available?

n Mon, 26 Jun 2023 17:09:47 +1000 > Martin D Kealey wrote: > > > Hi Eli > > > > How about using the shell itself to parse the output of "typeset" (an > alias > > for "declare"), but redefining "declare" to do something different. This >

Re: $((expr)) allows the hexadecimal constant "0x"

On Thu, 29 Jun 2023 at 19:45, Denys Vlasenko wrote: > IIRC bash used to allow numeric constants of the > BASE#DIGITS form even if the DIGITS part was empty. > IOW: not only "64#0", but "64#" too was accepted > as a valid zero constant. > > This no longer works in 5.2.15, probably better than > fo

Re: maybe a bug in bash?

On Thu, 29 Jun 2023 at 23:42, Greg Wooledge wrote: > The answer to this is [...] just ssh in as root instead of nonroot + sudo. > > Some folks will scream that this is a bad idea, horrible practice, can't > do it, etc. These folks are idiots. Ssh can be configured to allow root > logins only w

Re: [PATCH 1/2] <<# indent-stripping heredoc

On Fri, 14 Jul 2023 at 09:47, Grisha Levit wrote: > This patch implements the ksh93-style <<# redirection operator to enable > indentatable heredocs. On the whole I think this is great, and thankyou for working up the patch, but I would like to offer some comments and suggestions: Firstly, it'

Re: [PATCH 1/2] <<# indent-stripping heredoc

On Sat, 15 Jul 2023, 10:18 Dennis Williamson, wrote: > Would a declared spaces-per-level indent amount be useful? Something like > <<4# that would be the script writer's responsibility to conform to since > they set it. This might be in addition to the already proposed <<#. > I briefly pondered

Re: slash appended to tab so its two // at end

Hi Alex On Wed, 19 Jul 2023 at 12:01, alex xmb ratchev wrote: > i in 5.2.15 bash aarch64 termux did > > $ cp -ap db2.*/ > What does your bash say in response to this: $ type -a $( ( complete -p cp || complete -p -D ) 2> /dev/null | tee -a /dev/stderr | sed -n 's/.* -F \([^ ]*\).*/\1/p' ) -Mart

Re: problem anomalies , possibly aliases related

Hi Alex Aliases are not functions, and they don't work the same way. A function is like a separate script, except that it runs in the same process & context as the caller. Its meaning is determined as the script RUNS. An alias is quite different: it replaces tokens while the script is being PARSE

Re: problem anomalies , possibly aliases related

On Thu, 20 Jul 2023, 18:03 Grisha Levit, wrote: > Sounds like you want all the commands in the alias to be executed as a > group -- so you can just write it as one: > > alias bad='{ echo fail; continue; }' > That right there USED to work as a function: bad() { echo fail; continue; } But then

Re: problem anomalies , possibly aliases related

On Thu, 20 Jul 2023, 23:28 Greg Wooledge, wrote: > The idea that this would "work" is quite surprising to me. Shell functions are SO unlike functions in other languages that it surprises me that anyone would assume any particular parallel holds. Everything about them is dynamic: where they fin

Re: problem anomalies , possibly aliases related

On Fri, 21 Jul 2023, 04:09 Greg Wooledge, wrote: > On Fri, Jul 21, 2023 at 12:33:07AM +1000, Martin D Kealey wrote: > > Saying that this *ought* to be done using aliases is not reasonable, as > it > > means forgoing the other stuff that functions can do, like taking > &g

Re: comments inside command subst are handled inconsistently

On Thu, 27 Jul 2023, 18:31 Denys Vlasenko, wrote: > Try these two commands: > > $ echo "Date: `date #comment`" > Date: Thu Jul 27 10:28:13 CEST 2023 > > $ echo "Date: $(date #comment)" > > )" > Date: Thu Jul 27 10:27:58 CEST 2023 > > > As you see, #comment is handled differently in `` and $(). >

Re: git amend commit with backticks on cli causes tty to crash

On Fri, 21 Jul 2023, 03:31 Wiley Young, wrote: > The first time I saw this bug, tty3 crashed and isn't available any more > in /dev/pts . Partially reproducing the bug, ttys have crashed but they > become available for use again when I press Ctrl-Shift-t from > xfce4-terminal. > Point of order,

Re: comments inside command subst are handled inconsistently

On Sun, 30 Jul 2023, 08:22 Chet Ramey, wrote: > On 7/28/23 1:51 PM, Martin D Kealey wrote: > > > maybe it's time to start issuing a warning > > when [backticks are] used at all? 🤪 > > There's no reason to use `` over $(...), but that form is still a required

Re: ! history expansion occurs within arithmetic substitutions

On Tue, 8 Aug 2023, 23:24 Zachary Santer, wrote: > Description: > Similarly, history expansion occurs within arithmetic substitutions. This > will never, ever be what the user wants. Correction: it will never ever be what YOU want. I can certainly think of uses for history expansion in arithmet

Re: ! history expansion occurs within arithmetic substitutions

On Sat, 12 Aug 2023, 02:29 Dale R. Worley, wrote: > … The line is broken into words in the same fashion as when reading > input, so that several metacharacter-separated words surrounded by quotes > are considered one word. … I think it would be helpful to start this sentence with "The selected

Re: ! history expansion occurs within arithmetic substitutions

On Tue, 15 Aug 2023 at 01:41, Chet Ramey wrote: > On 8/11/23 4:19 PM, Martin D Kealey wrote: > > I think it would be helpful to start this sentence with "The selected > > line…", to differentiate from the line just entered containing a "!". > > It

Re: Assignment to RO variable

On Wed, 16 Aug 2023 at 14:24, Dennis Williamson wrote: > Your use of colon as a comment character is confusing. > Colon is only confusing if one mistakes it for a comment. Colon is not a comment, it's a command, and therefore included in xtrace output. Of course, the real problem is that colon'

Re: SLA Information

This has come to the bash-bug volunteers mailing list. Many of us, myself included, offer software consulting services, and would happily provide the support you seek, but it would be helpful if you could clarify the type of support that you're looking for: (a) bug fixes for bash itself, or (b) su

Re: using exec to close a fd in a var crashes bash

On Sun, 20 Aug 2023, 14:15 Grisha Levit, wrote: > [...] it would probably make sense to undo them if the exec fails and the > shell is not going to exit. > Just one question: how? The sequence of dup2() and close() calls has to occur before the execve() call. Whilst they could be undone by usin

Re: using exec to close a fd in a var crashes bash

On Wed, 23 Aug 2023, 05:29 Greg Wooledge, wrote: > Excuse me now, while I go and close several open FDs in the shell where > I tested something the other day, which I had no idea were left open. > It's even worse than that; try: echo Hi {X}>/dev/null ls -l "/proc/$$/fd/$X" -Martin >

Re: using exec to close a fd in a var crashes bash

On Wed, 23 Aug 2023, 12:20 Greg Wooledge, wrote: > > echo Hi {X}>/dev/null > > ls -l "/proc/$$/fd/$X" > > That's a really strange example. I wonder what would lead someone to > write that particular redirection. Oh I merely wanted to point out that the redirection persists beyond the echo comm

Re: give_terminal_to() / maybe_give_terminal_to() race

On Fri, 1 Sep 2023, 15:51 Earl Chew, wrote: > The controlling terminal must be reconfigured before the parent gets to > wait() for the job, and before the child gets to exec() the program (or their equivalents). This second point makes sense, but I don't really see why the first point is nece

Re: RFC: changing printf(1) behavior on %b

If compatibility with C is really that important, shouldn't we be fixing %c? Its current behaviour as a synonym for %.1s doesn't provide significant utility, and arguably differs from C's "take an int and output the corresponding single byte", not "take the first byte of a string and output that".

Re: Warn upon "declare -ax"

On Wed, 6 Sep 2023, 01:46 Kerin Millar, wrote: > My pet name for it is arrayshock. > > $ arr=(foo bar baz) > $ export arr > $ env | grep ^BASH_ARRAY_ > BASH_ARRAY_arr%%=([0]="foo" [1]="bar" [2]="baz") > $ ./bash -c 'declare -p arr' > declare -ax arr=([0]="foo" [1]="bar" [2]="baz") > I've often w

Re: variable set in exec'ing shell cannot be unset by child shell

On Sat, 14 Oct 2023 at 06:33, Robert Elz wrote: > The issue we have (which possibly might be similar in bash, but only > possibly - but it would explain the symptoms) is that when one does > > VAR=value command > > "VAR" is essentially made a local variable for command, so its value > in

Re: variable set in exec'ing shell cannot be unset by child shell

On Sun, 15 Oct 2023, 03:05 Greg Wooledge, wrote: > On Sat, Oct 14, 2023 at 12:55:21PM -0400, Ti Strga wrote: > > it's just the "[[ -v foo ]]" tests to see where along the cloning > process we are. > > *Shudder* > Likewise, b. If the *real* goal is to overwrite a running script with a new ve

Re: variable set in exec'ing shell cannot be unset by child shell

On Sun, 15 Oct 2023, 03:15 Ti Strga, wrote: > On Fri, Oct 13, 2023 at 5:59 PM Grisha Levit > wrote: > > IMHO you'd be better off just putting a `{` line at the start and `}` > line at the end of your scripts > The big weakness of the "{}" approach is that if a writer forgets to do > that, there

Re: variable set in exec'ing shell cannot be unset by child shell

On Sun, 15 Oct 2023, 02:03 Robert Elz, wrote: > Date:Sat, 14 Oct 2023 14:46:12 +1000 > From: Martin D Kealey > Message-ID: a2+3nnknhm5a+...@mail.gmail.com> > > > | Back when I used the Bourne Shell we didn't have `local`, so we used to

Re: bash tries to parse comsub in quoted PE pattern

On Wed, 18 Oct 2023 at 22:19, Zachary Santer wrote: > On Tue, Oct 17, 2023 at 5:56 PM Emanuele Torre > wrote: > > > bash-5.1$ letters=( {a..z} ); echo "${letters["{10..15}"]}" > > k l m n o p > ... > So how important is it to maintain undocumented behavior? > This is the expected outco

Re: test -lt inconsistent about white space

I'm more concerned that the error message is misleading; "integer expression expected" is NOT true; rather an integer LITERAL is expected (meaning an optional sign followed by one or more digits). As for fixing the inconsistency, I would rather get rid of whitespace skipping entirely, perhaps with

Re: Command hangs when using process substitution

Perhaps some background would help here; I start by highlighting this section in "man xclip": -l, -loops number of X selection requests (pastes into X applications) to wait for before exiting, with a value of 0 (default) causing xclip to wait for an unlimited number of reques

Re: $((expr)) allows the hexadecimal constant "0x"

Apropos the intentional breakage of ((10#$X)) I wrote (back in June 2023): > > Is there any chance this can be reversed before it becomes an official release? to which Chet replied: > This happened years ago. I have to admit that I'm finding that being a maintainer for a large suite of Bash script

Re: $((expr)) allows the hexadecimal constant "0x"

On Sun, 10 Dec 2023, 12:15 Zachary Santer, wrote: > On Thu, Nov 30, 2023 at 5:19 AM Martin D Kealey > wrote: > > > > This change will break scripts that use $((10#$somevar)) to cope with > > > > somevar having leading zeroes OR BEING EMPTY. > Beside the point, b

Re: $((expr)) allows the hexadecimal constant "0x"

On Mon, 11 Dec 2023 at 06:55, Chet Ramey wrote: > It came up as a bug report in > > https://lists.gnu.org/archive/html/bug-bash/2019-06/mstheng00042.html > > > (part of the followup discussion after the second linked thread above

Re: issue with debug trap

On Sat, 16 Dec 2023 at 07:21, Giacomo Comes wrote: > debugon () { > trap 'if (($?)); then echo "$((LINENO-1)): $(sed -n "$((LINENO-1))p" > "$0")" ; fi' DEBUG > } > debugoff () { > trap '' DEBUG > } > > Although LINENO is the command that's about to be executed, that does not imply that LI

Re: complete NAME seems to diasable completion for NAME in the case of git

On Fri, 22 Dec 2023, 05:55 Andreas Schwab, wrote: > If you want to print existing completions, use > complete -p [NAME...]. > The problem is, there's a documentation error. "help complete" says "if no options are supplied…" when it should say something more like "if the -p option is given, or i

Re: $((expr)) allows the hexadecimal constant "0x"

On Tue, 12 Dec 2023, 05:56 Zachary Santer, wrote: > On Mon, Dec 11, 2023 at 9:26 AM Chet Ramey wrote: > > Part of the issue here is that distros -- Red Hat, at least -- never > > upgrade the version of bash they started with. Red Hat will `support' > > bash-4.2 as long as they support RHEL 7. >

Re: document that read built-in can't return zero-length string in the middle of input

Random irreversible behaviour change strikes again. This changed in Bash 4.3.0, and to make matters worse, shopt -s compat42 does not restore the previous behaviour. Up to Bash 4.2, read -N1 would indeed set the receiving variable to empty while returning a zero status, having read only one byte.

  1   2   3   >