It just occurred to me that 'cd -' with its _special behavior_ seems
not well suited for scripting. While 'cd anydir' is just doing its
job and switches to the directory 'cd -' will create spurious output;
the target directory. While that may be desirable in interactive use
I don't see a point to create that spurious output in scripting.
Neither 'cd "$OLDPWD"' nor 'cd ~-' will do that (because they imply
an expansion).

Bash and Ksh always produce that unnecessary output with 'cd -' while
Zsh does that, more sensibly, it seems, only in _interactive mode_.

Is there any sensible application for that inconsistency in scripts?
I mean, say, something like here_I_am=$( cd - )
(which I'd rather explicitly ask for if I want to know the 'pwd').

I am using 'cd -' for decades but now its output got in the way of
other output I create - strange that it didn't occur to me before.

Janis

On 2022-10-29, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> It just occurred to me that 'cd -' with its _special behavior_ seems
> not well suited for scripting. While 'cd anydir' is just doing its
> job and switches to the directory 'cd -' will create spurious output;
> the target directory. While that may be desirable in interactive use
> I don't see a point to create that spurious output in scripting.
> Neither 'cd "$OLDPWD"' nor 'cd ~-' will do that (because they imply
> an expansion).

Hey look, this is required by POSIX!

When a <hyphen-minus> is used as the operand, this shall be
equivalent to the command:

cd "$OLDPWD" && pwd

which changes to the previous working directory and then writes its
name.

POSIX doesn't say that it may behave differently in a noninteractive
script, so shells which change the behavior are nonconforming.

Basically it seems to be a shortcut for interactive use;
take me back to where I was before and remind me where that is.

It probably suited someone's personal workflows and tastes, and
that person got it into the cd command.

If you don't have the current working directory embedded into
your prompt, and execute "cd -" several times, you might know
know where you are. You can use pwd; but then that's just what is
built-in to the cd - semantics.

Maybe this comes from a time when it wasn't fashionable to adjust the
prompt to include the current directory.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 29.10.2022 03:38, Kaz Kylheku wrote:
> On 2022-10-29, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> It just occurred to me that 'cd -' with its _special behavior_ seems
>> not well suited for scripting. While 'cd anydir' is just doing its
>> job and switches to the directory 'cd -' will create spurious output;
>> the target directory. While that may be desirable in interactive use
>> I don't see a point to create that spurious output in scripting.
>> Neither 'cd "$OLDPWD"' nor 'cd ~-' will do that (because they imply
>> an expansion).
>
> Hey look, this is required by POSIX!

Oh, I haven't looked at POSIX; I was somehow assuming that it's a
non-standardized ksh/bash/zsh extension of 'cd' (but confused that
maybe with the 'cd oldstring newstring' extension?). Looking that
up in the portability section of Bolsky/Korn I see both listed in
the "Ksh features not in POSIX" section. So 'cd -' seems to be a
more recent addition to POSIX. We probably have to blame the ksh
paragon for the way this functionality got standardized in POSIX.

>
> When a <hyphen-minus> is used as the operand, this shall be
> equivalent to the command:
>
> cd "$OLDPWD" && pwd
>
> which changes to the previous working directory and then writes its
> name.
>
> POSIX doesn't say that it may behave differently in a noninteractive
> script, so shells which change the behavior are nonconforming.
>
> Basically it seems to be a shortcut for interactive use;
> take me back to where I was before and remind me where that is.

Indeed. - Too bad that they didn't differentiate [in ksh] at that
time between interactive mode and scripting in case of 'cd'.

>
> It probably suited someone's personal workflows and tastes, and
> that person got it into the cd command.
>
> If you don't have the current working directory embedded into
> your prompt, and execute "cd -" several times, you might know
> know where you are. You can use pwd; but then that's just what is
> built-in to the cd - semantics.

Personally I can't remember what files are actually in a directory,
so every 'cd' should probably imply a 'ls'. :-)

>
> Maybe this comes from a time when it wasn't fashionable to adjust the
> prompt to include the current directory.

Even then I wouldn't need it, but as you say, personal workflows
and preferences vary.

I seem to recall that adjusting the prompt was common even in the
late 1980's (my csh times), but memories are faint.

Janis

In comp.unix.shell, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 29.10.2022 03:38, Kaz Kylheku wrote:
>> Hey look, this is required by POSIX!

Really making me want to 'mkdir ./-' and see how things react.

> Personally I can't remember what files are actually in a directory,
> so every 'cd' should probably imply a 'ls'. :-)

I have some directories where that's painful. Even if using the don't
sort flag.

>> Maybe this comes from a time when it wasn't fashionable to adjust the
>> prompt to include the current directory.
> I seem to recall that adjusting the prompt was common even in the
> late 1980's (my csh times), but memories are faint.

It's behavior I abhor. Prompt changing for 'su', sure; changing with
exit code of last process, okay; putting history line number in, maybe;,
but directories? Ugh, it changes the length of the prompt too much.

But yeah, some people have apparently liked that for a long time.

Elijah
------
PS1=": $USER@$HOST ; "; PS2='^I'

On 29.10.2022 23:27, Eli the Bearded wrote:
>> On 29.10.2022 03:38, Kaz Kylheku wrote:
>>> [ adjust the prompt to include the current directory ]
>
> It's behavior I abhor. Prompt changing for 'su', sure; changing with
> exit code of last process, okay; putting history line number in, maybe;,
> but directories? Ugh, it changes the length of the prompt too much.

That's why you occasionally see folks using such prompts with
embedded line breaks, I suppose, having the path on a separate
line, so that you have a complete line available for input.

Myself I haven't changed my prompt definition for decades. It's
still something like user@host:path where the path prefix is
substituted by a '~' for files beneath $HOME. The user@host part
I'd consider less useful in the private context where I solely
work on a single Unix system now. So if I decide to change the
prompt definition I probably start removing that user@host first.

The length of the prompt isn't an issue for me, though. Whenever
a command gets typed that is getting lengthy (or use an inherently
long compound command) I just "Esc v" and get a vi instance where
I can continue typing any command with arbitrary complexity.[*]
(This is in Kornshell with vi editing mode activated.)

What I recently added is a shell-level counter to see whether I
started another (embedded) instance, e.g. from a shell escape of
programs that support that.

Janis

[*] Something I consider an issue here is that if I abort editing
with :q! the typed command will still get executed, so it needs
to be deleted before quitting or prefixed by '#'. My expectation
here would be that :w should execute the entered text and :q! not.

In article <tjk805$3ndt9$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
....
>[*] Something I consider an issue here is that if I abort editing
>with :q! the typed command will still get executed, so it needs
>to be deleted before quitting or prefixed by '#'. My expectation
>here would be that :w should execute the entered text and :q! not.

Yeah, I find this a little annoying too. But, of course, it makes perfect
sense when you think about it. :q!'ing out just reverts the file to what
it was on entry (or at last save, if any).

I've gotten in the habit of doing dd (assuming just a single line in the
buffer) before exiting (if I don't want anything to be executed).

--
The whole aim of practical politics is to keep the populace alarmed (and hence clamorous
to be led to safety) by menacing it with an endless series of hobgoblins, all of them imaginary.

H. L. Mencken

On 30.10.2022 00:11, Kenny McCormack wrote:
> In article <tjk805$3ndt9$1@dont-email.me>,
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> ...
>> [*] Something I consider an issue here is that if I abort editing
>> with :q! the typed command will still get executed, so it needs
>> to be deleted before quitting or prefixed by '#'. My expectation
>> here would be that :w should execute the entered text and :q! not.
>
> Yeah, I find this a little annoying too. But, of course, it makes perfect
> sense when you think about it. :q!'ing out just reverts the file to what
> it was on entry (or at last save, if any).

Yes, technically you are correct. What I had in mind was that the shell
may have more options to implement something more sensible (read it as:
something that I think would be more sensible). It seems that the vi(m)
instance will not create exit codes !=0 to differentiate that, though.
So shell might resort to date of "creation" (i.e. first modification)
and modification date after the edit to determine tmp-file changes.

I am aware (OTOH) that some folks may have the expectation to execute
at least the initial text sequence if any other command modification
gets :quited, but to me that appears extremely risky. (Thinking of a
start with rm -rf * then realizing to add a cd command before the rm
and then quitting the editing.)

Besides editing the newly typed command we can use "Esc v" also to
edit (simple or compound) commands from the history. In case of a
complex command (from history or newly typed) deletion is a bit more
cumbersome.

Besides command line editing (vi/emacs) in shell there's also the stty
setting 'kill' to allow erasing the input typed on the line; but that
doesn't work in vi mode. There should be *some way* to _abort_ sending
the text as command to the shell. (Explicitly deleting everything seems
counter-intuitive to me.)

>
> I've gotten in the habit of doing dd (assuming just a single line in the
> buffer) before exiting (if I don't want anything to be executed).

Yes, either that, or, (if the typed command will have no bad effects)
just accept the error message.

Janis

In article <tjm0oh$6g1a$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
....
>> I've gotten in the habit of doing dd (assuming just a single line in the
>> buffer) before exiting (if I don't want anything to be executed).
>
>Yes, either that, or, (if the typed command will have no bad effects)
>just accept the error message.

Maybe it should be possible to configure the shell to always ask for
confirmation (i.e., an "Are you sure?" prompt) before going ahead after you
exit the editor.

Incidentally, I agree that the best solution would be if vi (which is
usually vim these days) could return some non-zero exit code in this
situation. I'll bet that could be done with some fancy vim scripting;
whether it would be worth the trouble or not is another matter.

It would be interesting to know if the shell would recognize the non-zero
exit code and do the right thing. I'll have to test that at some point (in
bash).

--
I'm building a wall.

On 30.10.2022 15:29, Kenny McCormack wrote:
>
> Incidentally, I agree that the best solution would be if vi (which is
> usually vim these days) could return some non-zero exit code in this
> situation. I'll bet that could be done with some fancy vim scripting;
> whether it would be worth the trouble or not is another matter.

The problem I see is that we'd be creating sort of an own ecosystem
with modified tools and tools relying on such modification.

>
> It would be interesting to know if the shell would recognize the non-zero
> exit code and do the right thing. I'll have to test that at some point (in
> bash).

I wouldn't expect that shell would react on non-zero status here,
but please keep us informed, in any case it's interesting to know.

Janis

On 2022-10-29, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

> [*] Something I consider an issue here is that if I abort editing
> with :q! the typed command will still get executed, so it needs
> to be deleted before quitting or prefixed by '#'. My expectation
> here would be that :w should execute the entered text and :q! not.

You get used to that from version control. Whether you're using
old cvs or git, when you find yourself making a commit you don't
want, you blank out the commit log message and save it, and
then quit.

git will not commit if the editor terminates abnormally.

You get a mesage like

error: There was a problem with the editor 'vim'.
Please supply the message using either -m or -F option

Bash has two features for editing a command in an external editor:

- fc (fix command) to edit the previous command (or a range
of commands).

- Ctrl-x e to switch the current command line edit to an
external editor.

Under both of these, the command will be dispatched if you
save and exit.

Like git, they are robust to bad termination. If you suspend
the editor and terminate it with "kill -KILL", Bash will
not execute the command.

If Vim had a way to exit unsuccessfully, as Kenny wishes,
at least git and Bash will do the right thing.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 30.10.2022 15:29, Kenny McCormack wrote:
>
> Incidentally, I agree that the best solution would be if vi (which is
> usually vim these days) could return some non-zero exit code in this
> situation. I'll bet that could be done with some fancy vim scripting;
> whether it would be worth the trouble or not is another matter.
>
> It would be interesting to know if the shell would recognize the non-zero
> exit code and do the right thing. I'll have to test that at some point (in
> bash).

The "Esc v" in Kornshell's vi editing mode is referring to 'fc -e vi'
and the 'fc' man page says:

"[...] If the editor returns a non-zero exit status, this will suppress
the entry into the history list and the command reexecution. [...]"

Janis

On 31.10.2022 08:28, Kaz Kylheku wrote:
> On 2022-10-29, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>
>> [*] Something I consider an issue here is that if I abort editing
>> with :q! the typed command will still get executed, so it needs
>> to be deleted before quitting or prefixed by '#'. My expectation
>> here would be that :w should execute the entered text and :q! not.
>
> If Vim had a way to exit unsuccessfully, as Kenny wishes,
> at least git and Bash will do the right thing.

....or, if an unsuccessful exit is not supported by vim, use a
wrapper - ideally only for shell history edits, so that you can
keep the wrapper simple - like this fragment to create an error
status depending on an actual file change

before=$( stat -c%Y "$1" ) # or %y for higher accuracy?
vim "$1"
after=$( stat -c%Y "$1" )
[[ "$before" != "$after" ]]

and setting 'VISUAL' to such a wrapper.

Do other commands evaluate the 'VISUAL' shell variable?

Janis

On 31.10.2022 11:45, Janis Papanagnou wrote:
> On 31.10.2022 08:28, Kaz Kylheku wrote:
>> On 2022-10-29, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>
>>> [*] Something I consider an issue here is that if I abort editing
>>> with :q! the typed command will still get executed, so it needs
>>> to be deleted before quitting or prefixed by '#'. My expectation
>>> here would be that :w should execute the entered text and :q! not.
>>
>> If Vim had a way to exit unsuccessfully, as Kenny wishes,
>> at least git and Bash will do the right thing.
>
> ...or, if an unsuccessful exit is not supported by vim, use a
> wrapper - ideally only for shell history edits, so that you can
> keep the wrapper simple - like this fragment to create an error
> status depending on an actual file change
>
> before=$( stat -c%Y "$1" ) # or %y for higher accuracy?
> vim "$1"
> after=$( stat -c%Y "$1" )
> [[ "$before" != "$after" ]]
>
> and setting 'VISUAL' to such a wrapper.

It just occurred to me that there's also the 'HISTEDIT' (and the
obsolete 'FCEDIT') variable to define the editor. Using one of
these would reduce the risk to be used by other commands.

>
> Do other commands evaluate the 'VISUAL' shell variable?
>
> Janis
>

On 31.10.2022 11:51, Janis Papanagnou wrote:
> On 31.10.2022 11:45, Janis Papanagnou wrote:
>> On 31.10.2022 08:28, Kaz Kylheku wrote:
>>> On 2022-10-29, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>>
>>>> [*] Something I consider an issue here is that if I abort editing
>>>> with :q! the typed command will still get executed, so it needs
>>>> to be deleted before quitting or prefixed by '#'. My expectation
>>>> here would be that :w should execute the entered text and :q! not.
>>>
>>> If Vim had a way to exit unsuccessfully, as Kenny wishes,
>>> at least git and Bash will do the right thing.
>>
>> ...or, if an unsuccessful exit is not supported by vim, use a
>> wrapper - ideally only for shell history edits, so that you can
>> keep the wrapper simple - like this fragment to create an error
>> status depending on an actual file change
>>
>> before=$( stat -c%Y "$1" ) # or %y for higher accuracy?
>> vim "$1"
>> after=$( stat -c%Y "$1" )
>> [[ "$before" != "$after" ]]
>>
>> and setting 'VISUAL' to such a wrapper.
>
> It just occurred to me that there's also the 'HISTEDIT' (and the
> obsolete 'FCEDIT') variable to define the editor. Using one of
> these would reduce the risk to be used by other commands.

Just tested that. The wrapper works with 'VISUAL' but not with the
other two variables.

>
>>
>> Do other commands evaluate the 'VISUAL' shell variable?
>>
>> Janis
>>
>

Kaz Kylheku <864-117-4973@kylheku.com> writes:
> If Vim had a way to exit unsuccessfully, [...]
> at least git and Bash will do the right thing.

It does.

":cq" or ":cquit" exit with a status of 1. It takes an optional
argument to specify a non-zero status (including 0).

":help cq" to see the documentation.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
[Watch this space]
void Void(void) { Void(); } /* The recursive call of the void */

In article <87v8o0m499.fsf@nosuchdomain.example.com>,
>> If Vim had a way to exit unsuccessfully, [...]
>> at least git and Bash will do the right thing.
>
>It does.
>
>":cq" or ":cquit" exit with a status of 1. It takes an optional
>argument to specify a non-zero status (including 0).
>
>":help cq" to see the documentation.

That's very useful. Thank you.
I can think of many occasions where this would be useful.

Of course, it has to be used with caution, but when it's right, it's right.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/CLCtopics

On 2022-10-31, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>> If Vim had a way to exit unsuccessfully, [...]
>> at least git and Bash will do the right thing.
>
> It does.
>
> ":cq" or ":cquit" exit with a status of 1.

Wow, that is buried in the functionality.

I've never heard of the use case hinted at by the documentation, with
regard to the compilation scenario: that if you quit with a failed
status, the compiler won't try to compile that file again.

The idea must be that vim is in some kind of external loop
invoked during a build to fix files with errors. To break out of that
loop, you use :cq. Somethingg like:

# while compilation fails, but editing doesn't, repeat:

while ! $(CC) $< -o $@ && vim $@ ; do : ; done

Except with a bit more complexity to invoke vim on the error
output captured from the compiler as a quickfix list. (which is why
this cq is buried in the quickfix command suite).

This seems worth looking into because it has certain obvious advantages
over iterating on "make -k" and fixing batches of errors:

> It takes an optional
> argument to specify a non-zero status (including 0).
>
> ":help cq" to see the documentation.

The argument must be in newer Vim versions; none is documented for Vim
8.0, and it rejects arguments or prefixes.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

In article <20221031092259.353@kylheku.com>,
....
>> It takes an optional
>> argument to specify a non-zero status (including 0).
>>
>> ":help cq" to see the documentation.
>
>The argument must be in newer Vim versions; none is documented for Vim
>8.0, and it rejects arguments or prefixes.

Yes. My Vim 7.4 is the same. 'cq' is there, but the N option isn't.

However, in Vim 9.0.180, the help says:

:cq[uit][!]
:{N}cq[uit][!]
:cq[uit][!] {N} Quit Vim with error code {N}. {N} defaults to one.
Useful when Vim is called from another program:
e.g., a compiler will not compile the same file again,
`git commit` will abort the committing process, `fc`
(built-in for shells like bash and zsh) will not
execute the command, etc.
{N} can also be zero, in which case Vim exits
normally.
WARNING: All changes in files are lost! Also when the
[!] is not used. It works like ":qall!" |:qall|,
except that Vim returns a non-zero exit code.

What is funny is that the ! seems to be a no-op; it does exactly the same
thing with or without the !. Why mention it at all?

--
(Cruz certainly has an odd face) ... it looks like someone sewed pieces of a
waterlogged Reagan mask together at gunpoint ...

http://www.rollingstone.com/politics/news/how-america-made-donald-trump-unstoppable-20160224

Kaz Kylheku <864-117-4973@kylheku.com> writes:
> On 2022-10-31, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>> If Vim had a way to exit unsuccessfully, [...]
>>> at least git and Bash will do the right thing.
>>
>> It does.
>>
>> ":cq" or ":cquit" exit with a status of 1.
>
> Wow, that is buried in the functionality.
>
> I've never heard of the use case hinted at by the documentation, with
> regard to the compilation scenario: that if you quit with a failed
> status, the compiler won't try to compile that file again.
>
> The idea must be that vim is in some kind of external loop
> invoked during a build to fix files with errors. To break out of that
> loop, you use :cq. Somethingg like:
>
> # while compilation fails, but editing doesn't, repeat:
>
> while ! $(CC) $< -o $@ && vim $@ ; do : ; done
>
> Except with a bit more complexity to invoke vim on the error
> output captured from the compiler as a quickfix list. (which is why
> this cq is buried in the quickfix command suite).
>
> This seems worth looking into because it has certain obvious advantages
> over iterating on "make -k" and fixing batches of errors:
>
>> It takes an optional
>> argument to specify a non-zero status (including 0).
>>
>> ":help cq" to see the documentation.
>
> The argument must be in newer Vim versions; none is documented for Vim
> 8.0, and it rejects arguments or prefixes.

The numeric argument was added in version 8.2.0095, 2020-01-06.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
[Watch this space]
void Void(void) { Void(); } /* The recursive call of the void */

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

> Whenever a command gets typed that is getting lengthy (or use an
> inherently long compound command) I just "Esc v" and get a vi instance
> where I can continue typing any command with arbitrary complexity.

This is in fact the first time I read of somebody using this. Do you use
vi mode for other command line editing stuff as well? If so, can you
comment on the motivation? While I am an adherent to the other editor
religion, I can reasonably work with vi as well, but for command line
editing a mode-based paradigm seems especially strange. No holy wars, I
am genuinely curious. And even the vi users I know will normally stick
to bash's default emacs editing mode.

Best regards

Axel

In article <87h6zeed5g.fsf_-_@axel-reichert.de>,
Axel Reichert <mail@axel-reichert.de> wrote:
>Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>
>> Whenever a command gets typed that is getting lengthy (or use an
>> inherently long compound command) I just "Esc v" and get a vi instance
>> where I can continue typing any command with arbitrary complexity.
>
>This is in fact the first time I read of somebody using this. Do you use
>vi mode for other command line editing stuff as well? If so, can you
>comment on the motivation? While I am an adherent to the other editor
>religion, I can reasonably work with vi as well, but for command line
>editing a mode-based paradigm seems especially strange. No holy wars, I
>am genuinely curious. And even the vi users I know will normally stick
>to bash's default emacs editing mode.

Not me.

(And, yes, there really is nothing else to say - that won't lead us down
the path to a Holy War...)

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/EternalFlame

Axel Reichert <mail@axel-reichert.de> writes:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>
>> Whenever a command gets typed that is getting lengthy (or use an
>> inherently long compound command) I just "Esc v" and get a vi instance
>> where I can continue typing any command with arbitrary complexity.
>
> This is in fact the first time I read of somebody using this. Do you use
> vi mode for other command line editing stuff as well? If so, can you
> comment on the motivation? While I am an adherent to the other editor
> religion, I can reasonably work with vi as well, but for command line
> editing a mode-based paradigm seems especially strange. No holy wars, I
> am genuinely curious. And even the vi users I know will normally stick
> to bash's default emacs editing mode.

I use C-x C-e, which is bound by default to edit-and-execute-command.
According to the bash documentation, it attempts to invoke $VISUAL,
$EDITOR, and emacs, in that order.

The new vi-edit-and-execute-command (which is not bound by default)
probably does the same thing but falls back to vi rather than emacs
(I haven't verified this). It was added in bash 5.2, but is not
mentioned in the bash documentation.

I use vim as my primary editor ($VISUAL and $EDITOR are both "vim"), but
I use the default emacs-style key bindings in bash.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

On 2022-11-04, Axel Reichert <mail@axel-reichert.de> wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>
>> Whenever a command gets typed that is getting lengthy (or use an
>> inherently long compound command) I just "Esc v" and get a vi instance
>> where I can continue typing any command with arbitrary complexity.
>
> This is in fact the first time I read of somebody using this. Do you use
> vi mode for other command line editing stuff as well?

This is not a vi mode; it's just launching an external editor.

In Bash, Ctrl-X Ctrl-E does this, by default.

There are times when command-line editing is not up to snuff,
particularly when you have a multi-line command.

I implemented Ctrl-X Ctrl-E in the TXR Lisp REPL, which is based on a
substantially modified Linenoise library.

it's a must-have feature.

> If so, can you
> comment on the motivation? While I am an adherent to the other editor
> religion, I can reasonably work with vi as well, but for command line
> editing a mode-based paradigm seems especially strange. No holy wars, I
> am genuinely curious. And even the vi users I know will normally stick
> to bash's default emacs editing mode.

I set up vi editing mode in the shell profile of one particular service
account years ago. It keeps tripping me up every time I log into it, but
not enough for me to change it back. :)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

In comp.unix.shell, Axel Reichert <mail@axel-reichert.de> wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> Whenever a command gets typed that is getting lengthy (or use an
>> inherently long compound command) I just "Esc v" and get a vi instance
>> where I can continue typing any command with arbitrary complexity.
> This is in fact the first time I read of somebody using this.

I do this regularly. But I also regularly run long pipelines
and nested loops interactively.

> Do you use vi mode for other command line editing stuff as well?

100% yes. For one thing I have vi editing very well memorized, and
even ingrained. <esc>h or <esc>k are things I find myself doing in
very inappropriate places like web text boxes.

> If so, can you comment on the motivation? While I am an adherent
> to the other editor religion, I can reasonably work with vi as well,
> but for command line > editing a mode-based paradigm seems
> especially strange.

Once you think in vi, which I fully get that some people neither can nor
want to, it's not strange at all. Strange is not being able to use vi
mode edits on the : line within vi[*]. I use vi mode on my phone (with
"Hacker's Keyboard" and Termux shell.)

> And even the vi users I know will normally stick to bash's default
> emacs editing mode.

Other than arrow keys, I don't know how to use that effectively. I do a
lot of ssh into servers I've never touched before or su into shared
accounts and find myself confronted with the defaults of bash more often
than I'd like. Only one or two cW or rx type things make me reach for
"set -o vi".

[*] Solution ':map * "yyy@y' and then compose commands in the buffer,
hit <esc>* to execute them, then dd or undo the thing and edit it
again. This is how I compose large :g commands or complicated
substitutions.

Elijah
------
mz:'a,'e g/^>/ s/> *>/>>/g |normal 'z

On 04.11.2022 20:24, Axel Reichert wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>
>> Whenever a command gets typed that is getting lengthy (or use an
>> inherently long compound command) I just "Esc v" and get a vi instance
>> where I can continue typing any command with arbitrary complexity.
>
> This is in fact the first time I read of somebody using this. Do you use
> vi mode for other command line editing stuff as well?

I'm not sure whether you are asking whether and why I prefer vim to
emacs or why I use the vi-mode of ksh compared to, say, tcsh's edit
features.

What I do is using vim (or vi) wherever some text has to be edited,
since I consider that tool the most flexible and most effective way.
(Only so much for the moment to keep this reply short.)

So, yes, I use it to edit a command line in a ksh session, and to
edit larger shell commands - the shell is a programming language as
other programming languages are, and I do edit programming languages
with vim.

> If so, can you comment on the motivation?

Of course I can do that. - I already started to write up something,
but hesitated to continue, because I got unsure whether I understood
the intention of your question correctly...

> While I am an adherent to the other editor
> religion, I can reasonably work with vi as well, but for command line
> editing a mode-based paradigm seems especially strange.

....so it's probably better if you elaborate on why and what you think
is "especially strange" so that I can better focus on the information
you're asking for.

> No holy wars, I am genuinely curious. And even the vi users I know
> will normally stick to bash's default emacs editing mode.

(The rest is off-topic and better disputed in comp.editors.)

The good thing is that we can choose whatever we want to use, so there's
also absolutely no need for holy wars. And I certainly don't want to
convince anyone. :-)
For the moment just an anecdote; I experienced (and heard similar
reports from other vi-users) that folks observing some vi-user are often
astonished that a) only few keystrokes can transform the whole file
(and I am *not* speaking about hidden complex macros in the background),
and b) that very complex tasks can be invoked that I haven't seen in any
other editor possible.

(I'll elaborate the vi-topic further on request.)

Janis

>
> Best regards
>
> Axel
>