Change default shell from bash to zsh by default?

Another thing is that some controls, even not specified on the zsh file, are acting their default behavior.

Example is ^I, which is the same as tab. I will add those also because then I don’t overwrite the default behavior they already have with different mappings.

Edit: some can’t be mentioned

zsh-syntax-highlighting: unhandled ZLE widget 'complete'
zsh-syntax-highlighting: (This is sometimes caused by doing `bindkey <keys> complete` without creating the 'complete' widget with `zle -N` or `zle -C`.)
1 Like

Now, before we add bindkey '^ ' forward-word to the zsh config by default

Didn’t find anything conflicting with ^ .

Are there some common / popular / convention zsh shortcuts? Then perhaps we should use the same instead of inventing ones which are only used by Kicksecure / Whonix?

Doing that following the readline man page (Arch or Debian, same thing)

Once that’s done, the most common hotkeys should be documented unless it’s already documented somewhere good enough upstream.

Just link to man page.

One default behavior I know that I changed is ^J to accept-search instead of the default accept-line.

^M is already accept-line, which equals to the Enter key.

Having ^J as accept-search is better for tab completion, you can select the option and type ^J to accept the search and continue typing.

1 Like
1 Like

Forward word and backward word is not Ctrl+arrows, where arrows are right and left arrows.

1 Like

I think this is the right way to go. macOS did this some time ago, but not for this reason.

Maybe with different colors/themes (I kinda like compartmentalization) in Whonix GW vs Whonix WS too, once again to prevent mistakes from happens, because they do, right?

Have a good one! // yodawins

1 Like

Currently the prompt is workstation|gateway user PWD, where workstation or gateway depends on the vm you are on. I see a problem with this is that it makes the prompt too large, but ws|gw would not be a suitable alternative because they only differ by one letter. Maybe setting the terminal background differently for the GW or WS would help, but that would be on XFCE, not on ZSH.

1 Like

Merged, thank you!

1 Like

Thanks, merged!

Another issue:
The ZDOTDIR environment variable is unset when logging in over SSH.

Results in…

Something useful here that we don’t have yet…?

Will review later.

1 Like

2 posts were split to a new topic: more secure shell version called experimental - ash - reduced attack surface

autoload -U zsh-newuser-install
zsh-newuser-install -f

zsh-newuser-install: can’t write to /etc/zsh/dist.
zsh: exit 1

No root permissions, that is why… don’t know yet how to deal with it.

1 Like

Cannot be run as root / with sudo either.


might help. zsh-newuser-install can then be run but I am not sure the created configuration files would be ignored next time a new shell is opened?

Maybe the same question in other words: Does our current ZDOTDIR based approach support user customization made in user home’s folder?

Current configuration does not support user configuration to home directory.

1 Like

To solve the SSH issue, maybe a bit late now but maybe back to the drawing board.

The function will be run again next time. To prevent this, execute:
touch ~/.zshrc

How can we avoid such corner cases?

Does file ~/.zshrc allow for a different implementation path?

Could we drop the ZDOTDIR environment variable? But that’s not the main goal. That would just be a bonus.

Perhaps a symlink from ~/.zshrc to some file in /etc/zsh/dist would help here?

ln -s /etc/zsh/dist/.zshrc /home/user/.zshrc

I know I said it’s best to avoid writing into the user home folder before.
(Dev/About Debian Packaging - Kicksecure)
But a symlink only might be a good compromise. It’s easy for the user to remove if the user wishes to customize. (unlink /home/user/.zshrc)

For for package desktop-config-dist it would be easy to update zsh configuration files in folder /etc/zsh/dist. Since no actual scripts are in user home folder, to dpkg interactive conflict resolution dialog will happen since the scripts are nicely contained in /etc/zsh/dist.