Re: Brace expansion change on devel

x issue with redirections to bash input file descriptor; >> new minimal chmod builtin; posix mode change for kill builtin return >> status; perform additional validation on brace expansion sequence >> expressions > > The rationale for this change is to identify brace expansio

Re: Tilde expansion in PATH in POSIX-Mode

Hello Lawrence! Am Fri, 30 May 2025 04:53:06 -0400 schrieb Lawrence Velázquez : > Your example commands demonstrate something else. The command > > PATH=~/foo:~/bar > > has always assigned a value like '/myhome/foo:/myhome/bar', POSIX > mode or not. This is broken in bash 5.1 POSIX mode

Re: Tilde expansion in PATH in POSIX-Mode

On Fri, May 30, 2025, at 3:36 AM, Martin Schulte wrote: > https://www.gnu.org/software/bash/manual/bash.html#Bash-POSIX-Mode says: > > 19. Literal tildes that appear as the first character in elements of > the PATH variable are not expanded as described above under Tilde > Expansi

Re: Tilde expansion in PATH in POSIX-Mode

Le 30/05/2025 à 09:36, Martin Schulte écrivait : Hello, https://www.gnu.org/software/bash/manual/bash.html#Bash-POSIX-Mode says: 19. Literal tildes that appear as the first character in elements of the PATH variable are not expanded as described above under Tilde Expansion. Is this no longer

Tilde expansion in PATH in POSIX-Mode

Hello, https://www.gnu.org/software/bash/manual/bash.html#Bash-POSIX-Mode says: 19. Literal tildes that appear as the first character in elements of the PATH variable are not expanded as described above under Tilde Expansion. Is this no longer true from version 5.2 on? $ bash--posix

Re: Brace expansion change on devel

builtin; posix mode change for kill builtin return status; perform additional validation on brace expansion sequence expressions The rationale for this change is to identify brace expansions that contain multiple expressions, some valid and some not. The examples added to the tests show what I mean

Brace expansion change on devel

return status; perform additional validation on brace expansion sequence expressions the following behaves differently: $ echo {a,../a.cfg} {a,../a.cfg} # with devel vs $ echo {a,../a.cfg} a ../a.cfg # with 5.2_p37 Does this constitute a valid sequence expression? The documentation implies that

Re: Surprising behavior with inline environment variable expansion

On Mär 31 2025, Chet Ramey wrote: > It's hard to see these as being useful if they're glibc-specific. They are coming from ISO TR 14652 and 30112. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely

Re: Surprising behavior with inline environment variable expansion

On Mär 26 2025, Andreas Kähäri wrote: > The argument to "bash -c" There is no "bash -c" in that command. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."

Re: Surprising behavior with inline environment variable expansion

that we're all used to), from the NetBSD shell (bash can't execute this one, yet anyway): Does libc understand those as digits? Does strtoimax() use isdigit() and understand how to convert those to a numeric value? As an additional example of where locales can affect results, in Thai, the d

Re: Surprising behavior with inline environment variable expansion

On 3/29/25 4:52 PM, Lawrence Velázquez wrote: Additional macro definitions, beginning with the characters LC_ and an uppercase letter, may also be specified by the implementation. https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/basedefs/locale.h.html Thank

Re: Surprising behavior with inline environment variable expansion

On 3/31/25 12:52 PM, Andreas Schwab wrote: On Mär 31 2025, Chet Ramey wrote: It's hard to see these as being useful if they're glibc-specific. They are coming from ISO TR 14652 and 30112. OK. And when other systems support them, and they get standardized, it will be time to revisit the issu

Re: Surprising behavior with inline environment variable expansion

If I write break ๒ in a bash script with LANG=th set in the environment (and no other locale settings) is bash going to interpret that correctly? That's one of the "hypothetical extra digits" that really do exist (it is $'\u0E52' if the character isn&#x

Re: Surprising behavior with inline environment variable expansion

On Sat, Mar 29, 2025, at 4:52 PM, Lawrence Velázquez wrote: > https://sourceware.org/git/?p=glibc.git;a=blob;f=locale/locale.h;hb=glibc-2.41#l33 > https://sourceware.org/git/?p=glibc.git;a=blob;f=locale/langinfo.h;hb=glibc-2.41#l584 > https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/loca

Re: Surprising behavior with inline environment variable expansion

On Sat, Mar 29, 2025, at 2:25 PM, Chet Ramey wrote: > How does a locale doing this expose the category to the programmer? > I suppose all possible additional locale categories have to be available > to setlocale() somehow, via and the documentation. Yeah, looks like POSIX explicitly permits that:

Re: Surprising behavior with inline environment variable expansion

On 3/29/25 12:05 AM, Lawrence Velázquez wrote: On Thu, Mar 27, 2025, at 5:22 PM, Chet Ramey wrote: On 3/26/25 6:29 PM, Robert Elz wrote: LANG is generally just the fallback for categories that haven't been set to something else. For this, assume the LC_ALL had never been set (setting LANG aft

Re: Surprising behavior with inline environment variable expansion

On Thu, Mar 27, 2025, at 5:22 PM, Chet Ramey wrote: > On 3/26/25 6:29 PM, Robert Elz wrote: >> LANG is generally just the fallback for categories that haven't been >> set to something else. For this, assume the LC_ALL had never been >> set (setting LANG after that is set should probably just do n

Re: Surprising behavior with inline environment variable expansion

On 3/26/25 6:29 PM, Robert Elz wrote: Date:Wed, 26 Mar 2025 16:05:57 -0400 From:Chet Ramey Message-ID: | There is a precedence hierarchy associated with locale environment | variables, since setting and unsetting environment variables is under | the use

Re: Surprising behavior with inline environment variable expansion

Le 26/03/2025 à 21:18, Chet Ramey écrivait : I think you're misunderstanding the order of execution here. What additions would you suggest? The order of execution is described in SIMPLE COMMAND EXPANSION. The locale variables and their precedence hierarchy are described in Shell Variables

Re: Surprising behavior with inline environment variable expansion

Date:Wed, 26 Mar 2025 16:05:57 -0400 From:Chet Ramey Message-ID: | There is a precedence hierarchy associated with locale environment | variables, since setting and unsetting environment variables is under | the user's control. This brings up an unrelated, bu

Re: Surprising behavior with inline environment variable expansion

On 3/26/25 8:20 AM, Léa Gris wrote: I am onto something here : No, not really. It's pretty simple. $ LC_ALL=C bash -c 'locale; printf "\\nEnvironment variable: LC_NUMERIC=%s\ \n" "$LC_NUMERIC"' LC_ALL overrides LC_NUMERIC, as explained in the POSIX reference I sent. Setting LC_ALL doesn't c

Re: Surprising behavior with inline environment variable expansion

On 3/26/25 8:09 AM, Léa Gris wrote: I wonder if locale is switched accordingly to environment variables, but environment variables may not automatically switch to the new locale. There is a precedence hierarchy associated with locale environment variables, since setting and unsetting environm

Re: Surprising behavior with inline environment variable expansion

On 3/26/25 6:52 AM, Léa Gris wrote: LANG=C LC_NUMERIC=C printf '%s\t%f\t%f\n' "$LC_NUMERIC" 3.141592654 3,141592654 Outputs: bash: printf: 3,141592654: invalid number fr_FR.UTF-8    3.141593    3.00 In this particular case, the expansion of LC_NUMERIC is performe

Re: Surprising behavior with inline environment variable expansion

On 3/26/25 7:54 AM, Andreas Kähäri wrote: On my Alpine system (bash 5.3.37), LC_NUMERIC is unset, and setting LC_ALL does not automagically set LC_NUMERIC in "bash -c": % LC_ALL=C bash -c 'echo "$LC_NUMERIC"' (blank line output) % LANG=C bash -c 'echo "$LC_NUMERIC"'

Re: Surprising behavior with inline environment variable expansion

Le 26/03/2025 à 12:54, Andreas Kähäri wrote : On my Alpine system (bash 5.3.37), LC_NUMERIC is unset, and setting LC_ALL does not automagically set LC_NUMERIC in "bash -c": % LC_ALL=C bash -c 'echo "$LC_NUMERIC"' (blank line output) % LANG=C bash -c 'echo "$LC_NUMERIC"'

Re: Surprising behavior with inline environment variable expansion

On Wed, Mar 26, 2025 at 01:35:12PM +0100, Andreas Schwab wrote: > On Mär 26 2025, Andreas Kähäri wrote: > > > The argument to "bash -c" > > There is no "bash -c" in that command. > > -- > Andreas Schwab, SUSE Labs, sch...@suse.de > GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3

Re: Surprising behavior with inline environment variable expansion

On Wed, Mar 26, 2025 at 13:09:45 +0100, Léa Gris wrote: > $ LC_ALL=C locale > LANG=fr_FR.UTF-8 > LANGUAGE=fr_FR:fr_CA:en > LC_CTYPE="C" > LC_NUMERIC="C" > LC_TIME="C" > LC_COLLATE="C" > LC_MONETARY="C" > LC_MESSAGES="C" > LC_PAPER="C" > LC_NAME="C" > LC_ADDRESS="C" > LC_TELEPHONE="C" > LC_MEASUREME

Re: Surprising behavior with inline environment variable expansion

I am onto something here : $ LC_ALL=C bash -c 'locale; printf "\\nEnvironment variable: LC_NUMERIC=%s\\n" "$LC_NUMERIC"' Output: LANG=fr_FR.UTF-8 LANGUAGE=fr_FR:fr_CA:en LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES="C" LC_PAPER="C" LC_NAME="C" LC_ADDRESS="

Re: Surprising behavior with inline environment variable expansion

On Wed, Mar 26, 2025 at 12:19:48PM +0100, Andreas Schwab wrote: > On Mär 26 2025, Léa Gris wrote: > > > Even though LC_NUMERIC=C is used to correctly parse 3.141592654, the > > expansion of $LC_NUMERIC still prints its original value (fr_FR.UTF-8). > > That is exp

Re: Surprising behavior with inline environment variable expansion

On Mär 26 2025, Léa Gris wrote: > Even though LC_NUMERIC=C is used to correctly parse 3.141592654, the > expansion of $LC_NUMERIC still prints its original value (fr_FR.UTF-8). That is expected. The reference to LC_NUMERIC is expanded before the command execution is started (which in

Surprising behavior with inline environment variable expansion

Hello, While experimenting with inline environment variables, I noticed that although they are correctly applied to command execution, their expansion sometimes retains the previous value—but not always! Context: Bash version: GNU bash, version 5.2.21(1)-release (x86_64-pc-linux-gnu

Re: Degenerate case in brace expansion.

On 3/8/25 3:05 PM, Kaz Kylheku wrote: But: $ echo {a..{z,y}} a..z a..y Is this documented? I would expect it to produce {a..z} {a..y} As fate would have it, I fixed this case about a month ago after a separate conversation. -- ``The lyf so short, the craft so long to lerne.'' - C

Re: Degenerate case in brace expansion.

On Sat, Mar 8, 2025, at 3:05 PM, Kaz Kylheku wrote: > > $ echo {a..{z,y}} > a..z a..y > > Is this documented? I would expect it to produce > > {a..z} {a..y} This is fixed in the devel branch: $ git -C ~/src/bash checkout -q c3ca11424d2ae66cafa2f931b008dfb728e209a5 $ { ~/src/

Degenerate case in brace expansion.

have recognized the syntax for special processing, but then it is not evident in the a..z a..y output how it relates to sequence expansion. I came across this because the recent discussion in this list prompted me to go looking into my own brace expansion implementation, which I recently extended

Re: Possible bug for nested curly brace expansion

{0} is no expansion {0,} is it must be 2+ On Thu, Mar 6, 2025, 7:40 PM Trond Endrestøl via Bug reports for the GNU Bourne Again SHell wrote: > $ bash --version > GNU bash, version 5.2.37(0)-release (amd64-portbld-freebsd14.1) > Copyright (C) 2022 Free Software Foundation, Inc. > L

Re: Possible bug for nested curly brace expansion

On Thu, Mar 6, 2025, at 9:06 PM, Kaz Kylheku wrote: > But Bash cannot do this. The reason is that brace expansion is already > a deviation from POSIX. POSIX.1-2024 does permit brace expansion syntax as an extension, although it doesn't use the term "brace expansion" or p

Re: Possible bug for nested curly brace expansion

On 2025-03-06 11:58, Lawrence Velázquez wrote: > On Thu, Mar 6, 2025, at 1:48 PM, microsuxx wrote: >> {0} is no expansion >> {0,} is >> it must be 2+ > > And this is documented. It is not a bug. > > A correctly-formed brace expansion must contain unq

Re: Possible bug for nested curly brace expansion

On Thu, Mar 6, 2025, at 1:48 PM, microsuxx wrote: > {0} is no expansion > {0,} is > it must be 2+ And this is documented. It is not a bug. A correctly-formed brace expansion must contain unquoted opening and closing braces, and at least one unquoted comma o

Possible bug for nested curly brace expansion

(1) in FreeBSD gives the expected expansion for both examples: $ echo devel/llvm{1{1,2,3,4,5,6,7,8,9},2{0}} devel/llvm11 devel/llvm12 devel/llvm13 devel/llvm14 devel/llvm15 devel/llvm16 devel/llvm17 devel/llvm18 devel/llvm19 devel/llvm20 $ echo devel/llvm{1{1,2,3,4,5,6,7,8,9},2{0,1}} devel/llvm1

Re: [Suggestion] Add warning/error when using the tilde expansion in a folder where the tile-named file/folder exists

and a command with a parameter starting with ~ is used (which will produce tilde expansion). Thanks for the suggestion. I'm not inclined to implement it. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'

Re: [Suggestion] Add warning/error when using the tilde expansion in a folder where the tile-named file/folder exists

Andrés Rodríguez Reina writes: ... > Due to a mistake in coding a script, a folder named '~' was > generated. An unexperienced bash user issued the command "rm -rf ~" by > mistake, intending to delete the '~' folder, but this resulted in > deleting 150GB+ of data at their home directory. It mig

Re: [Suggestion] Add warning/error when using the tilde expansion in a folder where the tile-named file/folder exists

either, but it can easily be activated in ~/.bashrc for beginners. From: microsuxx Sent: Wednesday, February 12, 2025 9:29:40 PM To: Andrés Rodríguez Reina Cc: bug-bash ; Marina López Seoane Subject: Re: [Suggestion] Add warning/error when using the tilde expansion in a folder where the ti

Re: [Suggestion] Add warning/error when using the tilde expansion in a folder where the tile-named file/folder exists

or \~ On Wed, Feb 12, 2025, 9:05 PM microsuxx wrote: > to use ~ as file .. > > '~' n "~" > or ./~ > > On Wed, Feb 12, 2025, 5:21 PM Andrés Rodríguez Reina > wrote: > >> Subject: [Suggestion] Add warning/error when using the tilde expansion in &

Re: [Suggestion] Add warning/error when using the tilde expansion in a folder where the tile-named file/folder exists

to use ~ as file .. '~' n "~" or ./~ On Wed, Feb 12, 2025, 5:21 PM Andrés Rodríguez Reina wrote: > Subject: [Suggestion] Add warning/error when using the tilde expansion in > a folder where the tile-named file/folder exists > > Configuration Information [Automa

Re: [Suggestion] Add warning/error when using the tilde expansion in a folder where the tile-named file/folder exists

On Wed, Feb 12, 2025, at 2:02 PM, Andrés Rodríguez Reina wrote: > And I also > agree that any other substitution is subject to cause the same > confusion, but the case with the tilde expansion produces more damage > to inexperienced users. I mean: "rm -rf *" just delet

RE: [Suggestion] Add warning/error when using the tilde expansion in a folder where the tile-named file/folder exists

Thank you for taking the time to review this suggestion. I agree that tilde expansion is not ambiguous, this suggestion is here just to help clear the ambiguity in the user's mind/intent. And I also agree that any other substitution is subject to cause the same confusion, but the case with

Re: [Suggestion] Add warning/error when using the tilde expansion in a folder where the tile-named file/folder exists

g > with ~ is used (which will produce tilde expansion). You could say this about any unexpanded word. touch '$var' echo $var touch '*' ls * set -H touch '!$' stat !$ Should the shell look for a directory e

[Suggestion] Add warning/error when using the tilde expansion in a folder where the tile-named file/folder exists

Subject: [Suggestion] Add warning/error when using the tilde expansion in a folder where the tile-named file/folder exists Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash

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

ath begins with ‘~’ but is not of any of the forms given above, the expansion may be used for additional features in future. In that case it would be preferable that they should work both quoted and unquoted. Clearly it is inappropriate to suggest that $HOME be used in place of ‘~’ except where it&#

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

On 2/3/25 8:03 PM, Zeffie via Bug reports for the GNU Bourne Again SHell wrote: To whom it may concern, Bash has long maintained a legacy feature whereby, in interactive sessions, a literal tilde (`~`) at the start of a `PATH` element (e.g., `~/bin`) is expanded to the user’s home directory at

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

ah , this might be due to u use it after a bash keyword 1. it doesnt need export cause its already exported 2. if u wanna export , export it but 3. do PATH='...' or ".." ur string but not after export or declare just on its own line greets On Tue, Feb 4, 2025, 4:53 AM Zeffie wrote: > On 2025-02

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

On 2025-02-03 22:19, microsuxx wrote: ~ $ p=~:~:~ ; declare -p p declare -- p="/data/data/com.termux/files/home:/data/data/com.termux/files/home:/data/data/com.termux/files/home" ~ $ cp $( type -P bash ) sh ~ $ ./sh sh-5.2$ x=~:~:~: sh-5.2$ declare -p x declare -- x="/data/data/com.termux/files

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

> `~/bin`) is expanded to the user’s home directory at the time a command > is executed. While this behavior can sometimes “help” users find > commands in their home directory, it is neither consistent with POSIX > nor universally understood. In particular, when Bash is invoked as >

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

find commands in their home directory, it is neither consistent with POSIX nor universally understood. In particular, when Bash is invoked as `/bin/sh` or in POSIX mode, tilde expansion in `PATH` is disabled, leading to potential confusion and hard-to-debug issues. Given that a number of

[sr #111160] "Names matching prefix" expansion does not honor empty prefix

URL: <https://savannah.gnu.org/support/?60> Summary: "Names matching prefix" expansion does not honor empty prefix Group: The GNU Bourne-Again SHell Submitter: None Submitted: Sat 07 Dec 2024

Re: word selection in history expansion - !?word?%

ry of extending the history expansion syntax, even to the extent of adding a new modifier. It's been basically identical for what, 46 years? It's an interesting idea, though. Implementing the search across lines might prove tricky.  The current code splits line match and word match; we don

Re: word selection in history expansion - !?word?%

loogle > > $ echo !?word?% > > echo word03 > > word03 > > $ # I expected to get word01 > > $ echo $BASH_VERSION > > 5.2.26(1)-release > > ``` > > > > The bash manual for word designators sounds to me as if word01 should be > > selected. > > Th

Re: word selection in history expansion - !?word?%

should be selected. That's certainly the csh behavior. Bash has done it this way for as long as its history expansion has been implemented. It dates back to at least 1988-89. I think the idea (that was a long time ago) was that it started as a way to perform searching for readline, and in that

word selection in history expansion - !?word?%

header has words numbered from the beginning of the line, and the description of `%` says first. Thus, I would expect the history expansion to provide word01. Looking at the code that performs % interpolation, that behaviour is hard-coded to do a reverse search on the line. The way this reverse search

Re: [[...]] documentation claims tilde expansion and process substitution occur within double quotes

On 4/26/24 5:36 PM, Lawrence Velázquez wrote: Both the manual [1] and man page [2] state: The words between the [[ and ]] do not undergo word splitting and filename expansion. The shell performs tilde expansion, parameter and variable expansion, arithmetic expansion

[[...]] documentation claims tilde expansion and process substitution occur within double quotes

Both the manual [1] and man page [2] state: The words between the [[ and ]] do not undergo word splitting and filename expansion. The shell performs tilde expansion, parameter and variable expansion, arithmetic expansion, command substitution, process substitution

Re: History Expansion in Arithmetic Expansion

On Sat, Mar 23, 2024 at 11:34 AM A4-Tacks wrote: > > ```bash > $ ((!RANDOM)) > bash: !RANDOM: event not found > ``` I just reported this last August [1]. If you, like me, never use history expansion, the best solution might be to disable it in your .bash

Re: History Expansion in Arithmetic Expansion

bash: !RANDOM: event not found > ``` Unfortunately this is intentional and documented. In interactive shells with default settings, unquoted `!' introduces a history expansion [1]. You cannot backslash-escape `!' within `((exp))' because `exp' is treated almost

Re: History Expansion in Arithmetic Expansion

Thank you, this is very effective! Replied Message | From | alex xmb sw ratchev | | Date | 03/23/2024 23:38 | | To | A4-Tacks | | Cc | bug-bash | | Subject | Re: History Expansion in Arithmetic Expansion | On Sat, Mar 23, 2024, 16:34 A4-Tacks wrote: Configuration Information

Re: History Expansion in Arithmetic Expansion

On Sat, Mar 23, 2024, 16:34 A4-Tacks wrote: > Configuration Information [Automatically generated, do not change]: > Machine: aarch64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -march=armv8-a -O2 -pipe -fstack-protector-strong > -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wfo

History Expansion in Arithmetic Expansion

Configuration Information [Automatically generated, do not change]: Machine: aarch64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -march=armv8-a -O2 -pipe -fstack-protector-strong -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-prote

Re: Bash reference manual: shell parameter expansion examples

using a different form? After this paragraph: "When not performing substring expansion, using the forms described below (e.g., ‘:-’), Bash tests for a parameter that is unset or null. Omitting the colon results in a test only for a parameter that is unset. Put another way, if the colon is inc

Bash reference manual: shell parameter expansion examples

Hi! In the Bash reference manual, there are a series of examples of testing if a variable is null or unset: - Under *${parameter:-word}*, the usage is *${var-unset}*. - Under *${parameter:=word}*, the usage is *${var:=DEFAULT}*. - Under *${parameter:?word}*, the usage is *${var:?var is u

Re: set-e and command expansion

arch and Execution. If there is no command name, but the command contained a command substitution, the command shall complete with the exit status of the last command substitution performed." Below is an excerpt from https://www.gnu.org/software/bash/manual/html_node/Simple-Command-Expansion.h

Re: set-e and command expansion

On Sun, Feb 04, 2024 at 08:27:56PM +0300, Van de Bugger wrote: > Case 3: echo $(false) > > $ cat ./test > #!/bin/bash > set -e > echo before > echo $(false) > echo after > > $ ./test > before > > after > > Oops, in this case the script is NOT terminated before "echo after", but > co

set-e and command expansion

bug, but interaction between "set - e" and command substitution is not well defined in the bash manual. Anyway, it looks like inconsistency: command expansion in a variable assignment terminates the script, but the same command expansion in another command does not. What do you think?

Re: bash aborts line-editing on tab-expansion with find pattern

2024年1月15日(月) 23:02 : > Description: > Found while editing history line with a find pattern. > Apparently bash doesn't like + characters very much. > > Repeat-By: > find . -type f -ctime +30 ! -ctime +40 -exec ls -la --full-time {} + > Move cursor to any point after

bash aborts line-editing on tab-expansion with find pattern

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall uname output: Linux sourcetronic.com 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21) x8

Re: No filename expansion in shell-expand-line

On 1/12/24 3:28 AM, Martin Schulte wrote: Hello, from the documentation I understand that shell-expand-line (ESC CTRL-E) should do alias expansion, history expansion, brace expansion, tilde expansion, shell parameter expansion, command substitution, arithmetic expansion, process substitution

Re: No filename expansion in shell-expand-line

Sorry, I falied to copy and paste R*, the last line is replaced by ls --color=auto echo {a..c} ~root xterm-256color 2024-01-12 42 /dev/fd/63 hello R* > Hello, > > from the documentation I understand that shell-expand-line (ESC CTRL-E) > should do alias expansion, history expa

No filename expansion in shell-expand-line

Hello, from the documentation I understand that shell-expand-line (ESC CTRL-E) should do alias expansion, history expansion, brace expansion, tilde expansion, shell parameter expansion, command substitution, arithmetic expansion, process substitution (if supported by the operation system

Re: Newlines resulting from alias expansion are ignored by here-document processing

On Tue, Dec 5, 2023, 17:22 Chet Ramey wrote: > On 11/30/23 3:45 AM, gldrk wrote: > > $ cat test > > alias 'foo=cat < > hello' > > foo > > world > > EOF > > $ sh test > > world > > test: line 5: hello: command not found > > > > My reading of the upcoming POSIX revision > > (https://www.austingroup

Re: Newlines resulting from alias expansion are ignored by here-document processing

On 11/30/23 3:45 AM, gldrk wrote: $ cat test alias 'foo=cat

Re: Newlines resulting from alias expansion are ignored by here-document processing

This patch appears to solve the issue. As far as I can tell, this routine is only used for here-documents. diff --git a/parse.y b/parse.y index 8fd24a1c..4d361af7 100644 --- a/parse.y +++ b/parse.y @@ -2083,6 +2083,8 @@ read_a_line (remove_quoted_newline) static char *line_buffer = (char *)N

Newlines resulting from alias expansion are ignored by here-document processing

$ cat test alias 'foo=cat

Re: ! history expansion occurs within arithmetic substitutions

7;s both, actually. The line being expanded is broken into words to bound > the history expansion, since a history expansion doesn't extend to multiple > words, and the event is broken into words for the rest of the process. > While the delimiters for picking history expansions out of

Re: ! history expansion occurs within arithmetic substitutions

to start this sentence with "The selected line…", to differentiate from the line just entered containing a "!". It's both, actually. The line being expanded is broken into words to bound the history expansion, since a history expansion doesn't extend to multiple

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

Andreas Schwab writes: >> More troublesome, I think, are several variable substitutions which >> include "!" followed by a name. But I doubt they're used much in >> interactive mode. > > The history expansion is smart enough to not interfere with ${!var}.

Re: ! history expansion occurs within arithmetic substitutions

On Thu, Aug 10, 2023, at 2:21 PM, Dale R. Worley wrote: > My understanding is that "interactive" directly affects only two things, > the startup file(s) read and the initial values of various shell > options. There are more differences than that. https://www.gnu.org/software/bash/manual/html_node

Re: ! history expansion occurs within arithmetic substitutions

Zachary Santer writes: > When messing around in interactive mode to test things I may want to do in > a script, it's nice if it actually behaves the same. There are probably > some other set and possibly shopt things I should have somewhere if that's > what I want. I checked, and it doesn't seem

Re: !; is interpreted as an history expansion that can never match anything

On 8/8/23 3:30 PM, Dale R. Worley wrote: Emanuele Torre writes: ! followed by a ; or another terminator is interpreted as an history expansion with no pattern that can never match anything. $ !; echo hi bash: !: event not found $ !&& echo hi bash: !: event not found IM

Re: !; is interpreted as an history expansion that can never match anything

On 8/8/23 5:02 PM, Emanuele Torre wrote: On Tue, Aug 08, 2023 at 03:35:10PM -0400, Chet Ramey wrote: Anyway, there's a good reason to add ";&|" to the set of characters that inhibit history expansion if they follow the history expansion character. Thank you! Please also

Re: !; is interpreted as an history expansion that can never match anything

On Tue, Aug 08, 2023 at 03:35:10PM -0400, Chet Ramey wrote: > Anyway, there's a good reason to add ";&|" to the set of characters that > inhibit history expansion if they follow the history expansion character. Thank you! Please also "()<>" if possible. o/ emanuele6

Re: ! history expansion occurs within arithmetic substitutions

On Tue, Aug 8, 2023 at 3:11 PM Dale R. Worley wrote: > But I would not take it as given that nobody would ever want to use > history expanstion within an arithmetic substitution. Let me concoct an > example: > Yeah, that's all fair. Admittedly, I never use history expa

Re: !; is interpreted as an history expansion that can never match anything

On 8/8/23 1:43 AM, Emanuele Torre wrote: ! followed by a ; or another terminator is interpreted as an history expansion with no pattern that can never match anything. $ !; echo hi bash: !: event not found $ !&& echo hi bash: !: event not found This is interesting. Bash d

Re: ! history expansion occurs within arithmetic substitutions

On Aug 08 2023, Dale R. Worley wrote: > More troublesome, I think, are several variable substitutions which > include "!" followed by a name. But I doubt they're used much in > interactive mode. The history expansion is smart enough to not interfere with ${!var}.

Re: !; is interpreted as an history expansion that can never match anything

Emanuele Torre writes: > ! followed by a ; or another terminator is interpreted as an history > expansion with no pattern that can never match anything. > > $ !; echo hi > bash: !: event not found > $ !&& echo hi > bash: !: event not found IMHO it is more to

Re: ! history expansion occurs within arithmetic substitutions

Zachary Santer writes: > Description: > Similarly, history expansion occurs within arithmetic substitutions. This > will never, ever be what the user wants. And now I know how to make it not > happen. > > Repeat-By: > $ set +o histexpand Well, yes, if you turn off histo

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 exp

Re: ! history expansion occurs within arithmetic substitutions

3.4.7.x86_64 2023-07-14 > 16:57 UTC x86_64 Msys > Machine Type: x86_64-pc-msys > > Bash Version: 5.2 > Patch Level: 15 > Release Status: release > > Description: > Similarly, history expansion occurs within arithmetic substitutions. This > will never, ever be wha

! history expansion occurs within arithmetic substitutions

Patch Level: 15 Release Status: release Description: Similarly, history expansion occurs within arithmetic substitutions. This will never, ever be what the user wants. And now I know how to make it not happen. Repeat-By: $ set -o histexpand $ number=4 $ printf '%s\n' "$(( !0 ))"

!; is interpreted as an history expansion that can never match anything

! followed by a ; or another terminator is interpreted as an history expansion with no pattern that can never match anything. $ !; echo hi bash: !: event not found $ !&& echo hi bash: !: event not found It should not be intepreted as a history expansion that cannot possib

Re: [Documentation] Parameter expansion: missing colon in example

On 7/21/23 2:37 PM, private--- via Bug reports for the GNU Bourne Again SHell wrote: Hello, The example on parameter expansion[1] should perhaps read : $ echo ${v:-unset} instead of : $ echo ${v-unset} There should probably be more examples showing the differences between the - and

[Documentation] Parameter expansion: missing colon in example

Hello, The example on parameter expansion[1] should perhaps read : $ echo ${v:-unset} instead of : $ echo ${v-unset} Yes ? More context: ---8<--- ${parameter:-word} If parameter is unset or null, the expansion of word is substituted. Otherwise, the value of parameter is substituted.

  1   2   3   4   5   6   7   8   9   10   >