Echoing commands in vi visual mode

[Ondrej Oprala]

Hi,
bash-4.3 seems to act differently(better) in vi visual mode, than
previous bash-4 minors.
However, ksh gave a different result all along.
Steps to reproduce:
1. set -o vi
2. meta+k
3. v
4. for i in $(seq 10); do j=$( echo $i$i ); echo $j; done
echo second
# save and close the editor

Results in 4.{1,2}:

# set -o vi
for i in $(seq 1 10);do j=$(echo $i$i ); echo $j; done
seq 1 10)
seq 1 10
echo $i$i )
echo $i$i
11
echo $i$i )
echo $i$i
22
echo $i$i )
echo $i$i
33
echo $i$i )
echo $i$i
44
echo $i$i )
echo $i$i
55
echo $i$i )
echo $i$i
66
echo $i$i )
echo $i$i
77
echo $i$i )
echo $i$i
88
echo $i$i )
echo $i$i
99
echo $i$i )
echo $i$i
1010
echo second
second

Results in 4.3:
# set -o vi
for i in $(seq 1 10);do j=$(echo $i$i ); echo $j; done
seq 1 10
echo $i$i
11
echo $i$i
22
echo $i$i
33
echo $i$i
44
echo $i$i
55
echo $i$i
66
echo $i$i
77
echo $i$i
88
echo $i$i
99
echo $i$i
1010
echo second
second

Results in ksh:

# set -o vi
for i in $(seq 1 10);do j=$(echo $i$i ); echo $j; done
11
22
33
44
55
66
77
88
99
1010
second

What then, does upstream consider correct behaviour?
Thanks

[Chet Ramey]

On 6/11/14, 6:35 AM, Ondrej Oprala wrote:
> Hi,
> bash-4.3 seems to act differently(better) in vi visual mode, than previous
> bash-4 minors.
> However, ksh gave a different result all along.

This isn't standardized, so I'm not worried about small differences between
implementations in something that happens interactively.

Bash uses the `v' option to echo commands as they are read from the temp
file and executed, and that option is inherited by subshells. ksh93
doesn't seem to echo any commands at all. I personally think the bash
behavior is more useful.

Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU ch...@case.edu http://cnswww.cns.cwru.edu/~chet/

[Ondrej Oprala]

On 06/11/2014 07:26 PM, Chet Ramey wrote:
> On 6/11/14, 6:35 AM, Ondrej Oprala wrote:
>> Hi,
>> bash-4.3 seems to act differently(better) in vi visual mode, than previous
>> bash-4 minors.
>> However, ksh gave a different result all along.
> This isn't standardized, so I'm not worried about small differences between
> implementations in something that happens interactively.

True, it's an unimportant detail, though ksh-compliance seems to
always be desired.
Anyway, one of my colleagues wrote a small patch that brings
the behaviour very close to ksh. Could you please comment on it?

>
> Bash uses the `v' option to echo commands as they are read from the temp
> file and executed, and that option is inherited by subshells. ksh93
> doesn't seem to echo any commands at all. I personally think the bash
> behavior is more useful.
>
> Chet

Thanks,
Ondrej

[Chet Ramey]

On 6/26/14, 4:56 AM, Ondrej Oprala wrote:
> On 06/11/2014 07:26 PM, Chet Ramey wrote:
>> On 6/11/14, 6:35 AM, Ondrej Oprala wrote:
>>> Hi,
>>> bash-4.3 seems to act differently(better) in vi visual mode, than previous
>>> bash-4 minors.
>>> However, ksh gave a different result all along.
>> This isn't standardized, so I'm not worried about small differences between
>> implementations in something that happens interactively.
> True, it's an unimportant detail, though ksh-compliance seems to
> always be desired.

Not really. There's no reason to be deliberately incompatible with other
shells where non-interactive features are concerned, but ksh is not
something to be `compliant' with.

> Anyway, one of my colleagues wrote a small patch that brings
> the behaviour very close to ksh. Could you please comment on it?

The interesting thing about this is that very few shells, other than
bash, seem to inherit the -v option in subshells. This looks like a
place where Posix doesn't reflect historical behavior, since Posix says
that subshell environments inherit all options. I guess it's a question
of when the command in the command substitution is `read'.

[Filip Krska]

Hi Chet,

On 06/30/2014 08:55 PM, Chet Ramey wrote:
> On 6/26/14, 4:56 AM, Ondrej Oprala wrote:
>> On 06/11/2014 07:26 PM, Chet Ramey wrote:
>>> On 6/11/14, 6:35 AM, Ondrej Oprala wrote:
>>>> Hi,
>>>> bash-4.3 seems to act differently(better) in vi visual mode, than previous
>>>> bash-4 minors.
>>>> However, ksh gave a different result all along.
>>> This isn't standardized, so I'm not worried about small differences between
>>> implementations in something that happens interactively.
>> True, it's an unimportant detail, though ksh-compliance seems to
>> always be desired.
> Not really. There's no reason to be deliberately incompatible with other
> shells where non-interactive features are concerned, but ksh is not
> something to be `compliant' with.

Yep, I'd not suggest to take ksh always as an etalon of compliance ;).

However, if we are swimming in "undefined" waters, we can consider
usability and "user expectation". And in this case, especially when
substitution occurs in cycle, echoing substituted commands seems not
only unexpected, but annoying (that's why it was reported to us). See:

If I enter in edit-and-execute-command (C-xC-e) e.g.

for i in $(seq 1 4);do j=$(echo $i$i ); echo $j; done
echo second

it result for bash-4.3 in:

#
for i in $(seq 1 4);do j=$(echo $i$i ); echo $j; done
seq 1 4

echo $i$i
11
echo $i$i
22
echo $i$i
33
echo $i$i
44

echo second
second

However, with the proposed patch the output reads:

#
for i in $(seq 1 4);do j=$(echo $i$i ); echo $j; done
11
22
33
44
echo second
second

Of course, treat the patch rather as proof of concept, there may be side
effect I'm not aware.

>> Anyway, one of my colleagues wrote a small patch that brings
>> the behaviour very close to ksh. Could you please comment on it?
> The interesting thing about this is that very few shells, other than
> bash, seem to inherit the -v option in subshells. This looks like a
> place where Posix doesn't reflect historical behavior, since Posix says
> that subshell environments inherit all options. I guess it's a question
> of when the command in the command substitution is `read'.
>
> Chet
>

Thanks and Regards,

Filip

--
Filip Krška

GSS-SEG EMEA engineer, #sbr-shells (pri), #sbr-anaconda (sec)
Red Hat Czech s.r.o.
Purkyňova 99/71
612 45, Brno, Czech Republic
email:fkr...@redhat.com
office phone:+420 5322 94499

♡ All Wrongs Reversed
http://copyheart.org

[Chet Ramey]

On 7/2/14, 2:22 AM, Filip Krska wrote:

> Of course, treat the patch rather as proof of concept, there may be side
> effect I'm not aware.

There's a more direct one-line patch I'm looking at.