Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Are there any IDEs targeted at shell scripting, specifically bash and zsh scripts? This means having syntax-highlighting for shell scripts and more importantly debugging environments with features like breakpoints, variable inspection and modification, etc., just like those available for regular programming languages like Python, Java, and C.

For instance Microsft Windows Powershell has IDEs like Powershell Plus and PowerGui.

Googling brought up a combination of ShellEd, an Eclipse plugin for editing shell scripts, and BashEclipse, a Bash debugger that works with ShellEd; I haven't tried it yet.

Are there any other shell scripting IDEs for Un*x similar to this combo? Does anyone have some experience with them?

share|improve this question
how does someone vote down a question with 30 seconds it of being posted? – vfclists Mar 8 '14 at 22:44
I did not downvote but whoever did, did so because you are not asking a question. The only question in your post can be answered with a Yes/No. What are you actually asking? How do these programs work? What they do? What are you trying to do exactly? – terdon Mar 8 '14 at 22:48
A bash IDE? Nuclear fission to boil water for tea... – jasonwryan Mar 8 '14 at 23:00
Actually, having a bash debugger is a very good idea -- just as with any programming language, your code will be better if you step through each line in the debugger slowly, examine the variables, think about what the code is doing, etc. A debugger is the best way to do that, even if your program or script doesn't have bugs. You can get bashdb in most distributions, which will allow you to do that in text mode. Also, the aging DDD graphic debugger can be made to work with bashdb so you have a more "visual" experience. – Stabledog Mar 9 '14 at 5:59
Yes, certainly one can do that. And many do, and that's how they get by for years. If that suits you, I wouldn't try to convince you otherwise. In my opinion, its an inferior approach that taxes the brain with low-value tasks (like mentally keeping track of the values of variables, etc). The idea of a good debugger UI is freeing up those cycles for thinking about the program. In my experience, this matters -- you have more attention free to focus on thinking about what the program is doing if you're spending less of it on such things. – Stabledog Mar 10 '14 at 20:20
up vote 4 down vote accepted

I wouldn't say it is either well known or well used but you might have a look to basheclipse:

enter image description here

I must admit I have no experience with basheclipse and even failed to install it due to an eclipse version mismatch.

On the other hand, I'm using bash and ksh93 specific debugging features, especially the trap ERR and trap DEBUG ones but not the debuggers based on them kshdb and bashdb

share|improve this answer
I find it rather ironic that your screen-shot is of a Windows-style window. – Agi Hammerthief Mar 10 '14 at 17:54
@NigelNquande To be honest, I'm not a basheclipse (or eclipse for that matter) user. I definitely use debugging features provided by ksh93 and bash, but no GUI. This screenshot is taken from the basheclipse site. It might be some gnome theme or just a real Windows 7 screenshot given the OS="cygwin" line. – jlliagre Mar 10 '14 at 21:11
Well, IMO, if you're going to do something, do it with boots on, not half-aed (but that's neither here nor there to anybody else). To me, bash on Windows seems half-ased when it works perfectly well in GNU/Linux. – Agi Hammerthief Mar 10 '14 at 21:15
@NigelNquande As I wrote, this isn't a screenshot of mine. In any case, I only use bash on Windows when I have no choice and cygwin is quite efficient to hide the underlying OS. – jlliagre Mar 10 '14 at 21:33

A purpose-built IDE would sort of defeat the purpose of shell scripting, not to mention that it's nearly impossible to do, because most of what shell does is calling external commands - how do you debug that? Debugging with checkpoints is counterintuitive for a shell - shell scripts usually operate heavily on files and thus have destructive side-effects on every call. Scripting BY DESIGN works line-by line, so your "environment" is actually the terminal itself - you can always echo variables, your environment is always there for you, there is no "prescribed flow" that you would have to interrupt. You progressively do whatever you want to do, line by line, testing each time if you got what you wanted and then paste these lines into a script to use again. Any IDE would actually just disable most of what you can do in the shell itself.

For fully qualified scripting languages (Python, Perl etc) you do have all this, but bash/zsh/ksh/... are interactive "glue" for other commands and are their own debuggers.

However, most text editors will highlight the code for you, and emacs will (provided you find the right packages, I never bothered with doing that for shell scripts) provide programmable keyword completion. I believe vi can do that as well (don't start a flamewar here please).

share|improve this answer
How do you define a "fully qualified scripting language?" – Trevor Sullivan Dec 19 '15 at 4:44

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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