Tab Complete with Bash Functions

About two years ago I had trouble figuring out how to program bash shell script functions to use tab-completion options. Here is what I learned, hopefully it will help someone out there, someday.

How to programming TAB completion into bash functions, programs and other such things.

Minimum Requirements
Here are the minimum requirements for BASH tab completion.
Code:

# 'local' can only be used within a function, exclude it if not using a function
COMPREPLY=()
local cur="${COMP_WORDS[COMP_CWORD]}"
local opts="--whatever --tabbing --options --you --want"
COMPREPLY=($(compgen -W "${opts}" -- ${cur}))

Lastly, you need one more line after this somewhere in the file, usually after your function:

complete -F "function_name" -o "default" "function_name"
# Replace function_name with your function

Example
A simple example with the current code:

Code:

function sd
{
# 'local' can only be used within a function, exclude it if not using a function
COMPREPLY=()
local cur="${COMP_WORDS[COMP_CWORD]}"
local opts="--whatever --tab --options --you --want to have!"
COMPREPLY=($(compgen -W "${opts}" -- ${cur}))
if [[ ! $* =~ \n ]]; then # Check command been submitted, no more tab-completing
  echo "Command submitted"
  ... # more bash code, dealing with submitted command arguments
fi 
}
complete -F "sd" -o "default" "sd"
# complete -F "sd" -o "nospace" "sd" ## Use this if you do not want a space after the completed word

Slighty Advanced
You can manipulation the string input however you want, just make sure you clear COMPREPLY, and grab the current command prompt info, and append them using compgen.

Firefox 3.5's new JavaScript engine to use revolutionary new JIT method

Here is small post for you programmer guys that you may find interesting.

Sure, you know what JIT is and why it makes so many modern interpreted languages actually usable in terms of speed/performance. But you probably have not heard of the exact methods through which JIT is achieved, and much less of a new method called "trace trees."

Apparently Mozilla's JavaScript engine has a new feature called TraceMonkey which is based on this new JIT compilation method and "The net result is a massive speed increase both in the browser chrome and Web‐page content."[1]

Programmers may find reading about Trace Trees to be interesting. I did.

For more detailed information about how this works with Firefox 3.5, take a look here.

LLVM-GCC vs GCC

So I have been reading up on the LLVM, and on integrating it with GCC. I care about a possible integration of the system because I want Linux programs to continue to be fast. The compiler is an important component in that speed. Furthermore, unlike Microsoft, the GCC project does not have direct communication with Intel Compiler designers, so it is important that GCC compiler be damn good.

From what I read online, it seems like some people like to decry the GCC project as being difficult to contribute to, and perhaps it is... or was. I don't personally believe this after reading experts from The Cathedral and the Bazaar. But I also do not have a lot of experience with the GCC project personally. If nothing else, the history of the GCC since the late 1990s has definitely been one of better community involvement.

Benchmark Data
There is a project called LLVM-GCC which is the combination of GCC and LLVM and I have been trying to collect information on performance between the two compilers. Here follows some of the things I have found.

To note at the beginning, the speed of the compilers is dramatically effected by the CPU architectures they are compiling on. So, an X86_64 architecture compared to Darwin/PPC could give wildly different results for the same code. Many of these tests don't even mention their architectures.

At Cliff Hacks, we see the GCC outperforming LLVM when maximum optimization is enabled (-O3). Unfortunately comparing GCC with -O0 and LLVM standard is fairly invalid, since -O0 effectively ties GCC's hands for speed.

At Laurovenancio, we see LLVM-GCC outperforming GCC by about 2-4%, but this is using GCC 4.1.x. I know from other research that there have been some serious speed improvements in 4.2 and 4.3, and I know that 4.4 is continuing these efforts with Stack management improvements. Because of these updates, I would not take these results as very reliable now.

Leonardo-m's blog is the most recent (2008-12-14) and best illustration of results I have found so far.



These results seem to indicate an overall small speed increase when using LLVM-GCC. The nbody section was a bug which has been reported and fixed already.

If nothing else, the GCC is still an amazing piece of work to be competing so well, even with all of "supposed shortcomings" that I see frequently mentioned in relation to LLVM.

One reason that LLVM has not been adopted into GCC officially is that there are license conflicts between the two projects. I don't really care to list them now, but basically the GCC want to keep things GPL'd and LLVM is more interested in a BSD style license. This is probably because of funding and influence from Apple, their sponsor. I don't fault either party for their intents.

A Final Thought
If LLVM-GCC should become a significantly better/faster/superior/prettier compiler over the GCC, I wonder if there will be a movement to adopt it as the official compiler for Linux distribution packages? I mean, would Debian or Ubuntu start to build their packages with LLVM-GCC if it was a superior compiler? Or would they stick with GCC? Does license matter more than speed? Does "the official Linux compiler" stamp from GCC matter more the perceived performance?

I just hope that if LLVM-GCC should become a "better" compiler that the Linux community, specifically the package maintainers, will consider it as a possibility.