Some programs that are run in the terminal, after calling them, switch the command line to their own environment, like "R" (statistical program language) or "GHCi" (interactive Haskell).

What is the technical term for this?

References, tutorials how to write bash programs with their own environment would be great.


name@name ~$GOOFY
GOOFY >mv foo (where goofy's mv does something else then regular mv)

I think REPL (read-eval-print-loop) is what you are looking for.

From the wikipedia page:

A read–eval–print loop (REPL), also known as an interactive toplevel or language shell, is a simple, interactive computer programming environment that takes single user inputs (i.e. single expressions), evaluates them, and returns the result to the user; a program written in a REPL environment is executed piecewise.

  • thanks, so this would mean that I can write a code that reads the input, make a calculation (or whatever) and instead of quitting, it just simply returns to an input line again. It makes sense, I though this was much more complicated. – B.Kocis Jun 10 '15 at 8:36

I would call this sort of thing "an interpreter". I've done a few using standard development tools lex (actually flex) and yacc or bison. To blow my own horn, my combinatory logic interpreter works pretty much as you describe, and you can find Stackoverflow answers recommending this path. Plenty of tutorials exist on the web (of varying quality) for lex and yacc. The tutorials might talk of building compilers, but flex-generated code recognizes interactive usage, and acts accordingly. Also, the canonical example of something in this kind of interpreter is a "scientific calculator". Don't let that sort of thing bother you. If you can define the commands you want, you can build a BNF grammar for it in bison. You may have to iterate a few times, but the compromises won't be that bad.

  • 1
    Talking to an interpreter on a command line is exactly what “REPL” means. – Gilles 'SO- stop being evil' Jun 8 '15 at 23:11
  • thanks for the links, but if I may ask a stupid question, why is lex or yacc or bison the right tool for an interpreter? Is a simple bash script that takes the input (with read) and reacts to it, and returns to an input line again not the right approach? – B.Kocis Jun 10 '15 at 8:41
  • @user216125 - a lex/yacc interpreter is overkill for simple situations, but the dividing line between simple and complex sneaks up on you. It's usually pretty easy to get lex to recognize new tokens, and yacc to incorporate them in a parse tree. It's easy at first to do your own token recognition, and maybe recursive descent parsing, but soon enough, it's hard to add that new command. yacc gives you a grammar, with which you can recognize more kinds of input. A bash "while read" loop is fairly inflexible as far as number of tokens in a command, and recognizing tokens once you've got them. – Bruce Ediger Jun 10 '15 at 14:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.