Re: Missing semicolon tolerated after double-bracket [[ ]] expression

On Tue, 16 Sept 2025 at 01:46, Chet Ramey wrote: > On 9/15/25 10:46 AM, Robert Elz wrote: > > > If it was intended to mean "parsing the script" it would certainly say > so. > > Doesn't the fact that the discussion of token recognition includes the > references to s imply this? > There's an argum

Re: Missing semicolon tolerated after double-bracket [[ ]] expression

On Tue, 16 Sept 2025 at 04:08, Collin Funk wrote: > Worth mentioning that iswblank on some systems behaves like isblank > (only SPACE and TAB). This caused some problems in Coreutils [1]. > That would seem to me to be a case for including a replacement version of iswblank that can be deployed on

Re: [bug #67486] Can't use if with two separate awk floating number comparisons

Hi Branden On Wed, 10 Sept 2025 at 00:23, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > … Thankyou for pointing out that the headers are clickable. So it turns out that the “Mail Notification Carbon-Copy List” heading doesn't sit above an empty section. Nice to know. (On my scre

Re: [bug #67486] Can't use if with two separate awk floating number comparisons

On Tue, 9 Sept 2025 at 14:50, Oğuz wrote: > > Reply to this item at: > > > > Who thought this shit was a good idea? What's wrong with plain old e-mail? > I agree: the inability to submit *replies* by email is quite unsatisfactory. (This is compounded by h

Re: [PATCH] doc: missing parameter expansion operators in bash(1)

On Thu, 4 Sep 2025, 00:06 Chet Ramey, wrote: > If you think "significant parts" of the shell's behavior are undocumented, > either point them out or propose documentation patches. > Looking at doc/bash.1, the following are some features which I believe are intentional, and which yet are undocume

Re: [PATCH] command substitution with trailing newlines (was Re: [PATCH] Add shopts for ...)

On Sat, 6 Sept 2025 at 06:43, Chet Ramey wrote: > Anyone else have candidates for the command character? > How about if the lead character is newline? ${ *commands* } (Ordinarily I wouldn't suggest re-purposing “existing” syntax, but this feature has only existed for a brief while, so perhaps

Re: integer variable that unsets itself causes segfault

On Thu, 4 Sept 2025 at 23:56, Chet Ramey wrote: > > $ declare -in foo > > $ printf '%s\n' "${?}" > > 0 > > $ foo=bar > > $ printf '%s\n' "${?}" > > 0 > > $ declare -p foo > > declare -in foo="0" > > $ printf '%s\n' "${?}" > > 0 > > $ foo=12 > > bash: `0': not a valid identifier > > $ printf '%s\n

Re: [PATCH] command substitution with trailing newlines (was Re: [PATCH] Add

On Wed, 3 Sept 2025 at 07:17, Koichi Murase wrote: > 2025年9月3日(水) 1:21 Martin D Kealey : > > I really like this approach, but I suspect it will lead to a need > > for something akin to Perl's "use" or "BEGIN" keywords to execute > > code as soon

Re: [PATCH] command substitution with trailing newlines (was Re: [PATCH] Add

On Tue, 2 Sep 2025, 23:45 Koichi Murase, wrote: > I think, if an option to change the language behavior would be > introduced, the option should be implemented as ``a file-local option > that applies to shell codes based on lexical scoping''. > I really like this approach, but I suspect it will

Re: Bash exits with "Broken pipe" with process subsitution and sleep

On Tue, 2 Sep 2025, 03:55 Chet Ramey, wrote: > On 9/1/25 2:54 AM, Martin D Kealey wrote: > > - Brackets always ensure a subshell. > Parentheses. Brackets are [ and ] in bash and POSIX nomenclature. Sorry, dialectic slip of the tongue. I did indeed mean parentheses. Being told

Re: Bash exits with "Broken pipe" with process subsitution and sleep

On Mon, 1 Sept 2025 at 14:48, Oğuz wrote: > On Sunday, August 31, 2025, Maria wrote: > > > Bash exiting early with an exit code > > indicating a signal using nothing but a command line does not > > sound like expected behavior to me. > The « >(…) » construct was a game changer, especially when

Re: Bash exits with "Broken pipe" with process subsitution and sleep

On Mon, 1 Sept 2025 at 04:35, Maria wrote: > Bash will crash with exit code 141. For complicated historical reasons, when a process is killed by a signal, the parent shell pretends that it exited with a status of 128 plus the terminating signal number. This is why you see what looks like "exit

Re: [PATCH] doc: missing parameter expansion operators in bash(1)

On Thu, 28 Aug 2025 at 00:36, Chet Ramey wrote: > On 8/27/25 10:29 AM, Zachary Santer wrote: > > On Wed, Aug 27, 2025 at 10:19 AM Chet Ramey wrote: > >> On 8/26/25 6:40 PM, Zachary Santer wrote: > > Bash already provides one. You're just leaving it undocumented so > > you're more free to get rid

patch: (re)enable #ifdef processing within builtin help text

I tried adding documentation for declare -c but discovered that it wasn't honouring CASEMOD_CAPCASE. Looking at mkbuiltins.c, that appears to be because of the way that single_longdoc_strings is handled. So I figured I should fix that too. Attached herewith a patch to implement both. This will al

Re: [PATCH] doc: missing parameter expansion operators in bash(1)

On Sat, 30 Aug 2025 at 05:26, Chet Ramey wrote: > On 8/29/25 1:26 PM, Martin D Kealey wrote: > > > /In early proposals, a form $[expression] was used. It was functionally > > equivalent to the "$(())" of the current text, but objections were > lodged > >

Re: [PATCH] doc: missing parameter expansion operators in bash(1)

On Sat, 30 Aug 2025, 02:26 Chet Ramey, wrote: > There is no specification for how it behaves; I'll buy that when the shell is in POSIX mode, but when talking about Bash's extensions to POSIX, there's never been a full specification separate from the source code there is no expectation that > i

Re: [PATCH] doc: missing parameter expansion operators in bash(1)

On Thu, 28 Aug 2025, 04:20 Chet Ramey, wrote: > It was in early drafts of POSIX.2 (1003.2-1992). > > The feature started out as the compound command ((expr)) (draft 8), evolved > into a word expansion $[...] (draft 9), and then changed to $((...)) > (draft 11, the version I have was published in

Re: [PATCH] doc: missing parameter expansion operators in bash(1)

On Sat, 30 Aug 2025, 01:48 Chet Ramey, wrote: > > > > What was the rationale for preferring $((…)) over $[…] back when they > had a > > free choice? > > See if the POSIX rationale answers your question. > > > https://pubs.opengroup.org/onlinepubs/9799919799/xrat/V4_xcu_chap01.html#tag_23_02_06_04

Re: [PATCH] doc: missing parameter expansion operators in bash(1)

On Thu, 28 Aug 2025, 03:40 Chet Ramey, wrote: > This has never been documented. > If that's true, how are there scripts using it, and people asking about it? It's not just documentation that you've written that needs to be considered, because clearly this feature must be mentioned SOMEWHERE. I

Re: [PATCH] doc: missing parameter expansion operators in bash(1)

On Thu, 28 Aug 2025, 01:22 Connor Wilkins, wrote: > On 8/27/25 10:36 AM, Chet Ramey wrote: > > On 8/27/25 10:29 AM, Zachary Santer wrote: > >> Bash already provides one. You're just leaving it undocumented so > >> you're more free to get rid of it in the future? > > I'm leaving it undocumented to

Re: [PATCH] Add shopts for trailing newlines in command substitution and here strings

On Wed, 27 Aug 2025 at 15:16, Koichi Murase wrote: > > However, this isn't true. With these features implemented as shell > options, in general, one actually needs to write it in the following > way: > > local saved=$(shopt -p cmdsubst_trailing_nls) # (assume we are in a > function) > shopt -

Re: integer variable that unsets itself causes segfault

On Tue, 26 Aug 2025 at 00:28, Chet Ramey wrote: > On 8/23/25 11:40 PM, Martin D Kealey wrote: > > In other languages, binding and assignment are clearly different > > operations, where this would clearly NOT be "no different". > > Oh? > > int x = 0

Re: Time to retire archaic mis-use of grave accent as opening single quote?

primed for a fight. I am heartened and reassured by the responses indicating that there isn't much need for a fight now. At 2025-08-24T15:50:04+1000, Martin D Kealey wrote: > > I note that much of the documentation I should have been clearer: I'm talking about *all* documentation

Time to retire archaic mis-use of grave accent as opening single quote?

I note that much of the documentation still uses a quoting style that pretends that characters U+0060 and U+0027 are matching opening and closing quotes, and that new documentation is still being added that follows this style. For extra credit, they're sometimes redoubled as `` and '' to be fake do

Re: integer variable that unsets itself causes segfault

On Wed, 20 Aug 2025 at 00:15, Chet Ramey wrote: > No different than evaluating a variable value in an expression as an > expression. > In other languages, binding and assignment are clearly different operations, where this would clearly NOT be "no different". (Such malapropisms are, sadly, an of

Re: [PATCH] _rl_isearch_cleanup: avoid nested execution

On Thu, 21 Aug 2025 at 07:30, Chet Ramey wrote: > On 8/20/25 3:36 PM, Chet Ramey wrote: > The real issue is that readline […] does not > believe that read(2) can both succeed (return value > 0) *and* get a > signal before it returns to user mode without setting errno. […] > You either need to inj

Re: [PATCH] _rl_isearch_cleanup: avoid nested execution

On Thu, 21 Aug 2025 at 05:48, Grisha Levit wrote: > You can reproduce this by adding a key binding to your terminal emulator > to send \003\033 for some key combination. > Or if using a terminal emulator that doesn't support programmable bindings (or indeed, just for the simplicity): stty intr

Re: integer variable that unsets itself causes segfault

Hi Chet On Tue, 12 Aug 2025 at 01:18, Chet Ramey wrote: > On 8/9/25 1:09 AM, Oğuz wrote: > > $ declare -in x=a[x] > > $ echo $? > > 1 > > $ declare -p x > > bash: declare: x: not found > > Since you have -i, the a[x] expands to `0', which is an invalid name for > a namer

Re: Using history builtin with -ps options give unexpected results

Hi Dmitry On Mon, 11 Aug 2025 at 22:17, Шушуев Дмитрий wrote (in the attachment): > Description: > Using history builtin with -ps options give unexpected results > For example after executing: > dnf -q repoquery --list bash-doc | fold -w $(($COLUMNS/3-1)) | pr > -3tw $COL

Re: `kill --help` prints output of `help kill`

On Mon, 11 Aug 2025 at 13:19, Wiley Young wrote: > The reverse case applies with `getopts --help` vs. `getopt --help` as well > as with `dir --help` vs. `dirs --help`. Those would simply report 4 different messages (some of which might be complaints --help is an unknown option). Are you perhap

Re: docu: ) missing twice

Hello Martin On Thu, 7 Aug 2025, 03:07 Martin Schulte, wrote: > the closing brace is missing (see Bourne Shell Builtins > I spent 5 minutes trying to find any mention of braces and/or built-in commands in the referenced sections, and I was about to write a reply pointing out that braces are r

Re: Feature request (not a bug): enhanced variable substitutions would be nice.

-Martin On Tue, 5 Aug 2025 at 02:17, Stan Marsh wrote: > (I am talking about things like ${var:-default value}) > > I have long wished there was a substitution for "substitute a string if > var is unset > else substitute nothing". I've wondered about that myself at times. I like the idea, but

Re: sourc. can't handle /sys/block/*/uevent on Linux

On Tue, 15 Jul 2025, 03:46 Robert Elz, wrote: > | > This happens because /sys/block/*/uevent show up as regular files, > and > | > reports a file size of 4096 in stat: > | Which isn't the true file size. > > And I'd be reporting that as a kernel bug. But linux seems to be filled with crap

Re: parser bug in Q_ARITH

Missed a comma… On Mon, 14 Jul 2025, 03:43 Martin D Kealey, wrote > an expression would be parsed and then when executed [COMMA] the > expression itself - rather than the value resulting from evaluating it - > could be assigned to a variable. >

Re: parser bug in Q_ARITH

> > Since when is removal of recursive evaluation being mooted? > Not by me, but if we're going down the path of parsing numeric expressions at the same time as the surrounding shell commands, it would be useful to have some sort of lambda assignment, so an expression would be parsed and then when

Re: parser bug in Q_ARITH

On Thu, 10 Jul 2025 at 01:36, Chet Ramey wrote: > If the expression hadn't contained $x, nothing would have been expanded, > because expanding a word without any expansion characters is a waste of > time. This arguably causes a problem in this case; it would have been > more consistent to run the

Re: autoconf broken when forcing -Werror -pedantic

On Mon, 7 Jul 2025 at 13:03, Collin Funk wrote: > Martin D Kealey writes: > > it's SLOW. Any comments on this point? It seems like the main causes of inadequate speed are: (1) Lack of parallelism. (2) A monolithic probe-test-result cache structure, that's either "all

autoconf broken when forcing -Werror -pedantic

To help me find bugs in a range of projects, I have a wrapper around gcc that forces -Werror -pedantic. I expect to get a lot of errors during builds - that's the point - but what I didn't expect was for autoconf to be broken. The main problem is that autoconf fails to recognize a range of standar

Typo in bashline.c

diff --git a/bashline.c b/bashline.c index fb8aeea20..181585c5b 100644 --- a/bashline.c +++ b/bashline.c @@ -4142,7 +4142,7 @@ vi_advance_point (void) } } #else -rl_point++: +rl_point++; #endif return point; }

Re: parser bug in Q_ARITH

On Tue, 1 Jul 2025, 08:59 Zachary Santer, wrote: > It appears bash has made the parser more complex by selectively > removing the pre-expansion step for certain parts of expressions. > That's bad because the rules for when that happens are undocumented > [...] > By far the simplest approach for

Re: getcwd() returns with stale errno value upon error

On Thu, 26 Jun 2025 at 04:07, Oğuz wrote: > On Wednesday, June 25, 2025, Richard Weinberger > wrote: > > > > This can happen on filesystems where d_ino != st_ino > > i.e. a broken filesystem. Or not broken. There's a fairly obvious race condition where another process replaces a direc

Re: Unexpected behavior of ${x#word} and ${x/pat/str} in the case command

On Mon, 23 Jun 2025 at 19:02, Takaaki Konno wrote: > > x=abc > case def in > "${x#abc}"def) ;; > "${x##abc}"def) ;; > "${x%abc}"def) ;; > "${x%%abc}"def) ;; > "${x/abc/}"def) ;; > "${x//abc/}"def) ;; > "${x/#abc/}"def) ;; > "

Re: Incomplete cleanup in Bash with malformed heredoc in pipeline

On Thu, 19 Jun 2025 at 07:37, Alvaro Falagan wrote: > Bash does not clean up all its internal memory and leaves at least one file > descriptor (`/dev/pts/0`, fd 255) open at exit. Why would it be a problem if memory is still allocated or filedescriptors are still open at exit? Memory pages and

Re: IGNOREEOF is ineffective when holds a big integer

In variables.c at line 6243 we have eof_encountered_limit = (*temp && all_digits (temp)) ? atoi (temp) : 10; Presumably in your build of Bash, as in mine, `int` is 32-bit, so the maximum value convertible by atoi would be 2147483647. Larger values are returned modulo 4294967296 (with 2's complemen

Re: exec3.sub never finishes with huge argmax

Hi Joel On Sun, 8 Jun 2025 at 00:08, Joel Ebel via Bug reports for the GNU Bourne Again SHell wrote: > This is mostly an FYI, as I don't think our ridiculous environment needs to > be supported, but the E2BIG test in exec3.sub never finishes in our testing > environment due to ARG_MAX being set

Re: `help cut` doesn't document what -a does

On Thu, 5 Jun 2025 at 20:22, Duncan Roe wrote: > On Wed, Jun 04, 2025 at 09:43:00AM -0400, Chet Ramey wrote: > > Is it useful to combine multiple selected fields (-f) into one space- > > separated field so `cut' can put the selected portions of each line into > > a corresponding array element? >

Re: SourceAv in xparse_dolparen when trying to compare with rvalue

On Wed, 14 May 2025, 11:14 Александр Ушаков, wrote: > For reference, I believe this qualifies for a CVE because: > * It is a reproducible crash (DoS) in a security-sensitive component > (command interpreter). > By this logic, there should be a CVE for gcc because when you give it « int main (){

Re: Heap-buffer-overflow in read_token_word() when read element with -1 index

Hi Александр On Thu, 24 Apr 2025 at 03:30, Александр Ушаков wrote: > #define current_delimiter(ds) \ > (ds.delimiter_depth && !(ds.delimiter_depth - 1 < 0) ? > ds.delimiters[ds.delimiter_depth - 1] : 0) This seems unnecessarily complex; why not simply #define current_delimiter(ds) (ds.delim

Re: [sr #111211] `pipefail` leak/disablement

function safe_source() { > local saved_opts=$- > local pipefail_on=0 > > # Check if pipefail is set using 'shopt' > if (set -o | grep -q 'pipefail *on'); then > 'on' or 'off' is preceded by a tab character, plus arbitrary padding spaces, so that won't work. But it's a suboptimal a

Re: Ctrl+C during ~/.bashrc evaluation leads to unexpected behavior

It's important that sections of ~/.bashrc be ordered correctly to prevent such issues. Just because someone tells you to add something to the *end* of your .bashrc does not mean that's necessarily the best place to put it. 1) some boilerplate, including checking whether the shell is actually inter

Re: Bug: please document extended and alternate for loop syntax

On Tue, 11 Mar 2025, 00:54 John Wiersba via Bug reports for the GNU Bourne Again SHell, wrote: > The alternative is to have people, like me, stumbling on this > undocumented syntax and spending a considerable amount of time trying to > explore what it is and why it is undocumented. Hah! That's

Re: [sr #111166] ngettext syntax

On Mon, 24 Feb 2025 at 13:48, Phi Debian wrote: > I also forgot to mention that C99 introduced this > >There may be no gaps >in the numbers of arguments specified using '$'; for example, if > argu‐ >ments 1 and 3 are specified, argument 2 must also be specified > some‐

Re: "printf %d ''" should diagnose the empty string

On Sat, 8 Feb 2025, 17:48 Robert Elz, wrote: > > | and if the correspondence with strtol() is to be taken at face value, > | this would likewise imply that empty string is a valid representation > for > | zero, since strtol() reports that it has converted the entire string in > | that cas

Re: filedescriptor leakage, potential crash

On Sat, 8 Feb 2025 at 13:04, Oğuz wrote: > On Saturday, February 8, 2025, Martin D Kealey > wrote: >> >> ls -mU /proc/$$/fd >> ls -log /proc/$$/fd/99 >> > > They should appear in the output of `ls -l /proc/self/fd' in order for it > to be consid

Re: "printf %d ''" should diagnose the empty string

Hi Chet We seem to have very similar opinions about strong backwards compatibility in theory, and yet somehow we keep butting heads on how that pans out in practice. I'm concerned that the last ten years has seen a number of Linux distributions *stop* including Bash by default, and it has ceased

filedescriptor leakage, potential crash

Funny the bugs one finds when reading the source code to a program... I was looking at the usage of INPUT_REDIRECT and TRANSLATE_REDIRECT in execute_null_command() and thought “why compare against 8 values, when by re-ordering enum r_instruction in command.h, a simple range check would suffice?” Wh

Re: Documenting Bash’s Tilde Expansion in PATH: A Proposal for Clarity and Compatibility

On Tue, 4 Feb 2025 at 11:03, Zeffie via Bug reports for the GNU Bourne Again SHell wrote: > To address the above points, the following text (or similar language) is > proposed for inclusion in the Bash Reference Manual: > > *[...] * In interactive Bash sessions, any element of the `PATH` variabl

Re: -c option not working as expected

Bash is behaving correctly; this is not a bug in Bash. And this list is for reporting bugs, not fixing user scripts, so rather than spoon-feed you an explanation, I'm going to give you enough pointers to enable you to discover it for yourself. Start by reading what the manual says about reading co

Re: SHELLOPTS environment variable causes shell options to cascade

On Tue, 7 Jan 2025, 21:24 Tobi Laskowski, wrote: > the issue starts with misusing SHELLOPTS. Some folk have taken issue with my suggestion that SHELLOPTS is broken by design. Perhaps that was hyperbole, but it seems to me that if all possible uses for a feature actually constitute misuses, then

Re: SHELLOPTS environment variable causes shell options to cascade

On Sun, 5 Jan 2025 at 15:18, Oğuz wrote: > This is documented in the manual: > In other words, it's broken by design. > Try BASH_ENV instead: > > https://www.gnu.org/software/bash/manual/html_node/Bash-Variables.html#index-BASH_005fENV > Don't forget ENV as well, for sh scripts. -Martin

Re: make test errata (part 3)

» (I tests this on commit 49c2670226b045746d66765b23af37c1c7ba5597) (see first two parts for background) On Sun, 15 Dec 2024 at 00:35, Martin D Kealey wrote: > I've patched Bash to merge “shopt” and “set -o”, and now ... > Just to be clear, my new "options" module handles: (1

Re: Bash' code to store string of any characters containing pair of "" and '' at once

On Sun, 22 Dec 2024, 03:49 Budi, wrote: > How is Bash' code to store string of any characters should be containing > pair of "" and '' at the same time explicitly, being exact verbatim so, > ie. cannot be modified, escaped or etc, as expected from ordinary/naive > human writing), into a variable

Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active

On Sat, 21 Dec 2024, 04:01 Zachary Santer, wrote: > On Fri, Dec 20, 2024 at 11:50 AM Greg Wooledge wrote: > > I don't think your definition of "explicit" matches mine. > > ${variable} and ${| command; } are explicit expansions in the sense > that I had to write them in the script for the expansi

make test errata (part 2)

(see first part for background) I've patched Bash to merge “shopt” and “set -o”, and now “make tests” reports some minor differences. I would like some feedback on whether they're significant enough to warrant fixing. I've tried to mimic the current behaviour as closely as possible, including kee

make test errata

I'm trying to make sure that my modified version of Bash passes all the tests, and in the process I'm finding some, erm, oddities. Firstly, what seems to be a bug: Looking in tests/printf7.sub it has INT_MAX=$(getconf INT_MAX 2>/dev/null) [ -z "$INT_MAX" ] && INT_MAX=2147483647 # assume 3

Re: PIPESTATUS differs from $? for compound command

I started writing a response early in this thread and then set it aside. My initial impression was that excluding most compound commands from being reported in PIPESTATUS was at best questionable, but now I'm thinking otherwise. It is obviously useful to be able to inspect PIPESTATUS after compoun

Re: `complete -f` does not work at all.

On Fri, 6 Dec 2024, 15:12 Frederick Abell, wrote: > Description: > `compete -f`/`complete -A file` do not work at all, whilst `complete > -d`/`complete -A directory` work fine. > > $ cat > a_dir/ b_dir/ c_file d_file > > # I was expecting to only see c_file and d_file. Firstly this seems to

Re: Completion with -W fails if words contain ':'

On Wed, 4 Dec 2024 at 14:48, Keith Thompson wrote: > On Tue, Dec 3, 2024 at 10:20 AM Chet Ramey wrote: > > An easier workaround might have been removing `:' from COMP_WORDBREAKS. > > Sure, but that would affect all completions. I only want to change how > completions > work for my one custom com

Re: fg via keybind modifies tty settings

On Thu, 28 Nov 2024 at 13:54, David Moberg wrote: > Yes, if seems like the way to do this in bash. It's unfortunate because > doing it with a binding is more elegant as it avoids polluting the terminal > output and shell history. > You can avoid polluting history by inserting " fg\n" with a lead

Re: doc-strings of the 'command' built-in, as output by help

On Tue, 26 Nov 2024 at 12:43, Lawrence Velázquez wrote: > On Mon, Nov 25, 2024, at 9:03 PM, Martin D Kealey wrote: > > I keep "similar" there because ‘type -a COMMAND’ shows all possible > matches > > for COMMAND, whereas ‘command -V’ only does that when COMMAND is N

Re: String substitution bug

On Mon, 25 Nov 2024 at 22:22, Zachary Santer wrote: > On Mon, Nov 25, 2024 at 5:07 AM Martin D Kealey > wrote: > > > > How about this for a concrete proposal: let's split the current man page > > into a page per topic. The following list is alphabetical, though I &g

Re: doc-strings of the 'command' built-in, as output by help

On Tue, 26 Nov 2024 at 05:35, Andrew Davis wrote: > When running 'help command' in the shell, the output contains: > > > -vprint a description of COMMAND similar to the `type' builtin > > -Vprint a more verbose description of each COMMAND > > This seems to be opposite to the a

Re: "printf %d ''" should diagnose the empty string

How about a counter-proposal: when not in POSIX mode, arguments that correspond to numeric conversions in printf could be subject to normal arithmetic evaluation, so that « printf %d '6*7' » will output “42”. (Yes of course they should be subject to the single evaluation limit, regardless of any s

Re: String substitution bug

On Mon, 25 Nov 2024 at 00:21, Oğuz wrote: > In another document, not the manual. > If my suggested addition does not belong in the manual, then neither does *any* mention of "character class", nor indeed the entire existing description of "regular expression". Please provide a patch that removes

Re: String substitution bug

On Mon, 25 Nov 2024 at 01:08, Andreas Kähäri wrote: > I don't agree that the special parameters should be written as $! etc. > since those are their _values_ when used in the shell (exactness is a > virtue in a manual). > In a *printed* manual I would agree with you, but in a man page where the

Is Usenet defunct?

I don't see anyting wrong with the patch, but... +bug reports may be [...] posted to the Usenet newsgroup > .BR gnu.bash.bug . > Ummm? Does Chet still read Usenet? Does anyone else? -Martin PS: Sometimes I miss the good old days when Usenet was the social glue that held a small worldwide com

Re: String substitution bug

On Sun, 24 Nov 2024 at 18:05, Andreas Kähäri wrote: > I think the manual is quite clear: > > Within [ and ], character classes can be specified > using the syntax [:class:], where class is one of the > following classes defined in the POSIX standard: > alnum alpha

Re: history bug: new shell separates lines from the history file

Hello Michael The previously embedded lines (the for loop) now have got a timestamp (the > one from the shell start?)! > This is unwanted behavior, because now a cursor-up brings the separated > lines. > More precisely, any history read from a history file will *not* be in "command-oriented" mode

Re: "printf %d ''" should diagnose the empty string

at 06:23, Paul Eggert wrote: > On 2024-11-20 23:25, Martin D Kealey wrote: > > 2. There exist deployed scripts that rely on the current behaviour. > Any such scripts won't work on other shell implementations that do conform > to POSIX here. > Who said POSIX? My entire point ha

Re: "printf %d ''" should diagnose the empty string

On Thu, 21 Nov 2024 at 02:33, Paul Eggert wrote: there's little reason for Bash's non-POSIX mode to differ. > 1. One person's "failure to fail" is another person's "useful undocumented extension". 2. There exist deployed scripts that rely on the current behaviour. Does anyone think these are n

Re: "printf %d ''" should diagnose the empty string

On Wed, 20 Nov 2024, 07:36 Paul Eggert, wrote: > However, I don't see why Bash should differ from POSIX behavior. Bash > already diagnoses "printf %d x" and "printf %d ' '"; why should it be > silent about "printf %d ''"? > >From a semantic perspective, because "" doesn't contain any non-digits.

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

On Sun, 17 Nov 2024, 03:32 Chet Ramey, wrote: > On 11/16/24 3:36 AM, Martin D Kealey wrote: > I don't think a disclaimer saying "this manual is not what it does not > claim to be" is particularly useful. > That's valid, but how else do we get people to read the

Re: fg via keybind modifies tty settings

On Wed, 13 Nov 2024 at 01:49, Chet Ramey wrote: > On 11/10/24 7:14 PM, Martin D Kealey wrote: > > > Perhaps what's really needed is to make sure that "ordinary" commands > bound > > using bash -x are completely broken (so people won't try to

Re: fg via keybind modifies tty settings

On Sun, 17 Nov 2024 at 04:52, David Moberg wrote: > That looks very complicated, how do interpret that? And where/when to run > it? > To me this seems to have taken a wrong turn before the question was even asked. Just because readline has a "run a command" mode does NOT mean it's necessarily th

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

On Sat, 16 Nov 2024 at 15:01, Robert Elz wrote: > Date:Sat, 16 Nov 2024 14:05:17 +1000 > From: Martin D Kealey > Message-ID: d1_ebrgbusb2u1sxhyloqq...@mail.gmail.com> > > | I know, but "explicitly" is not the same as "highlighted

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

On Fri, 15 Nov 2024 at 00:20, Chet Ramey wrote: > On 11/13/24 11:40 PM, Martin D Kealey wrote: > > > The fact that pipeline components are implicitly run in subshells is > > arguably not highlighted well enough [...] > > The man page states that explicitly. > I kn

Re: [PATCH] Makefile.in: add LIBINTL_H to install-headers

On Thu, 14 Nov 2024 at 06:45, Chet Ramey wrote: > On 11/12/24 8:17 PM, Grisha Levit wrote: > > I'm not sure if this is the most idiomatic way to write the rule, but > > if a libintl.h is generated, it needs to make it into the installed > > headers directory to allow loadables to build. > AFAIK

Re: [PATCH] lib/readline/doc makefiles clean targets

On Thu, 7 Nov 2024, Chet Ramey wrote: > y.tab.h isn't part of the devel branch, you need bison to build it, and > it is included in the bash distributions. I see the problem here, though. > I'll figure out a way to fix it that's compatible with it being included > and not without too many releas

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

The disappearance of the variables that you export within your sourced file is not a feature of the source command. That will happen to ANY command that changes the shell's internal state, when run in a subshell. The fact that pipeline components are implicitly run in subshells is arguably not hig

Re: fg via keybind modifies tty settings

On Fri, 8 Nov 2024 at 05:19, Chet Ramey wrote: > The bind -x execution code could restore the terminal settings to icanon > mode before executing the command, and then set them back to what readline > is using (-icanon) before returning. This is not backwards compatible > and would break all the

Re: degraded error message in case of hash-bang interpreter error

On Mon, 4 Nov 2024, 21:37 Robert Elz, wrote: > | I guess I should s/POSIX/common Unix-like tradition/ and maybe > | mumble something about BSD. > > you'd need to go to *every* OS that exists … Good luck with that. Yeah I'm well aware this is futile whimsy. I should have raised this point ab

Re: degraded error message in case of hash-bang interpreter error

essage-ID: < > cah7i3lrjfhfgcejhmrmwd7mu2hu4r_oumvszw3esrc+3xqg...@mail.gmail.com> > > | On Monday, November 4, 2024, Martin D Kealey > | wrote: > | > | > POSIX says that the execve syscall reads the name of an interpreter > (and > | > options) from a '#!' line, > | >

Re: degraded error message in case of hash-bang interpreter error

This is one of those cases I would file under "POSIX being annoyingly literal". POSIX says that the execve syscall reads the name of an interpreter (and options) from a '#!' line, prefaces them onto the front of argv, and then restarts itself. This is why some people argue that ENOENT is "logical"

Re: [PATCH] Makefile: avoid undefined variables

On Sat, 26 Oct 2024, 00:05 Dmitry Goncharov, wrote: > >- cd $(@D) && $(MAKE) BUILD_DIR=$(UP)$(BUILD_DIR) > >top_srcdir=$(UPSRC)$(top_srcdir) $(MAKEFLAGS) $(@F) > > It is really not a good idea to pass makeflags on the command line as a > positional parameter. Agreed, but I was just copy

Re: [PATCH] Makefile: avoid undefined variables

On Fri, 25 Oct 2024 at 05:07, Grisha Levit wrote: > These are reported by make --warn-undefined-variables. > > Most were being set previously (sometimes 20 years ago) and got left > behind in recepies after their definitions have been removed. Others > only get set in some configurations so it ma

Re: recent typo in sig.c breaks Minix compilation

On Sat, 19 Oct 2024, 15:05 Oğuz, wrote: > > #ifdef FOO > if (foo && zot) > #else > if (bar && zot) > #endif > { > That's fine for the editors, but it's still a problem for "indent", as it produces nested indentation: #ifdef FOO if (foo && zot) #else if (bar && zot) #endif { …

Re: recent typo in sig.c breaks Minix compilation

On Fri, 18 Oct 2024, 13:09 Oğuz, wrote: > On Friday, October 18, 2024, Martin D Kealey > wrote: >> >> Talking of which, I note several places where there's a construct like: >> >> #ifdef FOO >> > if (foo && zot) >> > #else >> &

recent typo in sig.c breaks Minix compilation

It looks like a recent (last year) typo in sig.c breaks Minix compilation: $ git log a61ffa78ed^! > commit a61ffa78ede6df4d1127fddd2e8a1a77a7186ea1 > Author: Chet Ramey > Date: 2023-01-03 10:23:11 -0500 > second set of ANSI C changes: C89-style function declarations, more > inline functions

Re: procsub doesn't release the terminal without reading one byte

On Sun, 13 Oct 2024, 17:15 Oğuz, wrote: > On Sun, Oct 13, 2024 at 3:18 AM Chet Ramey wrote: > > You have two processes fighting over stdin. > > Why though? Can't bash just close the procsub's stdin when `:' returns? > Of course not. The operating system won't let processes meddle with each othe

Re: New feature

On Sat, 12 Oct 2024, 23:50 Saint Michael, wrote: > From: Saint Michael > Date: Sat, Oct 12, 2024 at 9:49 AM > Subject: New feature > > The command printf needs a new flag, -e, that would mimic that way the > same flag works with echo. > … > PROCEDURE_INFO=$(echo -e "${PROCEDURE_INFO}") > this s

  1   2   3   >