LWN.net Logo

Some bash enhancements...

Some bash enhancements...

Posted Dec 8, 2008 13:53 UTC (Mon) by Richard_J_Neill (subscriber, #23093)
Parent article: Go fish! (developerWorks)

It would be nice to see a few changes in bash for version 4. I'd like to see at least the following:
- syntax highlighting at the bash prompt (not just in editors). This idea is one we should take from fish.
- some sensible string functions with aliases defined so that we can use more familiar constructs eg strlen, rather than ${#string}
- trim() or chomp().
- more array functions, eg array_keys(), and multi-dimensional arrays
- a builtin to do path canonicalisation (like /usr/bin/readlink)
- a way to get variables back from subshells (the converse of EXPORT)[1]
- some hybrid of nullglob and failglob so that a mismatched glob results in null. [2]

I still do a *lot* of programming in bash, and it's pretty good. Just not perfect.

[1] Yes, I know this is really an OS feature. But still, why shouldn't a parent be allowed to explicitly access variables set in a subshell? This wouldn't be such a problem, except that subshells can only return a 1-byte integer exit value; rather than an array or a string.

[2] This needs some more explanation - here is an example:
mkdir test
cd test
touch a b c d

ls *z
ls: cannot access *z: No such file or directory
#Normally, bash will fail to expand the *z, and will then pass it to
#ls as a literal '*z'.

shopt -s nullglob
ls *z
a b c d
#Bash now treats '*z' as empty, and runs ls with no parameters.

shopt -s failglob
ls *z
bash: no match: *z
#Here, we get no match, but we get an error instead.

What I want is for "ls *z" to be like listing an empty directory. i.e. bash gives ls an explicit argument of NUL.


(Log in to post comments)

Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds