See here [1] for the code snippet used in one of my forked project:

if [[ ${SHELLOPTS} =~ (vi|emacs) ]]; then
# https://github.com/dvorka/hstr/blob/master/CONFIGURATION.md#bash-binding-hstr-to-keyboard-shortcut
# https://www.computerhope.com/unix/bash/bind.htm
#I'm still not so clear on whether the syntax is case sensitive.
bind -x '"\er": trap '' 2; READLINE_LINE=$(percol_sel_log_history) READLINE_POINT=; trap 2'

#bind -x '"\C-\M-R": trap '' 2; READLINE_LINE=$(percol_sel_log_master_history) READLINE_POINT=; trap 2'
#bind -x '"\C-\M-r": trap '' 2; READLINE_LINE=$(percol_sel_log_master_history) READLINE_POINT=; trap 2'
#bind -x '"\e\C-R": trap '' 2; READLINE_LINE=$(percol_sel_log_master_history) READLINE_POINT=; trap 2'
#bind -x '"\e\C-r": trap '' 2; READLINE_LINE=$(percol_sel_log_master_history) READLINE_POINT=; trap 2'
fi

I've 2 questions on the above code snippet:

1. For the short keys binding to bind command, is the character case-sensitive or not?
2. What does the ``READLINE_POINT='' used above do?

[1] https://github.com/hongyi-zhao/ariadne/blob/b094e0634c4d5890b5ca48fa0a0974adcbe177b0/ariadne.sh#L229

Regards,
HY

On Friday, September 3, 2021 at 2:26:12 PM UTC+8, hongy...@gmail.com wrote:
> See here [1] for the code snippet used in one of my forked project:
>
> if [[ ${SHELLOPTS} =~ (vi|emacs) ]]; then
> # https://github.com/dvorka/hstr/blob/master/CONFIGURATION.md#bash-binding-hstr-to-keyboard-shortcut
> # https://www.computerhope.com/unix/bash/bind.htm
> #I'm still not so clear on whether the syntax is case sensitive.
> bind -x '"\er": trap '' 2; READLINE_LINE=$(percol_sel_log_history) READLINE_POINT=; trap 2'
>
> #bind -x '"\C-\M-R": trap '' 2; READLINE_LINE=$(percol_sel_log_master_history) READLINE_POINT=; trap 2'
> #bind -x '"\C-\M-r": trap '' 2; READLINE_LINE=$(percol_sel_log_master_history) READLINE_POINT=; trap 2'
> #bind -x '"\e\C-R": trap '' 2; READLINE_LINE=$(percol_sel_log_master_history) READLINE_POINT=; trap 2'
> #bind -x '"\e\C-r": trap '' 2; READLINE_LINE=$(percol_sel_log_master_history) READLINE_POINT=; trap 2'
> fi
>
> I've 2 questions on the above code snippet:
>
> 1. For the short keys binding to bind command, is the character case-sensitive or not?
> 2. What does the ``READLINE_POINT='' used above do?

I tried with the following two bind commands, and they give the exactly same behavior:

bind -x '"\er": trap '' 2; READLINE_LINE=$(percol_sel_log_history) READLINE_POINT=; trap 2'
bind -x '"\er": trap '' 2; READLINE_LINE=$(percol_sel_log_history); READLINE_POINT=${#READLINE_LINE}; trap 2'

>
> [1] https://github.com/hongyi-zhao/ariadne/blob/b094e0634c4d5890b5ca48fa0a0974adcbe177b0/ariadne.sh#L229
>
> Regards,
> HY

On 03.09.2021 08:26, hongy...@gmail.com wrote:
> See here [1] for the code snippet used in one of my forked project:
>
> if [[ ${SHELLOPTS} =~ (vi|emacs) ]]; then

Given that SHELLOPTS is a colon-separated list this test appears to
be error prone.

Janis

On Saturday, September 4, 2021 at 11:19:08 PM UTC+8, Janis Papanagnou wrote:
> On 03.09.2021 08:26, hongy...@gmail.com wrote:
> > See here [1] for the code snippet used in one of my forked project:
> >
> > if [[ ${SHELLOPTS} =~ (vi|emacs) ]]; then
> Given that SHELLOPTS is a colon-separated list this test appears to
> be error prone.

What is the special situation that caused its failure? It really works on my side now:

$ echo ${SHELLOPTS}
braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor
$ [[ ${SHELLOPTS} =~ (vi|emacs) ]] && echo ok
ok

HY

On 05.09.2021 02:46, hongy...@gmail.com wrote:
> On Saturday, September 4, 2021 at 11:19:08 PM UTC+8, Janis Papanagnou wrote:
>> On 03.09.2021 08:26, hongy...@gmail.com wrote:
>>> See here [1] for the code snippet used in one of my forked project:
>>>
>>> if [[ ${SHELLOPTS} =~ (vi|emacs) ]]; then
>> Given that SHELLOPTS is a colon-separated list this test appears to
>> be error prone.
>
> What is the special situation that caused its failure?

If, for example, "vi" is or becomes part of any of the shell option
substrings.

$ SHELLOPTS=priviledged
$ [[ ${SHELLOPTS} =~ (vi|emacs) ]] && echo ok
ok

> It really works on my side now:

By accident.

The way you do the test is inherently broken.

If you want to test the SHELLOPTS components against two constants you
have to either split SHELLOPTS and compare the parts individually or
add the delimiters (considering not only the colons but also the start
and end of a sting) to the pattern expression.

Janis

>
> $ echo ${SHELLOPTS}
> braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor
> $ [[ ${SHELLOPTS} =~ (vi|emacs) ]] && echo ok
> ok
>
> HY
>

On Sunday, September 5, 2021 at 9:08:49 AM UTC+8, Janis Papanagnou wrote:
> On 05.09.2021 02:46, hongy...@gmail.com wrote:
> > On Saturday, September 4, 2021 at 11:19:08 PM UTC+8, Janis Papanagnou wrote:
> >> On 03.09.2021 08:26, hongy...@gmail.com wrote:
> >>> See here [1] for the code snippet used in one of my forked project:
> >>>
> >>> if [[ ${SHELLOPTS} =~ (vi|emacs) ]]; then
> >> Given that SHELLOPTS is a colon-separated list this test appears to
> >> be error prone.
> >
> > What is the special situation that caused its failure?
> If, for example, "vi" is or becomes part of any of the shell option
> substrings.
>
> $ SHELLOPTS=priviledged
> $ [[ ${SHELLOPTS} =~ (vi|emacs) ]] && echo ok
> ok
> > It really works on my side now:
> By accident.
>
> The way you do the test is inherently broken.
>
> If you want to test the SHELLOPTS components against two constants you
> have to either split SHELLOPTS and compare the parts individually or
> add the delimiters (considering not only the colons but also the start
> and end of a sting) to the pattern expression.

Got it. Now I changed to the following pattern:

$ set -o | egrep '\bon$' | egrep -q '^(vi|emacs)\b'
> Janis
> >
> > $ echo ${SHELLOPTS}
> > braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor
> > $ [[ ${SHELLOPTS} =~ (vi|emacs) ]] && echo ok
> > ok
> >
> > HY
> >

Janis Papanagnou <janis_papanagnou@hotmail.com> writes:

> On 05.09.2021 02:46, hongy...@gmail.com wrote:
>> On Saturday, September 4, 2021 at 11:19:08 PM UTC+8, Janis Papanagnou wrote:
>>> On 03.09.2021 08:26, hongy...@gmail.com wrote:
>>>> See here [1] for the code snippet used in one of my forked project:
>>>>
>>>> if [[ ${SHELLOPTS} =~ (vi|emacs) ]]; then
>>> Given that SHELLOPTS is a colon-separated list this test appears to
>>> be error prone.
>>
>> What is the special situation that caused its failure?
>
> If, for example, "vi" is or becomes part of any of the shell option
> substrings.
>
> $ SHELLOPTS=priviledged
> $ [[ ${SHELLOPTS} =~ (vi|emacs) ]] && echo ok
> ok
>
>> It really works on my side now:
>
> By accident.
>
> The way you do the test is inherently broken.
>
> If you want to test the SHELLOPTS components against two constants you
> have to either split SHELLOPTS and compare the parts individually or
> add the delimiters (considering not only the colons but also the start
> and end of a sting) to the pattern expression.

The other way is to add the delimiters to both sides:

[[ ":$SHELLOPTS:" =~ :(vi|emacs): ]]

--
Ben.

On Sunday, September 5, 2021 at 9:54:05 AM UTC+8, Ben Bacarisse wrote:
> Janis Papanagnou <janis_pa...@hotmail.com> writes:
>
> > On 05.09.2021 02:46, hongy...@gmail.com wrote:
> >> On Saturday, September 4, 2021 at 11:19:08 PM UTC+8, Janis Papanagnou wrote:
> >>> On 03.09.2021 08:26, hongy...@gmail.com wrote:
> >>>> See here [1] for the code snippet used in one of my forked project:
> >>>>
> >>>> if [[ ${SHELLOPTS} =~ (vi|emacs) ]]; then
> >>> Given that SHELLOPTS is a colon-separated list this test appears to
> >>> be error prone.
> >>
> >> What is the special situation that caused its failure?
> >
> > If, for example, "vi" is or becomes part of any of the shell option
> > substrings.
> >
> > $ SHELLOPTS=priviledged
> > $ [[ ${SHELLOPTS} =~ (vi|emacs) ]] && echo ok
> > ok
> >
> >> It really works on my side now:
> >
> > By accident.
> >
> > The way you do the test is inherently broken.
> >
> > If you want to test the SHELLOPTS components against two constants you
> > have to either split SHELLOPTS and compare the parts individually or
> > add the delimiters (considering not only the colons but also the start
> > and end of a sting) to the pattern expression.
> The other way is to add the delimiters to both sides:
>
> [[ ":$SHELLOPTS:" =~ :(vi|emacs): ]]

Thank you for the clever solution
HY

In article <sh15aq$h5k$1@gioia.aioe.org>,
Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
....
>The way you do the test is inherently broken.
>
>If you want to test the SHELLOPTS components against two constants you
>have to either split SHELLOPTS and compare the parts individually or
>add the delimiters (considering not only the colons but also the start
>and end of a sting) to the pattern expression.

Which is surprisingly hard to do (correctly). Splitting strings on
delimiters is not something shell script natively does. Yes, it can be
kludged, but it is harder than it ought to be. Messing around with IFS
seems to be the way, but doing so is hazardous to your health.

If I were doing this, I'd probably end up doing:

$ gawk -F: '{ for (i=1; i<=NF; i++) if ($i == "vi") exit 1 }' <<< "$SHELLOPTS" ||
echo "Yes, vi is set!"
$

Note: Nothing gawk-specific, but of course, both <<< and SHELLOPS are
bash-specific.

--
After 4 years of disastrous screwups, Trump now favors 3 policies that I support:
1) $2K/pp stimulus money. Who doesn't want more money?
2) Water pressure. My shower doesn't work very well; I want Donnie to come fix it.
3) Repeal of Section 230. This will lead to the demise of Face/Twit/Gram. Yey!

On Sunday, September 5, 2021 at 10:06:45 AM UTC+8, Kenny McCormack wrote:
> In article <sh15aq$h5k$1...@gioia.aioe.org>,
> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> ...
> >The way you do the test is inherently broken.
> >
> >If you want to test the SHELLOPTS components against two constants you
> >have to either split SHELLOPTS and compare the parts individually or
> >add the delimiters (considering not only the colons but also the start
> >and end of a sting) to the pattern expression.
> Which is surprisingly hard to do (correctly). Splitting strings on
> delimiters is not something shell script natively does. Yes, it can be
> kludged, but it is harder than it ought to be. Messing around with IFS
> seems to be the way, but doing so is hazardous to your health.
>
> If I were doing this, I'd probably end up doing:
>
> $ gawk -F: '{ for (i=1; i<=NF; i++) if ($i == "vi") exit 1 }' <<< "$SHELLOPTS" ||
> echo "Yes, vi is set!"
> $

Also, the following one:

$ tr ':' '\n' <<< "$SHELLOPTS" | egrep '^(vi|emacs)\b'
emacs

> Note: Nothing gawk-specific, but of course, both <<< and SHELLOPS are
> bash-specific.
>
> --
> After 4 years of disastrous screwups, Trump now favors 3 policies that I support:
> 1) $2K/pp stimulus money. Who doesn't want more money?
> 2) Water pressure. My shower doesn't work very well; I want Donnie to come fix it.
> 3) Repeal of Section 230. This will lead to the demise of Face/Twit/Gram. Yey!

On 05.09.2021 04:06, Kenny McCormack wrote:
> In article <sh15aq$h5k$1@gioia.aioe.org>,
> Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
> ...
>> The way you do the test is inherently broken.
>>
>> If you want to test the SHELLOPTS components against two constants you
>> have to either split SHELLOPTS and compare the parts individually or
>> add the delimiters (considering not only the colons but also the start
>> and end of a sting) to the pattern expression.
>
> Which is surprisingly hard to do (correctly). Splitting strings on
> delimiters is not something shell script natively does. Yes, it can be
> kludged, but it is harder than it ought to be. Messing around with IFS
> seems to be the way, but doing so is hazardous to your health.

Actually adding the colon to the pattern that I suggested I consider
quite simple and straightforward, and Ben's hint to also add colons
to the variable on the left to prevent complex patterns on the right
makes it, so I think, a perfect shell code pattern.

With modern shells (that the OP also uses) we can also use other code
patterns to address that splitting task, for example using ${v//p/r}
as in

grep vi <<EOT
${SHELLOPTS//:/
} EOT

>
> If I were doing this, I'd probably end up doing:
>
> $ gawk -F: '{ for (i=1; i<=NF; i++) if ($i == "vi") exit 1 }' <<< "$SHELLOPTS" ||
> echo "Yes, vi is set!"
> $

An advantage here is that it's obvious to programmers (also of other
languages) what's going on, less obscure than shell code.

I'm a big fan of awk, nonetheless I try to minimize awk/sh transitions
if possible, and resort to pure awk or pure sh code patterns unless
these are overly clumsy.

Janis

In article <sh2a25$tnn$1@gioia.aioe.org>,
Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
>On 05.09.2021 04:06, Kenny McCormack wrote:
>> In article <sh15aq$h5k$1@gioia.aioe.org>,
>> Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
>> ...
>>> The way you do the test is inherently broken.
>>>
>>> If you want to test the SHELLOPTS components against two constants you
>>> have to either split SHELLOPTS and compare the parts individually or
>>> add the delimiters (considering not only the colons but also the start
>>> and end of a sting) to the pattern expression.
>>
>> Which is surprisingly hard to do (correctly). Splitting strings on
>> delimiters is not something shell script natively does. Yes, it can be
>> kludged, but it is harder than it ought to be. Messing around with IFS
>> seems to be the way, but doing so is hazardous to your health.
>
>Actually adding the colon to the pattern that I suggested I consider
>quite simple and straightforward, and Ben's hint to also add colons
>to the variable on the left to prevent complex patterns on the right
>makes it, so I think, a perfect shell code pattern.

You are totally missing the point.

--
He must be a Muslim. He's got three wives and he doesn't drink.

On 05.09.2021 15:07, Kenny McCormack wrote:
> In article <sh2a25$tnn$1@gioia.aioe.org>,
> Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
>> On 05.09.2021 04:06, Kenny McCormack wrote:
>>> In article <sh15aq$h5k$1@gioia.aioe.org>,
>>> Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
>>> ...
>>>> The way you do the test is inherently broken.
>>>>
>>>> If you want to test the SHELLOPTS components against two constants you
>>>> have to either split SHELLOPTS and compare the parts individually or
>>>> add the delimiters (considering not only the colons but also the start
>>>> and end of a sting) to the pattern expression.
>>>
>>> Which is surprisingly hard to do (correctly). Splitting strings on
>>> delimiters is not something shell script natively does. Yes, it can be
>>> kludged, but it is harder than it ought to be. Messing around with IFS
>>> seems to be the way, but doing so is hazardous to your health.
>>
>> Actually adding the colon to the pattern that I suggested I consider
>> quite simple and straightforward, and Ben's hint to also add colons
>> to the variable on the left to prevent complex patterns on the right
>> makes it, so I think, a perfect shell code pattern.
>
> You are totally missing the point.

Maybe. And maybe it's not worth discussing since you don't point out
what it actually is. (If you change your mind, you're welcome.)

I see two views in the discussion; one, the solution-oriented, two,
the narrower IFS based argument. I had been taking the first path.
If I should make a statement about the second view - expressed in
your statement
"Splitting strings on delimiters is not something shell script
natively does"
then I have to disagree with you. Here the showcase in ksh (I'm sure
bash supports similar features and options):

$ x=abc:def:ghi:jkl
$ IFS=: read -A a <<< $x
$ printf "%s\n" "${a[@]}"
abc
def
ghi
jkl

No "messing around", a clear field separator oriented pattern. One
can also write a loop (as in your awk suggestion), or just use grep.

YMMV.

N.B. Of course awk FS is more powerful since it supports regexps,
but this is neither requested here nore the topic.

Janis