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.