On the topic of shells, does anyone know how to get ksh's "horizontal line scrolling" feature in bash? That's really the only thing (except maybe for the cleanness of ksh) that I notice and prefer over bash. I keep on using bash because of it's superior auto-completion, though.

(18-06-2020, 03:13 PM)jkl Wrote: I admit that I hadn’t tested it on a real Solaris yet, but wouldn’t pkgsrc work?

Probably would work. But I can't due to some company rules. But I'll try it on OpenIndiana.

(18-06-2020, 04:15 PM)zge Wrote: On the topic of shells, does anyone know how to get ksh's "horizontal line scrolling" feature in bash? That's really the only thing (except maybe for the cleanness of ksh) that I notice and prefer over bash. I keep on using bash because of it's superior auto-completion, though.

Put the following in your ~/.inputrc

I use mksh as interactive shell, and rc/posix shell to write scripts. But for me, any shell with auto-completion serves its purpose as interactive shell, as i usually use it only to run commands.

(21-06-2020, 12:21 PM)phillbush Wrote:

(18-06-2020, 04:15 PM)zge Wrote: On the topic of shells, does anyone know how to get ksh's "horizontal line scrolling" feature in bash? That's really the only thing (except maybe for the cleanness of ksh) that I notice and prefer over bash. I keep on using bash because of it's superior auto-completion, though.

Put the following in your ~/.inputrc

Code:

set horizontal-scroll-mode on

For some reason that didn't work on my system, but


did. Not as nice as ksh, but it works well.

(08-07-2020, 08:16 AM)zge Wrote: For some reason that didn't work on my system, but

set horizontal-scroll-mode On

did. Not as nice as ksh, but it works well.

That's strange, the manual says:

Quote:Unrecognized variable names are ignored. When a variable value is read, empty or null values, "on" (case-insensitive), and "1" are equivalent to On. All other values are equivalent to Off.

Anyways...
One thing (other than <(command)) that makes me like bash more than ksh is that in ksh you can only rebind the keys in the emacs mode, you cannot rebind keys in the vi mode, while in bash you can rebind in both modes. Line editing in bash is much more involved.

That makes me think that shells should not be interactive, instead we should use a wrapper like rlwrap that does the interactive job of line editing and completion, leaving the command parsing and execution job for the shell itself. Thus, you could reuse the shell wrapper in other shells/prompts like debuggers and interpreters, and have a uniform interface for every shell. You could for example, use sh, plan9's rc and a lisp interpreter all with the same line editing keybindings.

Don’t they all use readline anyway?

Currently testing: The rather usable ion shell from Redox OS (seems to be rather resource-hungry in its default configuration though) and the desh which is a fork of the es shell with some additional interactivity, namely: a NIH alternative to libreadline.

Both are mostly undocumented. That’s fun.

(01-10-2020, 05:52 AM)jkl Wrote: Currently testing: The rather usable ion shell from Redox OS (seems to be rather resource-hungry in its default configuration though) and the desh which is a fork of the es shell with some additional interactivity, namely: a NIH alternative to libreadline.

Both are mostly undocumented. That’s fun.

I ran the loop test:


Bash almost twice as fast.

Ah, the dev. Welcome to nixers and thank you for contributing this!

I think that the missing shell in this discussion is Powershell. Powershell is like the SystemD for Windows, except with command line capabilities.

(01-10-2020, 05:48 PM)injinj Wrote: I think that the missing shell in this discussion is Powershell. Powershell is like the SystemD for Windows, except with command line capabilities.

"Aww, look at Windows trying to be a real operating system." - quote from an ex-colleague on Powershell

The Powershell has an awful command line syntax, sadly.

I tried posh on Linux for a couple of days, but none of the plugins worked, they all required Windows. The problem with higher level languages on the command line is that a shell's main duty is to fork processes. Once the shell is forked, the only communication available are inter process through a pipe. All of the environment is no longer shared.

I was thinking about storing the environment in a sqlite db and sharing it across shell forks.

In es:


The closure variable i is incremented after every invocation of hello, but if hello in a subprocess, then i doesn't change:


The subshell fork of the backquote operator causes the variable i to be copied and manipulated in the subshell. The same happens with the env in bash when a subshell is spawned.

If the environment were persistent, that might allow for fancier command line multi processing. Maybe a new subshell operator, for example:

(02-10-2020, 06:54 AM)injinj Wrote: The closure variable i is incremented after every invocation of hello, but if hello in a subprocess, then i doesn't change:

Code:

; echo `{hello ; hello ; hello}                                        
3 4 5
; echo `{hello ; hello ; hello}                                        
3 4 5

I think the second example of subprocess is missing.

(02-10-2020, 06:56 AM)venam Wrote:

(02-10-2020, 06:54 AM)injinj Wrote: The closure variable i is incremented after every invocation of hello, but if hello in a subprocess, then i doesn't change:

Code:

; echo `{hello ; hello ; hello}                                        
3 4 5
; echo `{hello ; hello ; hello}                                        
3 4 5

I think the second example of subprocess is missing.

I could run the same echo command 100 times and it will still print 3 4 5. The reason is that the shell environment is forked, and then hello is run 3 times. I can capture this with ps like this:


The 5205 process is the desh running in the terminal connected to pts/0, the 17xxx process are subshells spawned using the backquote operator, these are running the hello functions.