Re: Bad filename tab completion with bracket and dollar sign

2025年8月23日(土) 4:28 Chet Ramey : > > Repeat-By: > > 1. touch '[$L]'a '[$L]'b; > > 2. less > > * The completion is less "[$L]. > Because bash completion guesses that the user wants the expansion to take > place, since there's no filename matching the completion, and double quotes > allo

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

2025年8月29日(金) 20:16 Kevin Pulo : > This patch adds the syntax ${;cmd;}, which is handled identically to ${ cmd;} > except that trailing newlines are preserved. I've checked the contents of the patch. Maybe it's already been applied to the codebase with adjustments, but shouldn't the keep-trailing-

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

2025年9月4日(木) 20:57 Martin D Kealey : > On Wed, 3 Sept 2025 at 07:17, Koichi Murase wrote: >> 2025年9月3日(水) 1:21 Martin D Kealey : >> > Maybe « function foo -o compat=60 -o extglob -o nullglob … { …; } »? >> >> With that syntax, Zsh defines multiple functions of th

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

2025年9月11日(木) 7:02 Martin Jambon : > Description: > Expectation: I expect a syntax error in the absence of a semicolon > or a newline between the closing brackets and the then. > > Behavior with Bash 5.2.21: no error, the program behaves as if a > semicolon was present. This is req

Re: On Martin D. Kealey (was: [bug #67486] Can't use if with two separate awk floating number comparisons)

Martin argues if he wishes, but I think it is a part of Martin's character. I don't think it is a big problem, though as Chet mentioned, I think Martin is undermining his arguments with his behavior to some extent. > [3] Or demonstrably false, even. Koichi Murase and Grisha Lev

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

2025年9月9日(火) 23:55 Chet Ramey : > You can be an administrator or a contributor. I am an administrator for > two groups: Bash and Readline. > > Being a contributor means being one of the developers: "Type below the name > of the group you want to contribute to. Joining a group means getting write >

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

2025年9月10日(水) 0:38 G. Branden Robinson : > At 2025-09-09T10:54:29-0400, Chet Ramey wrote: > > Being a contributor means being one of the developers: "Type below the > > name of the group you want to contribute to. Joining a group means > > getting write access to the repositories of the group, and

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

2025年9月9日(火) 13:51 Oğuz : > > Reply to this item at: > > > > Who thought this shit was a good idea? What's wrong with plain old e-mail? This is just a notification from the Savannah system. In addition to mailing lists, the Savannah system also provides sep

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

I vote for ${; cmd; }. It now seems to make sense to me. It initially appeared to be strange, but it seems to be a matter of whether you've gotten used to it. We already have ${| cmd; }, and there are still many command delimiters (where `|' belongs to), such as `&', `;', `||', `&&', `|&', `;;', `;

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

I also agree with Chet. People shouldn't expect features that have never been documented to be a stable API. One should regard such a feature as an experimental one (which may be officially announced in the future or may be removed before becoming an official feature). > On Sat, Aug 30, 2025 at 03

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

2025年8月29日(金) 20:16 Kevin Pulo : > On Fri, 29 Aug 2025 at 01:00, Koichi Murase wrote: > > If the feature is really desired by the community as an essential feature, > > it > > should be implemented as a new syntax. > > I looked at adding alternate syntax for doing c

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

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 as they're fully parsed, even if the encoding block > hasn't finished parsing. > > Then we could write something

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

2025年8月31日(日) 0:45 Stan Marsh : > However, it does still leave the problem that whatever objections they have > had to the > idea of doing it with "shopt" applies to pretty much most/all of the (other) > "shopt" > options. That is, most/all of the "shopt" options change shell behavior in > ways

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

2025年8月28日(木) 17:29 Martin D Kealey : > On Wed, 27 Aug 2025 at 15:16, Koichi Murase wrote: >> local saved=$(shopt -p cmdsubst_trailing_nls) # (assume we are in a >> function) >> shopt -s cmdsubst_trailing_nls >> foo=$(some_command ...) >> eval -- &quo

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

2025年8月28日(木) 17:20 Kevin Pulo : > On Wed, 27 Aug 2025 at 19:53, Koichi Murase wrote: > > We constantly receive reports from users saying "the frameworks should > > work flawlessly with this set of options because it is the built-in > > feature of Bash", etc.

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

2025年8月27日(水) 17:30 Kevin Pulo : > It's correct that using the shopt to change the behavior will, in general, > break existing code that assumes the original unmodified behavior, and this is > one of the main downsides of using shopts to modify behavior. > > However, I don't agree that the responsi

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

2025年8月27日(水) 12:27 Kevin Pulo : > [...] (1) the choice of using shopts to modify behavior (vs > alternative syntax ala [3]; each of these approaches has pros and cons), and I'm opposed to adding new shell options to change the behaviors of existing codes. If these options were added, we would nee

Re: 5.3: Why is <(cmd) allowed in func names of func defs?

2025年6月11日(水) 23:10 Chet Ramey : > On 6/3/25 4:35 PM, Robert Elz wrote: > > A function name should remain a shell "word" - including being possibly > > partly or fully a quoted word, after all, if it contains operator chars, > > white space, or quoting chars, then it will need to be quoted to be >

Re: 5.3: Why is <(cmd) allowed in func names of func defs?

2025年6月11日(水) 23:07 Chet Ramey : > On 6/3/25 11:57 AM, Koichi Murase wrote: > >> xx. <( and >( can now be used in function names. > > > > What is the background of this change? This was added in commit > > 315095ad, and to the best of my knowledge, an email

Re: 5.3: Why is <(cmd) allowed in func names of func defs?

2025年6月4日(水) 0:57 Koichi Murase : > [...]. If it was > implemented after Ref. [1], « '<(echo hello)' () { echo hello; } » > should have been supported but not « <(echo hello) () { echo hello; > }.». I realized that « '<(echo hello)' () { ...; } » i

5.3: Why is <(cmd) allowed in func names of func defs?

> xx. <( and >( can now be used in function names. What is the background of this change? This was added in commit 315095ad, and to the best of my knowledge, an email on the mailing list in the same period and related to this change would be Ref. [1] from kre. [1] https://lists.gnu.org/archive/ht

Re: 2.0..devel: `set -u; a=1; echo ${#a[@]}' fails

Thank you for your answer. 2025年4月8日(火) 0:40 Chet Ramey : > OK, so you're asking for a new feature/behavior change. Yes. > don't get me wrong, but it's a little late in the cycle for bash-5.3. Yeah, that makes sense. I don't mind if the change would be applied in a later version. > > I'd be ha

2.0..devel: `set -u; a=1; echo ${#a[@]}' fails

With nounset, ${#a[@]} for a scalar variable fails even though we can correctly obtain the result (which is consistent with the expansion of "${a[@]}") without nounset. This is the result with the devel version: $ bash -c 'a=1; echo ${#a[@]}' 1 $ bash -uc 'a=1; echo ${#a[@]}' bash: line 1

Re: bash --pretty-print and pattern

2025年2月20日(木) 23:37 Chet Ramey : > > $ bash --pretty-print -O extglob test.sh > > You can use BASH_ENV for this. The primary reason that pretty-printing mode > doesn't suppress execution until after any startup files are read is to > allow a custom startup file to set the shell options you want for

Re: bash --pretty-print and pattern

2025年2月20日(木) 20:51 Timotei Campian : > echo !(file.f*) > > *bash --pretty-print test.sh* If this script file "test.sh" will be used as an independent executable file, to make it work, you need to put "shopt -s extglob" at the beginning of the file as Greg explained in the other reply. If the scr

Re: bash compat* issues?

2025年1月22日(水) 22:03 MacBeth : > Or perhaps that second error is produced by the parent shell before This. The error message is printed even for "/bin/echo": $ BASH_COMPAT=foo bash: BASH_COMPAT: foo: compatibility value out of range $ BASH_COMPAT=4.4 /bin/echo hello bash: BASH_COMPAT: foo: compati

Re: bash compat* issues?

2025年1月22日(水) 14:25 Lawrence Velázquez : > On Tue, Jan 21, 2025, at 9:49 PM, MacBeth wrote: > > But either > > way, `shopt compat50` should be consistent with BUILTINS/shopt. > > Yeah, probably. I think this is just an error in the man page. The error still exists in the devel branch: https://git

Re: SHELLOPTS environment variable causes shell options to cascade

2025年1月5日(日) 5:43 Tobi Laskowski : > On the other hand, if there is a pre-existing SHELLOPTS environment > variable (set outside the current shell), then the `nounset` option > applies to all invocations of bash within the current shell. This is documented as Oguz pointed out. > Even with the `+u

Re: bind allows "impossible" key bindings without warning

2025年1月4日(土) 1:04 Hauke Laging : > Currently you can bind key sequences which (in that situation) cannot be > activated. You can activate it by setting a longer time to keyseq-timeout. $ bind 'set keyseq-timeout 1000' $ bind '"\C-h": "hello"' $ bind '"\C-hw": "world"' With this setup, you can pr

Re: Regression: EXIT traps always run in global context

2024年11月28日(木) 13:59 Ivan Shapovalov : > Repeat-By: > See the attached script. I was testing the behavior of Bash, but it seems Bash's behavior has never been stable and consistent. With the following test cases #1...#8, #1 "$bash" -ec'trap "echo \"[\$FUNCNAME:\$f]\"" EXIT; f() { loca

Re: [PATCH] prompt: add \m, PROMPTTIMEFORMAT, shopt prompt_time_all

Isn't this achievable with PS0 and Bash-5.3 valsub? _prompt_time() { if [[ $_prompt_time_start ]]; then _prompt_time=$((${EPOCHREALTIME//[!0-9]}-_prompt_time_start)) _prompt_time_start= fi printf -v REPLY '%d.%06d' "$((_prompt_time/100))" "$((_prompt_time%100))" } PS0+='${| _

Re: [feature request] Add ".sh" or ".bash" extension to tmpfile generated by `fc`

2024年9月21日(土) 1:09 Chet Ramey : > On 9/20/24 2:41 AM, shynur . wrote: > > `fc` will create a temporary file named something > > like "bash-fc.Esf9by", which seldom benefits from > > editors that use *suffixes* to infer what syntax > > highlighting should be enabled. > > Do these editors have an opt

Re: please make the commit log clean

2024年8月20日(火) 5:52 Koichi Murase : > 2024年8月20日(火) 2:25 Martin D Kealey : > > Perhaps a compromise would be to put the documentation in a directory > > that's not inside the source code directory, so it's easier to `git diff` > > just one or the other. (In practice,

Re: please make the commit log clean

2024年8月20日(火) 2:25 Martin D Kealey : > Perhaps a compromise would be to put the documentation in a directory > that's not inside the source code directory, so it's easier to `git diff` > just one or the other. (In practice, that would mean moving some of the > code into a new subdirectory.) One c

Re: Potentially misleading documentation of SECONDS variable

2024年8月7日(水) 0:24 Bash-help via Bug reports for the GNU Bourne Again SHell : > Reading the manual at > > regarding the SECONDS variable, it states that > " [..] Assignment to this variable resets the count to the value assigned, >

[PATCH] fix `shopt -u force_fignore' affecting unrelated parts

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -march=native -O3 uname output: Linux chatoyancy 6.5.12-100.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Nov 20 22:28:44 UTC 2023 x86_64 GNU/Linux Machine Type: x86_64-pc-li

Re: proposed BASH_SOURCE_PATH

2024年6月20日(木) 5:47 Léa Gris : > Look like you did not find a proper answer there. Here is one simple > that involve no sub-shell at all and does exactly what your sub-shell > version does. > > declare -r SCRIPT_DIR=${BASH_SOURCE[0]%/*} This doesn't work as explained by Will. BASH_SOURCE doesn't co

Re: REQUEST - bash floating point math support

2024年6月17日(月) 15:56 Léa Gris : > Le 16/06/2024 à 23:44, Zachary Santer écrivait : > Anyway, this could be handled with existing bash string replacement feature: > > localeFormatted=3,1415 > declare -i numvar=${localeFormatted/,/.} Is the radix character in an arbitrary locale ensured to be either

Re: set -a leads to truncated output from ps

2024年6月15日(土) 22:48 Koichi Murase : > 2024年6月15日(土) 13:48 Oğuz : > > On Saturday, June 15, 2024, Koichi Murase wrote: > >> Also, the behavior of the `ps' command honoring COLUMNS to format its > >> output is also an expected one. > > > > The fact tha

Re: set -a leads to truncated output from ps

2024年6月15日(土) 13:48 Oğuz : > On Saturday, June 15, 2024, Koichi Murase wrote: >> Also, the behavior of the `ps' command honoring COLUMNS to format its >> output is also an expected one. > > The fact that programs giving precedence to COLUMNS over the > terminal API

Re: REQUEST - bash floating point math support

2024年6月15日(土) 17:24 Léa Gris : > Indeed printf only knows the string value. But Bash know the variable > has a numeric flag when doing the value expansion, so it expands it > using the current LC_NUMERIC locale in this specific case. Ah, OK. I misunderstood your suggestion somehow differently (suc

Re: REQUEST - bash floating point math support

2024年6月14日(金) 16:18 Léa Gris : > Another elegant option would be to expand the existing variables' i flag > to tell the variable is numeric rather than integer. > > Then have printf handle argument variables with the numeric flag as > using the LC_NUMERIC=C floating-point format with dot radix poin

Re: set -a leads to truncated output from ps

2024年6月14日(金) 16:30 Alain BROSSARD : Even if the behavior of `set -a' is modified, your script (or the third-party script that you rely on?) is still broken when the user explicitly gives COLUMNS and LINES the export attribute, which is a *typical usage of those variables*. This should be a bug i

Re: Echoing commands

2024年6月13日(木) 5:20 Angelo Borsotti : > This is not the same as debugging, for which set -x is devoted. > "set -x" makes the ensuing commands be printed, but prefixed > with "+ ", which makes the result look ugly, PS4= (as Greg has replied) > not to mention that > the following "set +x" is echoed

Re: REQUEST - bash floating point math support

2024年6月6日(木) 18:09 Léa Gris : > Le 06/06/2024 à 10:29, Koichi Murase écrivait : > > 2024年6月6日(木) 15:59 Léa Gris : > >> Le 05/06/2024 à 17:09, Koichi Murase écrivait : > >>> 2024年6月5日(水) 21:41 Zachary Santer : > >>>> Bash could potentially detect flo

Re: REQUEST - bash floating point math support

2024年6月6日(木) 15:59 Léa Gris : > Le 05/06/2024 à 17:09, Koichi Murase écrivait : > > 2024年6月5日(水) 21:41 Zachary Santer : > >> Bash could potentially detect floating point literals within > >> arithmetic expansions and adjust the operations to use floating p

Re: REQUEST - bash floating point math support

2024年6月5日(水) 21:41 Zachary Santer : > Bash could potentially detect floating point literals within > arithmetic expansions and adjust the operations to use floating point > math in that case. [...] ksh and zsh are already behaving in that way, and if Bash would support the floating-point arithmeti

Re: [PATCH] fix uneccesary copy of function bodies for BASH_SOURCE

2024年6月4日(火) 15:11 konsolebox : > I haven't looked at this but it will keep lazy functions safe to > implement right? Right. The fix shouldn't change the observable behavior. The functions are saved in two hash tables, `shell_functions' and `shell_function_defs'. The function bodies are supposed

Re: [PATCH] fix uneccesary copy of function bodies for BASH_SOURCE

To add some contexts not in the commit message, I knew that recent versions of Bash consume more memory when the same shell script is loaded. After bisecting, I realized that the increase in memory use was actually caused by a single commit ba4ab055 (see the attached image. The vertical axis is t

[PATCH] fix uneccesary copy of function bodies for BASH_SOURCE

The function `bind_function_def' (variables.c) stores the function metadata in the hash map `shell_function_defs' in variables.c. The saved information is used by BASH_SOURCE (execute_cmd.c) and the output of `declare -F func' with `shopt -s extdebug' (builtin/declare.def) through the interface `f

Re: [PATCH v2 5/8] builtins/source: parse the -i option

2024年5月25日(土) 8:45 Lawrence Velázquez : > On Fri, May 24, 2024, at 9:04 AM, Koichi Murase wrote: > > 2024年5月24日(金) 19:18 Martin D Kealey : > >> On Tue, 21 May 2024 at 23:16, Koichi Murase wrote: > >>> However, I personally do not think the FPATH mechanism is useful

Re: [PATCH v2 5/8] builtins/source: parse the -i option

2024年5月24日(金) 19:18 Martin D Kealey : > On Tue, 21 May 2024 at 23:16, Koichi Murase wrote: >> 2024年5月21日(火) 14:56 Phi Debian : >> > 'May be' bash could investigate the ksh93/zsh $FPATH autoload, but don't >> > know if that would be good enough for th

Re: printf -u "$fd"?

2024年5月22日(水) 0:15 Zachary Santer : > Additionally, I was hoping the discussion of having a way to make fds > not CLOEXEC without a loadable builtin[3][4] would get some more > attention. I haven't followed the discussion in the original thread for multiple coprocs, but you can remove CLOEXEC rela

Re: [PATCH v2 5/8] builtins/source: parse the -i option

2024年5月21日(火) 14:56 Phi Debian : > Apparently konsolebox wrote a package manager, and survived the source 'as > is', yet he still advocate for 'enhancement'. I do have a package manager > too, and survived source 'as is' and don't require any enhancement. I'm not sure if it is the case for konsole

Re: [PATCH v2 5/8] builtins/source: parse the -i option

2024年5月17日(金) 4:36 Greg Wooledge : > On Thu, May 16, 2024 at 11:31:55AM -0400, Chet Ramey wrote: > > On 5/15/24 11:31 AM, Koichi Murase wrote: > > > Maybe it was not clear to use `source name' and `source -i name' to > > > describe the idea. I me

Re: [PATCH v2 6/8] builtins/source: use source path in isolated mode

2024年5月15日(水) 22:28 Chet Ramey : > On 5/14/24 5:26 PM, Koichi Murase wrote: > > I see. I was assuming that users who want to completely turn off the > > new feature would set an empty BASH_SOURCE_PATH (for both cases > > `source name' and `source -i name'

Re: [PATCH v2 5/8] builtins/source: parse the -i option

2024年5月15日(水) 22:21 Chet Ramey : > On 5/14/24 7:15 PM, Koichi Murase wrote: > > In case we talk about different designs, I assume the following one: > > > > * `source name' searches the files in BASH_SOURCE_PATH, PATH, and the > > current working directory. > >

Re: [PATCH v2 5/8] builtins/source: parse the -i option

2024年5月15日(水) 22:13 Chet Ramey : > On 5/14/24 4:48 PM, Koichi Murase wrote: > > However, at the same time, I think the new option could be justified > > from the viewpoint of language design. If we have a new namespace > > ``BASH_SOURCE_PATH'' for the scripts to be s

Re: proposed BASH_SOURCE_PATH

2024年5月14日(火) 15:09 Martin D Kealey : > A common pattern is to unpack a script with its associated library & config > files into a new directory, which then leaves a problem locating the > library files whose paths are only known relative to $0 (or > ${BASH_SOURCE[0]}). > > 1. I therefore propose t

Re: proposed BASH_SOURCE_PATH

2024年5月15日(水) 13:13 Peng Yu : > On Tue, May 14, 2024 at 3:35 AM Koichi Murase wrote: > > I totally agree that we should have a way to specify the files in > > subdirectories by the path relative to the current script file. > > I currently use something like this to source sc

Re: [PATCH v2 5/8] builtins/source: parse the -i option

ent. In addition, considering the purpose of the restricted shells, we would not need to provide the new feature to the restricted shells. Co-authored-by: Koichi Murase --- builtins/source.def | 21 - 1 file changed, 8 insertions(+), 13 deletions(-) diff --git a/

Re: Re: [PATCH v2 1/8] findcmd: parameterize path variable in functions

2024年5月14日(火) 12:32 Matheus Afonso Martins Moreira : > > The patches touch the interface of many functions > > I added one external function: find_in_path_var. > The other changes are all static and local. > > > It seems essentially equivalent to just calling > > find_in_path (list->word->word,

Re: [PATCH v2 6/8] builtins/source: use source path in isolated mode

2024年5月15日(水) 5:16 Chet Ramey : > On 5/13/24 10:53 PM, Matheus Afonso Martins Moreira wrote: > >> I think we should restrict the search in > >> BASH_SOURCE_PATH and shouldn't fall back to local files. > > > > I concur but thought it'd be wise to discuss it first so I left it in. > > Searching the c

Re: [PATCH v2 6/8] builtins/source: use source path in isolated mode

2024年5月15日(水) 5:02 Chet Ramey : > > In that case, > > we need to make sure that `find_in_path_var()' returns NULL in the > > case of empty BASH_SOURCE_PATH. > > Do you mean BASH_SOURCE_PATH= ? Yes. Or more precisely, I intended to include both `BASH_SOURCE_PATH=' and `unset -v BASH_SOURCE_PATH'.

Re: [PATCH v2 8/8] shell: restrict BASH_SOURCE_PATH when appropriate

2024年5月15日(水) 4:55 Chet Ramey : > On 5/13/24 6:37 AM, Matheus Afonso Martins Moreira wrote: > > Make the BASH_SOURCE_PATH variable read-only and unsettable > > when the shell is operating in restricted mode. This variable > > should be restricted for the same reasons why PATH is restricted. > > Or

Re: [PATCH v2 5/8] builtins/source: parse the -i option

2024年5月15日(水) 4:51 Chet Ramey : > What do folks think about forcing an option to enable using > BASH_SOURCE_PATH? Should it be required? Is it necessary? (I personally > think it is not.) We discussed this briefly last week but without any > conclusion. Either works for me (suppose the `source' bu

Re: proposed BASH_SOURCE_PATH

2024年5月14日(火) 15:09 Martin D Kealey : > 1. I therefore propose that where a relative path appears in > BASH_SOURCE_PATH, it should be taken as relative to the directory > containing $0 (after resolving symlinks), rather than relative to $PWD. > > As an interim step until that's implemented, please

Re: [PATCH v2 1/8] findcmd: parameterize path variable in functions

2024年5月13日(月) 19:38 Matheus Afonso Martins Moreira : > The PATH variable is hard coded in the user command finder function. > Transforming it into an argument allows reusing the file finding logic > with variables other than PATH, making the code more flexible. I think what was suggested by Chet i

Re: [PATCH v2 3/8] builtins/source: extract file executor function

2024年5月13日(月) 19:39 Matheus Afonso Martins Moreira : > Extract into a dedicated helper function the code which loads > the contents of a file and executes it in the current shell. > This separates this useful functionality from the path resolution > mechanism used by the source builtin. To other r

Re: [PATCH v2 6/8] builtins/source: use source path in isolated mode

2024年5月13日(月) 19:40 Matheus Afonso Martins Moreira : > diff --git a/builtins/source.def b/builtins/source.def > index 26040e70..7f870bfe 100644 > --- a/builtins/source.def > +++ b/builtins/source.def > @@ -177,6 +178,27 @@ search_for_file (WORD_LIST *list) > [...] > +static char * > +isolated_searc

Re: [PATCH 9/9] variables: define default BASH_LIBRARIES_PATH

2024年5月8日(水) 9:13 Matheus Afonso Martins Moreira : > Please let me know if you agree to any of the following paths: > > ~/.local/share/bash:/usr/share/bash > ~/.local/share/bash/lib:/usr/share/bash/lib The former is absolutely no. If we choose that location to store scripts, no place is le

Re: [PATCH 4/9] bashgetopt: define long option shortener function

2024年5月8日(水) 8:11 Matheus Afonso Martins Moreira : > Some builtins do support long options, even though it seems > to not be documented. I didn't know the `type' builtin recognizes those forms. > Also, I do realize that there's a big all caps warning > in the file saying that "THIS SHOULD REALLY

Re: Re: [PATCH 1/9] builtins: extract file content executor function

2024年5月8日(水) 6:13 Matheus Afonso Martins Moreira : > > By exposing this function in `common.h', > > this effectively becomes a part of the public > > interface for loadable builtins. > > [...] > > Are all external functions defined in all files inside the > builtins directory exposed as part of a p

Re: Re: [PATCH 0/4] Add import builtin

2024年5月8日(水) 7:12 Matheus Afonso Martins Moreira : > > a language that has no support for namespaces, awkward scoping rules, > > a problematic implementation of name references, and so on. > > I could at least attempt to address those issues. I don't think these are requests to you. Those topics (

Re: [PATCH 0/4] Add import builtin

2024年5月7日(火) 23:17 Chet Ramey : > On 5/6/24 1:21 AM, Phi Debian wrote: > > Well even this is unclear 'BASH_SOURCE_PATH get searched before PATH' or > > 'BASH_SOURCE_PATH get searched instead of' or even 'BASH_SOURCE_PATH get > > searched after PATH' > > Because we haven't discussed the semantics. T

Re: Re: Re: [PATCH 0/4] Add import builtin

2024年5月7日(火) 21:40 Martin D Kealey : > I wonder if it would be useful to add options to 'command': Thanks for your suggestion. I still think those should be implemented by shell functions, but that interface sounds interesting. That seems to cover most of the cases I raised. However, those are mer

Re: Re: Re: [PATCH 0/4] Add import builtin

2024年5月7日(火) 2:11 Matheus Afonso Martins Moreira : > >> A native way to source libraries. Built into bash, available to all users. > > That's the source builtin. > > It looks for scripts in directories meant for executables. > It prefers files with the executable bit set. Is this related to [1]?

Re: [PATCH 9/9] variables: define default BASH_LIBRARIES_PATH

2024年5月5日(日) 18:57 Matheus Afonso Martins Moreira : > +/* The default value of the BASH_LIBRARIES_PATH variable > + which is used by source -l instead of PATH. */ > +#ifndef DEFAULT_LIBRARIES_PATH > +#define DEFAULT_LIBRARIES_PATH \ > + "~/.local/lib/bash:/usr/local/lib/bash:/usr/lib/bash" I do

Re: [PATCH 8/9] builtins/source: search libraries in library mode

2024年5月5日(日) 18:57 Matheus Afonso Martins Moreira : > - filename = search_for_file (list); > + if (!library_mode) > +filename = search_for_file (list); > + else > +filename = search_for_library (list); I expected that the source builtin without the flag would also consider BASH_LIBRARIE

Re: [PATCH 4/9] bashgetopt: define long option shortener function

2024年5月5日(日) 18:57 Matheus Afonso Martins Moreira : > Define the shorten_long_options helper function that converts Let's talk about whether we should support the long form of the option in this patch set. 2024年5月7日(火) 2:11 Matheus Afonso Martins Moreira : > > incomplete addition of the long opti

Re: [PATCH 2/9] findcmd: parameterize path variable in functions

2024年5月5日(日) 18:56 Matheus Afonso Martins Moreira : > The PATH variable is hard coded in the user command finder function. > Transforming it into an argument allows reusing the file finding logic > with variables other than PATH, making the code more flexible. There is already a very similar featu

Re: [PATCH 1/9] builtins: extract file content executor function

The patches don't apply to the devel branch. You've made patches on top of the master branch, but the master branch of Bash is just a release branch, where each commit corresponds to a release. You should normally work based on the devel branch. 2024年5月5日(日) 18:56 Matheus Afonso Martins Moreira :

Re: Re: Re: [PATCH 0/9] Add library mode to source builtin

Honestly, I share the same feeling as the others about the name `library'. The use of the ``library'' feels something wrong in this context. I still think the variable name should be BASH_SOURCE_PATH. I've suggested `-l' as an *example*, but that's just because I couldn't come up with another lett

Re: 5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions

2024年5月6日(月) 23:01 Koichi Murase : > > The whole issue here is that in some circumstances bash defers that > > notification too long, and doesn't do it before the user can run `jobs'. > > You don't need to change `jobs' so it doesn't print foreground job

Re: 5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions

Thank you. 2024年5月6日(月) 22:16 Chet Ramey : > On 5/4/24 8:47 PM, Koichi Murase wrote: > > If we take the theory that « the notification of the signaled > > foreground jobs are required because it is not considered `reported' > > by `$?' », given that the shells don&#

Re: Re: [PATCH 0/4] Add import builtin

2024年5月6日(月) 14:28 Matheus Afonso Martins Moreira : > > I fail to see how this could possibly save "thousands and thousands > > of lines of code". > > How many lines of code were needed to implement the module managers? > Probably a lot of lines. I guessed it was in the "thousands of lines" > ball

Re: Re: Re: Re: [PATCH 0/4] Add import builtin

2024年5月5日(日) 13:36 Matheus Afonso Martins Moreira : > > If your purpose is just to solve a small inconvenience of the `source' > > builtin mixing the namespaces of local scripts, "libraries", and > > executables, I think the suggested `source -i' or `source -l' would be > > fine. I think no additio

Re: 5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions

2024年5月3日(金) 23:36 Chet Ramey : > > To the email [2]. In particular, to the question in the second paragraph > > [2]. > > OK. No, it doesn't make sense to do that. > > The better option is to change the notification strategy so that the jobs > list doesn't contain terminated unnotified foreground

Re: Re: Re: [PATCH 0/4] Add import builtin

If your purpose is just to solve a small inconvenience of the `source' builtin mixing the namespaces of local scripts, "libraries", and executables, I think the suggested `source -i' or `source -l' would be fine. I think no additional reasoning is needed. In this case, the "#pragma once" feature wo

Re: Re: Re: [PATCH 0/4] Add import builtin

I think we can separate the discussion about the module system and the source builtin. What is the primary purpose or the reasoning behind the suggestion? If the purpose is to introduce a standard module system in Bash, I'll have to be opposed to the change because I think the current suggestion f

Re: Re: [PATCH 0/4] Add import builtin

2024年5月3日(金) 14:45 Matheus Afonso Martins Moreira : > This is suboptimal. In case the library script cannot found > in the intended directories, it will needlessly search every > other entry in PATH for it, despite the fact they will contain > only unsuitable executables and programs. There is no

Re: [PATCH 0/4] Add import builtin

2024年5月3日(金) 11:17 Lawrence Velázquez : > If "import" were qualitatively different from "source" (say it > integrated some sort of namespace functionality), then it would be > more compelling. That sounds interesting. It's a bit unrelated to the main discussion, but I was wondering if it is possib

Re: [PATCH 0/4] Add import builtin

2024年5月3日(金) 9:56 Matheus Afonso Martins Moreira : > The source builtin uses the PATH variable for resolving file names > which means they would have to be placed alongside normal executables > which could cause confusion. You can prepare a separate directory for the script files to source and put

Re: 5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions

2024年5月1日(水) 22:58 Chet Ramey : > Yes, and I said I could work around this case. Thank you for your consideration. > > [1] https://lists.gnu.org/archive/html/bug-bash/2022-10/threads.html#00054 > > [2] https://lists.gnu.org/archive/html/bug-bash/2022-11/threads.html#00049 > > (continued. I haven'

Re: 5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions

2024年4月30日(火) 5:07 Chet Ramey : > OK, let's explore this again. I haven't yet been convinced by the previous discussion [1,2] about the reporting of the foreground dead jobs in the trap handler, but this time, the situation is slightly different. The `jobs' builtin reports the foreground dead jobs

5.3-alpha: value substitutions remove unrelated REPLY when its REPLY is removed

When REPLY that is prepared by a value substitution ${ ; } is removed by , the value substitution removes the previous-scope REPLY, which is not prepared by the value substitution, after the execution of . $ bash-5.3-alpha --norc $ unlocal() { unset -v "$@"; } $ f2() { unlocal "$1"; echo "f2:$1=${

5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions

I'm currently testing my framework with 5.3-alpha. In 5.3-alpha and the devel branch, foreground dead jobs are reported by the `jobs' builtin with function substitutions: $ bash-5.3-alpha --norc $ a=${ (true) }; b=${ jobs; }; declare -p b declare -- b="[1] Done( true )" I ex

Re: Bug tracking

2024年4月1日(月) 9:35 Martin D Kealey : > On Mon, 11 Dec 2023, 05:19 Chet Ramey, wrote: > > On 11/30/23 5:18 AM, Martin D Kealey wrote: > > > If there's a bug tracking system beyond "threads in a mailing list", I'd > > > like to know how I can get access to it. > > > > https://savannah.gnu.org/support

Re: exec redirection is undone if fd (>9) has O_CLOEXEC

2024年2月24日(土) 15:32 Emanuele Torre : > On Sat, Feb 24, 2024 at 02:11:25PM +0900, Koichi Murase wrote: > > I have a question. Maybe it's not technically a bug as fd > 9 is > > involved, but the resulting behavior appears to be strange. I > > received some reports

exec redirection is undone if fd (>9) has O_CLOEXEC

I have a question. Maybe it's not technically a bug as fd > 9 is involved, but the resulting behavior appears to be strange. I received some reports from users in my project and tried to find out what is happening. This is a reduced case: #!/usr/bin/env bash enable -f /path/to/lib/bash/fdfl

  1   2   3   4   >