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

Re: It is possible to remove the readonly attribute from {BASH, SHELL}OPTS

2024年2月20日(火) 18:12 Martin D Kealey : > So yes please, I'd like "local" to push a new variable definition that > inherits nothing from any outer one: not name-ref, not read-only, not array > (of any kind), not assignment modifiers (integer, upper-case, lower-case), > and above all, not any previous

Re: [PATCH] tests/array.tests: using grep -E instead of egrep

2024年2月19日(月) 18:01 Lawrence Velázquez : > On Mon, Feb 19, 2024, at 4:08 AM, Xiangyu Chen wrote: > > From: Xiangyu Chen > > > > The console ouput lots of egrep warning message, those message causes > > test case fail in diff stage. > > On what system does this happen? The proposed changes might b

Re: declare -A +A

2024年2月13日(火) 6:13 Chet Ramey : > Only for indexed and associative arrays, since those are the attributes > that cause changes in the underlying value storage format. That's different > than turning the integer attribute on and off, for instance. > > Should it be an actual error, or should the shel

Re: About `M-C-e` expand result `'` failed

Thank you for the discussion. 2024年2月4日(日) 12:59 Martin D Kealey : > I am generally concerned about breaking changes that affect existing > scripts, but I see changes to readline as less problematic, I also assume shell scripts, but shell scripts for interactive settings. Interactive settings ca

Re: About `M-C-e` expand result `'` failed

> Before Bash 3.2 P.S. Sorry, I meant "In Bash 3.2 and before,", where 3.2 is included in the statement.

Re: About `M-C-e` expand result `'` failed

I was just watching the discussion because I thought the existing behavior would never be changed as it behaved this way for a long time. However, I now think I should leave a comment because even Martin (who I believed was one of the careful people about backward compatibility as seen in [1,2]) se

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

Re: issue with debug trap

2023年12月16日(土) 6:22 Giacomo Comes : The original post asks the reason for the difference in the status between the following two cases: if ((0)); then :; else echo "here \$? is 1"; fi if ((0)); then :; fi; echo "but here \$? is 0" and the answer is that the former returns the status of ((0)) (wh

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

2023年12月10日(日) 15:58 Koichi Murase : > 2023年12月10日(日) 14:13 Martin D Kealey : > > But even if you still thought this was worth doing, it wasn't necessary to > > make $((10#)) completely illegal: Bash could look ahead and only intervene > > if the following character is &#

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

2023年12月11日(月) 23:37 Chet Ramey : > On 12/10/23 1:58 AM, Koichi Murase wrote: > > It's too late, but a better way could have been introducing the > > function-call syntax and supporting signed n-adic numbers through e.g. > > « int([-+]digits, n) ». > > You're

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

2023年12月10日(日) 14:13 Martin D Kealey : > But even if you still thought this was worth doing, it wasn't necessary to > make $((10#)) completely illegal: Bash could look ahead and only intervene > if the following character is '-' (affecting $((10#-digits)) but not > $((10#))). I'm not a big fan of

Re: bash should consult .config/bash/...

2023年12月10日(日) 13:23 Oğuz : > Trends come and go. If there is demand for this feature bash should do it > by honoring an environment variable like BASH_HOME when looking for rc > files instead of exploring a fixed path. In that case, a question would be what would be the standard way to specify th

Re: bash should consult .config/bash/...

2023年12月10日(日) 12:10 jidanni : > Maybe on the list of config files bash looks at, > there should be also .config/bash/... as that is There was a discussion: https://lists.gnu.org/archive/html/bug-bash/2021-05/threads.html#00024 https://lists.gnu.org/archive/html/bug-bash/2021-11/threads.html#0003

Re: "read -s -n999 -t0.01 key" hangs until keypress

2023年10月18日(水) 0:01 Chet Ramey : > He claims to have tested on bash-5.2. I just can't reproduce it. Oh..., I somehow thought they were both 5.1 (5.1.16 and 5.1.15). I didn't notice my misreading even when I extracted the quoted part. Thanks for pointing it out. -- Koichi

Re: "read -s -n999 -t0.01 key" hangs until keypress

2023年10月12日(木) 19:18 Bodo Thiesen : > Tested versions: > bash-5.1.16 with readline 8.1.2 > bash-5.2.15 with readline 8.2.1 You are using Bash 5.1, but I think it should have been already fixed in Bash 5.2. There were similar reports [1-3] (you may compare the test cases found there

Re: 5.3: job error caused by funsub + bind + loadable builtin

2023年10月2日(月) 23:15 Chet Ramey : > On 9/15/23 12:47 AM, Koichi Murase wrote: > > Description: > > > >DEBUG warnings are produced for inconsistent numbers of dead jobs > >when a function substitution is used with the loadable builtin > >`sleep' insi

5.3: job error caused by funsub + bind + loadable builtin

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.4.10-100.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Aug 11 15:18:39 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux Machine Type

Re: nofork command substitution

2023年5月25日(木) 21:13 Robert Elz : > | Does that mean ${(command)} would be explicitly unsupported even > | though {(command)} is allowed for the brace grouping? > > The two are mostly unrelated. Yes, they are independent, but there is still a "choice" to make the new grammar similar to the exis

Re: nofork command substitution

2023年5月24日(水) 22:27 Chet Ramey : > > [...] > > Thanks for testing it. Thank you for all the explanations and clarifications. > Both are valid, but don't get too fond of ${(command)} -- I'm going to > remove it in favor of people using ${ (command); } if they want a subshell. Does that mean ${(co

Re: nofork command substitution

2023年5月16日(火) 2:35 Chet Ramey : > The latest devel branch push has the initial implementation of `nofork' > command substitution. The excerpt from the info manual describing it is > appended. > > Please test it out, and find the places I missed. Thanks. I really appreciate that the feature ${ comm

Re: [PATCH] compgen -V option (store output in array)

2023年4月18日(火) 0:59 Chet Ramey : > Once you have -V, isn't -z superfluous? It's just > > compgen -V varname options word > printf '%s\0' "${varname[@]}" > > right? What am I missing? You are right. Actually, when I implemented -z, I also initially thought about the possibility to add an option to s

  1   2   3   4   >