[SOLVED] What would break with a very early version of bash?

harryhaller · 12-15-2013, 11:31 PM

I've been trying out sh and ash as my sign in shell and liked very much the speed and lightness.

I was also pleased that nearly all my scripts were compatible - I changed them to #!/bin/sh or ash. I even changed the sh symbolic link in /bin from bash to ash and that worked fine until shutdown, when the system crashed

Not so compatible startup and shutdown scripts

But the fact is that in interactive mode both ash and sh are uncomfortable.

Basically, I would like to have ash but with command line editing, a useful prompt and it to recognise "cd bin" to mean the relative directory bin in the current directory and not "/bin".

In anycase - I was wondering, what would break if I went back to a very early form of bash?

Richard Cranium · 12-15-2013, 11:34 PM

Maybe you should try dash instead.

harryhaller · 12-15-2013, 11:40 PM

I did try Dash but soon stopped as it seems to have the same restrictions as ash.
It is only little things which are annoying - such as not being able to set up the prompt to remind me in which directory I am in. Dash is the same as ash with regard to that.

That's why am I thinking about an early version of bash - it should be small and fast but would have, I hope, those few, little enhancements which I want.

Richard Cranium · 12-16-2013, 12:05 AM

Quote:

Originally Posted by harryhaller

It is only little things which are annoying - such as not being able to set up the prompt to remind me in which directory I am in.

Code:

export PS1=$CWD$

harryhaller · 12-16-2013, 12:12 AM

That becomes a constant - it doesn't change when you change directories.

gnashley · 12-16-2013, 12:29 AM

bash-2.05b would come closest to working, but I think there are still rc scripts which will bomb with that -rc.inet1 uses arrays which are not supported by bash2. There may be other rc scripts which are using newer bash features.

harryhaller · 12-16-2013, 12:53 AM

Yes, rc.inet1 and rc.S seem to be the only ones there using arrays.
That looks good, because with my setup I think I could use older versions of those scripts (maybe modify them). I only have eth0 so I it looks good.

harryhaller · 12-16-2013, 01:05 AM

Gnashley - would I get any problems with src2pkg? I use that quite often.

Otherwise, if inet1 and S are the only foreseeable problems, it's worth a try - I can download bash from slackware release 9.1 and recompile it. Thanks for the help.

Richard Cranium · 12-16-2013, 01:07 AM

Quote:

Originally Posted by harryhaller

That becomes a constant - it doesn't change when you change directories.

Yeah, you're right. (I made the same stupid mistake when I was *bleeping* around with ksh almost 20 years ago(!).) The only solutions that I've seen would have you run a program to do the substitutions when the prompt string is printed out.

The other comments pretty much pointed out that what you want in an interactive shell may not be what you want in a scripting shell. (IOW, use bash/ksh for the stuff that *you* type in but use ash/dash for a script.)

gnashley · 12-16-2013, 02:37 AM

@harryhaller, yes, unfortunately src2pkg uses bash3-isms in at least one place. It's possible that others have crept in over time. I'd be willing to fix that though. I did consider revising it to run using dash at least, but decided not to as I use bashisms throughout. The bash3-ism I know of is the use of indirect variable substitution like: '${!var}'. 'twould be easy enough to fix with a harmless eval -that would be the first use of eval in src2pkg, I think.

I've struggled with the question of using dash or ash as /bin/sh, but there are just too many scripts out there using bashisms but with the /bin/sh shebang. Still, I wanted to use dash as the shell for init scripts to have a faster boot. So, what I did was invent a shell called /bin/initsh (linked to static dash) and have all init scripts using that. This allows me to keep /bin/sh pointing to bash and still have a faster shell for other things. If your scripts work with ash or dash, then I'd change their shebangs to /bin/ash and have /bin/ash as a link to /bin/dash. This would still allow you to keep /bin/sh as bash.

tronayne · 12-16-2013, 09:10 AM

You may have noticed that sh is actually BASH emulating sh?

Code:

ls -al /bin/sh
lrwxrwxrwx 1 root root 4 Nov 24 13:31 /bin/sh -> bash*

KornShell on Slackware is actual KornShell, not an emulator. I've been exclusively using KornShell for (literally) decades with no inclination whatsoever to switch to anything else; BASH is a pain in the ASH.

Command line editing? Hit the up arrow key or Esc-K and edit away with vi/ex editing sequences. Easy alias?

Code:

cat .kshrc
alias lc='/usr/bin/clear; /bin/ls ${LS_OPTIONS} -aCF'
alias ll='/bin/ls ${LS_OPTIONS} -al'
alias cls='clear'
alias hi='history -${LINES}'
alias rs='eval `resize`'

Set up a KornShell environment?

Code:

cat .profile
#	set up default columns and lines
COLUMNS=80
LINES=40
export COLUMNS LINES
#	set up a good-size history
HISTSIZE=1000
export HISTSIZE
#	set up the ksh environment
ENV=${HOME}/.kshrc
export ENV
#	change the PATH a little
export PATH=.:${HOME}/bin:${PATH}
#	make COLUMNS and LINES the screen size
eval `resize`

Make it all work on log-in?

Code:

cat /etc/profile.d/ksh.sh
#!/bin/sh
#ident	"$Id$"
#
#	Name:		$Source$
#	Version:	$Revision$
#	Modified:	$Date$
#	Purpose:	set local environment variables for Korn Shell
#	Author:		T. N. Ronayne
#	Date:		1 Oct 2009
#	$Log$
# Set the HOST environment variable
export HOST="`uname -n`"
# Set ksh93 visual editing mode:
if [ "$SHELL" = "/bin/ksh" ]; then
#  VISUAL=emacs		# ugh
#  VISUAL=gmacs		# double ugh
   VISUAL=vi		# ah, elegence
fi
# Set a default shell prompt:
#PS1='`hostname`:`pwd`# '
# Do these anyway in case sombody uses a different shell
if [ "$SHELL" = "/bin/pdksh" ]; then
 PS1='! $ '
elif [ "$SHELL" = "/bin/ksh" ]; then
 PS1='${HOST}-${USER}-${PWD}: '
elif [ "$SHELL" = "/bin/zsh" ]; then
 PS1='%n@%m:%~%# '
elif [ "$SHELL" = "/bin/ash" ]; then
 PS1='$ '
else
 PS1='\u@\h:\w\$ '
fi
PS2='> '
export PS1 PS2

What could be simpler, one might ask.

Hope this helps some.

Richard Cranium · 12-16-2013, 09:27 AM

Since the OP is looking for something that is more lightweight than the current version of bash, I don't think that ksh will cut the mustard:

Code:

$ ls -lart /bin/ksh
-rwxr-xr-x 1 root root 1498632 Jun  9  2013 /bin/ksh*
$ ls -lart /bin/bash
-rwxr-xr-x 1 root root  973672 Aug 15 14:17 /bin/bash*
$ ldd /bin/ksh 
	linux-vdso.so.1 (0x00007fff68dff000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f8319604000)
	libutil.so.1 => /lib64/libutil.so.1 (0x00007f8319400000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f83190fe000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f8318d35000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f8319842000)
$ ldd /bin/bash
	linux-vdso.so.1 (0x00007fff3f780000)
	libtermcap.so.2 => /lib64/libtermcap.so.2 (0x00007fe9703b9000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fe9701b4000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fe96fdeb000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fe9705f6000)

Maybe ksh initialization code is faster than bash's, but I wouldn't expect any speedups from switching to ksh. YMMV.

ponce · 12-16-2013, 09:29 AM

if it can be useful, this is not bad for automated checking

http://sourceforge.net/projects/checkbaskisms/

lems · 12-16-2013, 10:18 AM

mksh installed from pkgsrc:

Code:

-rwxr-xr-x 1 root root 264496 Oct  4 13:52 /usr/pkg/bin/mksh*

There is also a SlackBuild.

gnashley · 12-16-2013, 10:24 AM

Of course I know that /bin/sh is a link to /bin/bash. You know that bash's 'emulation' of 'sh' still includes some bash extensions which are not POSIX. Exactly why there are lots of scripts out that where the author probably thinks they were compatible with (real) 'sh', when in fact they are not.