Poll: Interactive shells

Gerard Lally · 06-23-2016, 06:47 PM

Quote:

Originally Posted by notKlaatu

Cool, gezley! thanks. I might try some of those options.

I do think you have a typo in your .tshrc though:

Code:

# set editor
setenv EDITOR vi

"vi" is not how you spell emacs ;^)

haha! I wasn't getting anywhere with evil in emacs so I'm back to square one: learn vim thoroughly this time, and then, and only then, dump vim and use emacs with evil. Evil, I know, but vim really does have superior keys, and emacs has org-mode. Therefore, it has to be vim until I can use the evil emacs!

;-)

nivieru · 06-24-2016, 04:11 AM

zsh, with oh-my-zsh for configuration

NonNonBa · 06-24-2016, 05:06 AM

I personally did bash -> busybox's ash -> bash -> mksh -> dash -> bash -> mksh.

Strictly shell-scripting-wise I could live with dash actually, but the lack of completion is just a pity and the busybox's ash, which has one, is not very handy for packaging (kernel-like interactive configuration). So, mksh, while being "fat" for my usage, remains lighter and faster than bash and, more than all, doesn't mess with long command lines when there are ANSI color sequences in the prompt (a recurrent problem making me mad with bash). Once you learn to remove the leading spaces on the command line (they prevent this one to be added to the history, feature for which I never found any useful case and which I really wish it could be disabled, at least at compile-time), it's a simple and nice shell to use. That's why all my local shell stuff is nowadays "#!/bin/mksh".

bassplayer69 · 06-24-2016, 05:07 AM

I use KSH only because it's what I'm used to from back in my Unixware days in the early 90's.

Gerard Lally · 06-24-2016, 11:17 AM

Quote:

Originally Posted by NonNonBa

I personally did bash -> busybox's ash -> bash -> mksh -> dash -> bash -> mksh.

Strictly shell-scripting-wise I could live with dash actually, but the lack of completion is just a pity and the busybox's ash, which has one, is not very handy for packaging (kernel-like interactive configuration). So, mksh, while being "fat" for my usage, remains lighter and faster than bash and, more than all, doesn't mess with long command lines when there are ANSI color sequences in the prompt (a recurrent problem making me mad with bash). Once you learn to remove the leading spaces on the command line (they prevent this one to be added to the history, feature for which I never found any useful case and which I really wish it could be disabled, at least at compile-time), it's a simple and nice shell to use. That's why all my local shell stuff is nowadays "#!/bin/mksh".

I really like mksh, and Thorsten went far beyond the call of duty some time ago to help me with a query I had. I appreciated that and will continue to use and recommend mksh.

ttk · 06-24-2016, 01:42 PM

Fifteen years ago, tcsh was my primary shell, but these days I only use it on my laptop (mostly because of inertia) and bash on all of my other machines.

The only tcsh features I really miss under bash are the "time" output format and the "repeat" builtin.

I implemented a "rpt" script which does everything tcsh's "repeat" does (and more), so that's taken care of:
http://ciar.org/ttk/codecloset/repeat/

The output of tcsh's "time" can be approximated under bash with appropriate $TIMEFORMAT, but it's a pain setting that up on all of my machines, and I'm not supposed to on the servers at work anyway, so I just don't bother and sigh occasionally in remembrance of tcsh's output. It's not a big deal.

Richard Cranium · 06-24-2016, 09:36 PM

Quote:

Originally Posted by gezley

I wouldn't mind bash so much if I used Linux exclusively. It just doesn't sit right with my BSD temperament to install it on NetBSD. tcsh and mksh feel native on both Slack and NetBSD.

OSX uses it, too.

Not that I'm a big fan of OSX; I just have to use it at work.

Richard Cranium · 06-24-2016, 09:52 PM

A colleague of mine had come up with the idea that if having a directory of executable/readable scripts are good for the OS, then they are good for you too.

The beginning of .bashrc

Code:

# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# setup environment for any login
export TEMP=/tmp/${USER}
export TMP=${TEMP}
mkdir -p ${TEMP}

# setup environment for interactive logins
if [ "$PS1" ] ; then
  # source environment settings
  if [ -d ~/etc/env.d ] ; then
    for f in $(find ~/etc/env.d -type f); do
      . $f
    done
  fi
fi

The beginning of ~/.bash_profile

Code:

# ~/.bash_profile: executed by bash(1) for login shells.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.

# the default umask is set in /etc/login.defs
#umask 022

# include .bashrc if it exists
if [ -f ~/.bashrc ]; then
  . ~/.bashrc
fi

# add the user's bin to the PATH
if [ -d ~/bin ] ; then
  PATH=~/bin:"${PATH}"
fi

# add other path elements
if [ -d ~/etc/path.d ] ; then
  for f in $(find ~/etc/path.d -type f); do
    . $f
  done
fi

This kinda-sorta matches what you can do with /etc/profile.d with the difference that you can split path and environment manipulation and (of course) it's only for your login.

In my case, the contents of ~/etc/env.d are

Code:

0 ✓ cranium@cranium ~/etc $ ls -lart env.d/
total 56
-rw-r--r-- 1 cranium users  125 Jul 22  2009 cc.aliases
-rw-r--r-- 1 cranium users    7 Jul 22  2009 biff
-rw-r--r-- 1 cranium users   37 Jul 22  2009 history
-rw-r--r-- 1 cranium users   10 Jul 22  2009 umask
-rw-r--r-- 1 cranium users   67 Jul 22  2009 guile
-rw-r--r-- 1 cranium users   22 Jul 22  2009 bash
-rw-r--r-- 1 cranium users   42 Jul 23  2009 gnome
-rw-rw-r-- 1 cranium users   77 Mar  1  2011 tj3
-rw-r--r-- 1 cranium users   78 Jul 29  2011 maketool
-rw-rw-r-- 1 cranium users  147 Jul 10  2013 qemu
-rw-rw-r-- 1 cranium users   69 Nov 27  2013 perlcrap
drwxr-xr-x 5 cranium users 4096 Nov 27  2013 ../
-rw-rw-r-- 1 cranium users   36 Apr 25 19:58 jenv
drwxrwxr-x 2 cranium users 4096 Apr 27 18:58 ./

The contents of ~/etc/path.d are

Code:

0 ✓ cranium@cranium ~/etc $ ls -lart path.d/
total 24
-rw-rw-r-- 1 cranium users   36 Sep 17  2009 ant
-rw-rw-r-- 1 cranium users   72 Mar  1  2011 tj3
-rw-rw-r-- 1 cranium users   42 Sep  2  2011 gradle
drwxr-xr-x 5 cranium users 4096 Nov 27  2013 ../
-rw-rw-r-- 1 cranium users   40 Apr 27 18:59 jenv
drwxrwxr-x 2 cranium users 4096 Apr 27 18:59 ./

If it seems like overkill to you, both my colleague and I are software engineers. It wasn't overkill to us.

NoStressHQ · 06-24-2016, 10:15 PM

Quote:

Originally Posted by Richard Cranium

A colleague of mine had come up with the idea that if having a directory of executable/readable scripts are good for the OS, then they are good for you too.
[...]
If it seems like overkill to you, both my colleague and I are software engineers. It wasn't overkill to us.

I don't have the exact same setup (I had something similar at once, but I decided to reduce startup complexity for portability concerns), but I agree about having a home's own set of /bin /etc... It's important to install things locally for the user... I'm a software developer too so this might explains that

.

Edit: one thing about the dir script containers is that you might need to prepend scripts with some number to control execution order (sometimes it matters).

Richard Cranium · 06-24-2016, 10:35 PM

Quote:

Originally Posted by NoStressHQ

I don't have the exact same setup (I had something similar at once, but I decided to reduce startup complexity for portability concerns), but I agree about having a home's own set of /bin /etc... It's important to install things locally for the user... I'm a software developer too so this might explains that

.

Edit: one thing about the dir script containers is that you might need to prepend scripts with some number to control execution order (sometimes it matters).

Yep, valid point. You'd have to sort the listing in that case. (It hasn't bitten my behind yet, so I haven't implemented it. *That* isn't the software engineer side of me. If it were work related, I'd sort the listing.)

navigium · 06-25-2016, 11:11 AM

Quote:

Originally Posted by nivieru

zsh, with oh-my-zsh for configuration

Same here. I'm a lazy person, that's why I really like all the stuff zsh does, even though it sometimes seems to be a bit overkill for a shell. As long as it doesn't use the same amount of memory as KDE, I'm ok with that.

drgibbon · 06-26-2016, 01:40 AM

Quote:

Originally Posted by notKlaatu

I do think you have a typo in your .tshrc though:

Code:

# set editor
setenv EDITOR vi

"vi" is not how you spell emacs ;^)

A common error

chucktr · 08-02-2016, 12:24 PM

Bash because it is what is normally installed on openSuSE by default. I couldn't see any advantages in changing.

enorbet · 08-02-2016, 04:45 PM

Bash + Vi + Krunner == Bliss