LWN: Comments on "Bash 3.0 released"

Bash 3.0 released

Wills — Thu, 12 Aug 2004 17:49:18 +0000

> Another new feature of interest is the addition of history
> timestamps. This allows users to see when commands were run,
> which can provide some useful and interesting information.

Without implying any sort of criticism of bash, I would like to note that history timestamps have been in (t)csh for c.15 years and arrays, which bash didn't have until bash 2.0 in 1997, for c.10 years.

Bash programming enhancements - worthwhile!

mwilck — Tue, 10 Aug 2004 14:44:33 +0000

The shell is superior to all of these if a program

doesn't handle complex data structures
carries out many file system activities like searching and moving files or manipulating text files
makes much use of command line programs e.g. from the Unix tool box

Maybe some time in the future all text files will be XML and the file system will be replaced by a CORBA interface to some data base. I hope that happens after I retire.

P.S. did you really mean Java ? Ever seen a shell that needs a 30MB VM to be loaded before it can print "hello world!" ?

Martin, not looking forward to object-oriented bash programming but still seeing room for enhancements.

Bash programming enhancements - worthwhile?

nix — Sat, 07 Aug 2004 14:50:04 +0000

Some of us like bash as a programming language too.

(comments below apply to python as well, I think).

You can't use perl in many environments, either because it isn't available, or because you're not allowed to replace an ancient and buggy module; perl has a hugely higher startup overhead than bash does; you can't sanely use perl scripts at system startup time; one-liners at the shell prompt tend to grow into scripts, and (at least for me) those one-liners are, well, bash scripting...

Yes, there is a reason to improve bash as a programming language. :)

Bash programming enhancements - worthwhile?

giraffedata — Fri, 06 Aug 2004 01:25:57 +0000

If people have time to enhance Bash as a programming language, I'd sure rather they spend that time enhancing one of the languages that are already way ahead of Bash (Perl, Python, Java, whatever). Couldn't we let Bourne Shell (as a programming language) take its place in history?

On the other hand, I'll never get tired of new inventions in Bash as a command shell.

Associative Arrays Still in the Future? Yuck!

AnswerGuy — Fri, 06 Aug 2004 00:04:44 +0000

Korn shell has had support for associative arrays (which python calls "dictionaries," and perl "hashes") for eons (well over a decade I think).

I'll also be interested in whether bash 3.x fixes one shortcoming of bash that's been around forever. Consider the following:

unset foo; echo bar | read foo; echo $foo

What should the output be?

In zsh and ksh you'll see that foo is set; they spawn the subshells to the left of the pipe. In bash you'll find it unset because the read occurs in a subshell which exits at the semicolon. (Thus necessitating braces or parents to group the part after the pipe; or force them all into yet another, explicit subshell).

To most shell scripters this is obscure; nobody cares. However, for serious shell scripting this sort of thing is important (not so much for reading values from subprocesses into single variables, but for reading multiple variables parsed on $IFS, for example).

(Yes, I know, most UNIX/Linux admins and programmers would counter that serious scripting isn't done in shell --- that "real programmers" (and scripters) use Perl. To which I can only respond: "Foo!"

JimD

Some distribs (Gentoo) have it out already, at least in unstable.

Duncan — Thu, 05 Aug 2004 17:49:47 +0000

> Interested users who don't want to wait for Bash
> to ship with their favorite distribution [...]

Of course, other interested users already HAVE it shipping in their
favorite distribution, and have been using it for several days, if they
are running unstable, anyway.

Gentoo, anyone? A FreeBSD user on my ISP reported it was out for them as
well, altho that's obviously not a /Linux/ "distribution".

One bug confirmed both on Gentoo and FBSD, so it's apparently upstream, so
far: Where history scrollback (using the arrow keys, for instance) used
to let you go back in your command list, and then return to the normally
blank initial command, with 3.0, if one scrolls back at least two
commands, one can only scroll back forward to the last /history/ command,
the one BEFORE the previously blank command. To get back to the blank
command, one must use ^C. (If one scrolls only one command up, one can
still scroll that single command back down. It only breaks if one scrolls
at least two commands up.)

Or maybe that's a POSIX compliance thing? Do they standardize even
history scrolling to /that/ extent?

Duncan

FYI: incompatibility in 'trap'

vmole — Thu, 05 Aug 2004 15:22:59 +0000

It turns out that one of the POSIX fixes breaks a long standing use of the 'trap' builtin. Previously, one could specify e.g.

    trap 0

to reset the signal handler to the default for signal 0. POSIX requires the form

    trap - 0

Turning POSIX mode off, or running the script with "#!/bin/bash" instead of "#!/bin/sh" solves this, but doesn't really help scripts that are meant to be portable.

(No, I didn't figure this out myself. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=261948 for details.)

regexps vs regexps

rfunk — Thu, 05 Aug 2004 14:26:06 +0000

Regular expressions are first of all a theoretical concept

Yes, I tried to account for that without getting into the theoretical details that I don't remember.

If we start nit picking, we should not mistake one of those syntaxes as the one and only real regular expression syntax.

Except that globs do not have the power required by a true (theoretical) regular expression. They can't express everything that a regular expression can.

globs vs regexps

Lasse99 — Thu, 05 Aug 2004 11:35:55 +0000

Ooops! That should have been '^[^./][^/]*$'

globs vs regexps

Lasse99 — Thu, 05 Aug 2004 11:34:05 +0000

Actually, the single-star glob '*' is equivalent to the rather complicated
regular expression '^[^.].*$' or even '^[^./][^/]$'.
On the other hand, the simple regular expression '.*' must be expressed by
a set of two filename globs, namely ( '.*' '*' ).
So, it is debatable which syntax is more complicated...

regexps vs regexps

pkolloch — Thu, 05 Aug 2004 08:22:28 +0000

Regular expressions are first of all a theoretical concept. In that sense, regular expressions specify a (often infinite) language of accepted words. Fileglobs are usually not quite as powerful, but have a simplified syntax. There are some very frequently used regular expressions syntaxes as nicely described in the referenced WikiPedia page.

If we start nit picking, we should not mistake one of those syntaxes as the one and only real regular expression syntax.

RE: globs vs regexps

stuart_hc — Thu, 05 Aug 2004 06:42:34 +0000

Yes, this is an important point to stress. Filename pattern matching was historically related to regular expressions but the two have always been distinct. Filename patterns are described under the Pattern Matching section of the Bash man page, or better still in the POSIX standard on Pattern Matching Notation. The Wikipedia page on Regular Expressions gives both a gentle introduction and a formal description.

globs vs regexps

rfunk — Thu, 05 Aug 2004 05:31:34 +0000

The "failglob" option will probably be of interest to many users. When set, this option will cause an error when a regular expression fails to match any files

Filename globs are not regular expressions.

Filename globs are those expressions where ? matches a single character, * matches any number of characters, and the beginning and end are always anchored (e.g. a*d matches abcd but not qabcdz).

Regular expressions have a precise meaning I don't remember at the moment, but commonly refer to expressions where a period matches a single character, a * modifies a previous bit of the expression to match any number of that bit, and beginning and end achors must be explicitly specified if they are desired. (a.*d matches both abcd and qabcdz.)

The single-star glob "*" is equivalent to the four-character regular expression "^.*$".

Confusion between these two systems trips up a lot of people, so it's important not to refer to one when you mean the other.