Re: [PATCH] allow quoting completions w/o filename treatment

On Fri, Apr 14, 2023, 17:20 Grisha Levit wrote: > > The attached patch hopefully addresses these difficulties by allowing for > the decoupling of filename-specific match handling from match quoting. > Thanks very much for merging this. It adds a new completion option `allquote' (I'm not quite h

Docs: Mention that hash resets after changing PATH

Hello, I noticed that there's no mention in the manual that, when the PATH changes, "hash -r" is run. I think that would be a nice addition, possibly on "4.1 Bourne Shell Builtins / hash" Thanks.

Re: [PATCH] allow quoting completions w/o filename treatment

On 7/5/23 3:07 AM, Grisha Levit wrote: I noticed you went with "fullquote" for the completion option name and it occurs to me that this might be a bit confusing for users because of the existing "complete_fullquote" shell option. Maybe just "quote" would work? I don't mean to bikeshed this but

Re: Completion list updates on dynamic builtin load

On 7/4/23 4:10 AM, Grisha Levit wrote: The `enabled' and `disabled' completion lists don't get updated when a dynamic builtin is loaded: Thanks for the report. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ra

Re: Docs: Mention that hash resets after changing PATH

On 7/5/23 6:36 AM, Sebastian Carlos wrote: Hello, I noticed that there's no mention in the manual that, when the PATH changes, "hash -r" is run. I think that would be a nice addition, possibly on "4.1 Bourne Shell Builtins / hash" Thanks; good catch. -- ``The lyf so short, the craft so long t

Re: [PATCH] leak in rl_filename_completion_function

On Wed, May 31, 2023 at 6:23 PM Grisha Levit wrote: > > If rl_filename_rewrite_hook returns a new string for a filename (which > I guess only happens on macOS with bash), it is in most cases not > free-d. > diff --git a/lib/readline/complete.c b/lib/readline/complete.c > index bf7cc856..99556a35

Re: [PATCH] leak in rl_filename_completion_function

On 7/5/23 3:25 PM, Grisha Levit wrote: On Wed, May 31, 2023 at 6:23 PM Grisha Levit wrote: If rl_filename_rewrite_hook returns a new string for a filename (which I guess only happens on macOS with bash), it is in most cases not free-d. I think this one got dropped. I think this one might h

'${#@}' expands to an integer

Here's some code as observed "in the wild:" `[[ ${#@} -ne 0 ]] && ...` Perhaps the parser is reading this as an incomplete parameter transformation? It seems from context that the original intent was simply... `[[ $# -ne 0 ]] && ...` As it happens, the effect appears to be the same either w

Re: '${#@}' expands to an integer

On Wed, Jul 5, 2023, at 9:01 PM, Wiley Young wrote: > Here's some code as observed "in the wild:" > > `[[ ${#@} -ne 0 ]] && ...` > > Perhaps the parser is reading this as an incomplete parameter > transformation? It seems from context that the original intent was simply... > > `[[ $# -ne 0 ]] &

[PATCH] confusing/obsolete handling of test -t operator (and doc warnings against using -o/-a)

Hello, test -t X Always returns false and doesn't report an error about that invalid number (beside the point here, but in ksh/zsh, that X is treated as an arithmetic expression and evaluates to 0 if $X is not set). While: test -t X -a Y returns a "too many arguments" error. test X -a -t -a Y