Re: Feature Request: Add option to make completed values always become properly escaped
On Mon, Feb 21, 2022 at 4:32 PM Chet Ramey wrote:
> What does `properly quoted' mean here and how does it differ from the
> quoting you get when you force complete to treat the completions as
> filenames with `complete -o filenames'?
I realized that a "quote all ' option is not what I want since I need
to rely on nospace and manual adding of space when a single result is
valid. Having "quote all" enabled backslash escapes the space as
well. What I need more is an option that allows replacing the current
word including the quote (', ", or $') that begins it with the result
as is rather than appending the result to the quote. Maybe a method
that can prevent space from being added on a specific completion
result can be added instead too.
I also tried using the filenames option (which I remembered using
before) but it adds a slash to the result when the result matches a
directory. For example, "test" which refers to a task becomes
"test/".
--
konsolebox
Re: Feature Request: Add option to make completed values always become properly escaped
On Fri, Feb 25, 2022 at 8:29 AM konsolebox wrote:
> What I need more is an option that allows replacing the current
> word including the quote (', ", or $') that begins it with the result
> as is rather than appending the result to the quote.
... because the result is already quoted with `printf %q`.
> Maybe a method
> that can prevent space from being added on a specific completion
> result can be added instead too.
For this to work consistently, single-result directories should always
be added with a space as well.
--
konsolebox
Re: Feature Request: Add option to make completed values always become properly escaped
On 2/25/22 3:29 AM, konsolebox wrote:
On Mon, Feb 21, 2022 at 4:32 PM Chet Ramey wrote:
What does `properly quoted' mean here and how does it differ from the
quoting you get when you force complete to treat the completions as
filenames with `complete -o filenames'?
I realized that a "quote all ' option is not what I want since I need
to rely on nospace and manual adding of space when a single result is
valid. Having "quote all" enabled backslash escapes the space as
well. What I need more is an option that allows replacing the current
word including the quote (', ", or $') that begins it with the result
as is rather than appending the result to the quote. Maybe a method
that can prevent space from being added on a specific completion
result can be added instead too.
So `noquote' doesn't work for this purpose?
If you want to modify the options for the currently-running completion
function, you could use `compopt'.
I also tried using the filenames option (which I remembered using
before) but it adds a slash to the result when the result matches a
directory. For example, "test" which refers to a task becomes
"test/".
That's an interesting idea for another completion option. Maybe something
like `-o markdirs' or `-o nomarkdirs' since it is on by default. It's
already a bindable readline option.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: declare -x non-exportable variable types
On 2/22/22 1:35 PM, Léa Gris wrote: declare -x variable with unexportable flag/type is handled quite inconsistently: $ unset int_value && declare -ix int_value=42 && bash -c 'declare -p int_value' declare -x int_value="42" You can't export attributes, since the only vehicle to export objects to child processes is environment variables. In this case, the variable was found in the environment at shell startup, so it was given the export attribute in the child shell. That is standard behavior, defined by POSIX. $ unset array && declare -ax array=(foo bar) && bash -c 'declare -p array' bash: line 1: declare: array: not found $ unset assoc && declare -Ax assoc=([key1]=foo [key2]=bar) && bash -c 'declare -p assoc' bash: line 1: declare: assoc: not found You can't export array variables, period. $ unset upper && declare -ux upper='hello' && bash -c 'declare -p upper' declare -x upper="HELLO" $ unset lower && declare -lx lower='WORLD' && bash -c 'declare -p lower' declare -x lower="world" You can't export attributes, only variable names and values. $ unset str && unset -n ref && declare str=hello && declare -nx ref=str && bash -c 'declare -p ref' declare -x ref="str" You told declare to act on the nameref variable (-n) and export it (-x). You still can't export attributes. The inconsistency is that sometimes: - It exports the variable with its translated value (integer to string, upper, lower) Because these attributes result in behavior at assignment time. The converted value is what is stored and returned when the variable is referenced. The original value used in the assignment statement is discarded after being converted. - It exports nothing of array or associative array, despite that in Bash, array referenced without an index returns the first element, but not when exported. Bash doesn't export array variables. There is code to do it in there, and has been for a long time, but it's not enabled. - It export the reference name of nameref, despite it could export the value of the referee. If you want to export the referenced variable, don't tell declare to operate on the name reference instead. Something like unset str && unset -n ref && declare str=hello && declare -n ref=str && declare -x ref ./bash -c 'declare -p str ref' would easily do what you want. My stance on this is that there is no real consistent way to export variables with incompatible flags; and I wonder if to be consistent, the declaration statement could be erroring instead, when the other variable flag are incompatible with export. There is no way to export attributes, period, regardless of whether they are `incompatible with export.' This means that the export command would expand the variable value before exporting, but the declare, local and typeset statements would error if flags are incompatible with -x export. There are no flags that are compatible or incompatible with export. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: declare -x non-exportable variable types
Le 25/02/2022 à 16:49, Chet Ramey écrivait : You can't export array variables, period. You can't export attributes, only variable names and values. You still can't export attributes. There is no way to export attributes Chet, I heard you, I understood it and I knew it before, while I was writing my message, and still now. It feels like that you were either in a bad mood or that I didn't manage to express my remarks and thoughts as clearly as I would have liked. I'm sorry for what happened and I didn't expect to receive such a tense reaction. Now that you and I are, were and still are (I reassure you) in absolute agreement with: "Bash variable attributes and, or arrays are incompatible with environment variables" (undisputed fact)... Is it possible that: if these variables are passed explicitly as environment variables with -x or export : - Either Bash returns an error because of "variable flags are incompatible with the environment, and it's a mistake to export Bash variables with flags", rather than having different behaviours (pass value, nothing, name...) based on the original Bash variable flags/type? - Or that Bash should now be able to "convert" the value as it does now, but in a more consistent way? - Or that the documentation contains an explicit description of what happens when one tries to export a Bash variable with flags/types (even just documented as: "The result of exporting Bash variables with attributes is indeterminate"), which might be an appropriate clarification? -- Léa Gris
Re: declare -x non-exportable variable types
On 2/25/22 12:55 PM, Léa Gris wrote: Le 25/02/2022 à 16:49, Chet Ramey écrivait : You can't export array variables, period. You can't export attributes, only variable names and values. You still can't export attributes. There is no way to export attributes Chet, I heard you, I understood it and I knew it before, while I was writing my message, and still now. It feels like that you were either in a bad mood or that I didn't manage to express my remarks and thoughts as clearly as I would have liked. OK. I don't think my response was especially tense (now, terse, maybe). I simply disagree with much of your premise. Now that you and I are, were and still are (I reassure you) in absolute agreement with: "Bash variable attributes and, or arrays are incompatible with environment variables" (undisputed fact)... Variables have names, values, and attributes. Environment variables don't have enough information to contain all three (or two, in the case of arrays, without some special encoding). Is it possible that: if these variables are passed explicitly as environment variables with -x or export : - Either Bash returns an error because of "variable flags are incompatible with the environment, and it's a mistake to export Bash variables with flags", rather than having different behaviours (pass value, nothing, name...) based on the original Bash variable flags/type? But you have not shown such `different behaviors'. In the case of array variables, not exporting them is a conscious choice based on the issues encoding the values, and that is documented. Is that what you mean? - Or that Bash should now be able to "convert" the value as it does now, but in a more consistent way? I simply don't see the inconsistency you claim is there. Bash exports names and values for variables to which you assign the export attribute. - Or that the documentation contains an explicit description of what happens when one tries to export a Bash variable with flags/types (even just documented as: "The result of exporting Bash variables with attributes is indeterminate"), which might be an appropriate clarification? OK, what's indeterminate about it? I showed how the behavior from your first message was all consistent. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: declare -x non-exportable variable types
On Fri, Feb 25, 2022 at 8:52 PM Chet Ramey wrote: > On 2/25/22 12:55 PM, Léa Gris wrote: > > Le 25/02/2022 à 16:49, Chet Ramey écrivait : > > > >> You can't export array variables, period. You can't export attributes, > >> only variable names and values. You still can't export attributes. > There > >> is no way to export attributes > > > > Chet, I heard you, I understood it and I knew it before, while I was > > writing my message, and still now. > > > > It feels like that you were either in a bad mood or that I didn't manage > to > > express my remarks and thoughts as clearly as I would have liked. > > OK. I don't think my response was especially tense (now, terse, maybe). I > simply disagree with much of your premise. > > > Now that you and I are, were and still are (I reassure you) in absolute > > agreement with: "Bash variable attributes and, or arrays are > incompatible > > with environment variables" (undisputed fact)... > > Variables have names, values, and attributes. Environment variables don't > have enough information to contain all three (or two, in the case of > arrays, without some special encoding). > you map those as extension in free space, just like you do with your function to children passment my only comment to this > > > > Is it possible that: if these variables are passed explicitly as > > environment variables with -x or export : > > > > - Either Bash returns an error because of "variable flags are > incompatible > > with the environment, and it's a mistake to export Bash variables with > > flags", rather than having different behaviours (pass value, nothing, > > name...) based on the original Bash variable flags/type? > > But you have not shown such `different behaviors'. In the case of array > variables, not exporting them is a conscious choice based on the issues > encoding the values, and that is documented. Is that what you mean? > > > > > - Or that Bash should now be able to "convert" the value as it does now, > > but in a more consistent way? > > I simply don't see the inconsistency you claim is there. Bash exports names > and values for variables to which you assign the export attribute. > > > - Or that the documentation contains an explicit description of what > > happens when one tries to export a Bash variable with flags/types (even > > just documented as: "The result of exporting Bash variables with > attributes > > is indeterminate"), which might be an appropriate clarification? > > OK, what's indeterminate about it? I showed how the behavior from your > first message was all consistent. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ > >
