Terminal based development environment

[andyzammy]

I've recently started a new job working as a software developer. It's a very non-invasive environment, in that we're allowed to use whatever tools we want to get the jobs done.

I'm very interested in using terminal solutions if it's possible, but with my limited knowledge, it's extremely difficult navigating around big projects without using drawn-out steps.

At my current level it's just easier to use KDevelop which seems to be the preferred IDE of choice around here, and I can see why; hovering the mouse over... well, anything, gives you much information (where it's defined, return + args if function, where it's used, it'll sometimes even display coded comment, or a description if it's given one in it's definition).

I remember seeing a thread on here a long while back of someone asking how to find out where a particular function is defined, and someone supplied him with a script that did just that. I've searched but I couldn't find it.

I'd love to hear from people who develop solely on the command line, and how they achieve the 'smart' features of IDEs. Right now I can only manage one-file programs with vi (my preference), I'd like to know how I can progress to doing more with it. Any links would be appreciated!

Regards

 

[akil]

Hi,

I often use devel/cscope and editors/vim because sometimes I need to work remotely.

 

[drhowarddrfine]

You have to learn the unix commands, simple as that. Vim has a lot of plugins but I don't use them (cause I haven't bothered to look into it). 'grep' could easily give the same info you showed about the function.

 

[segfault]

Wow lucky you, would love to have that kind of leeway in dev environment in the work place.
I have been looking into similar stuff (for personal uses) and the following links may help:

http://vim.wikia.com/wiki/Use_Vim_like_an_IDE

http://www.thegeekstuff.com/2009/01/tutorial-make-vim-as-your-cc-ide-using-cvim-plugin/

Hope that helps get you started.

 

[neilms]

Well I do not see how you can expect to get any real development work done using vi, unless your development is restricted to fiddling around with system files. The only viable solution is for real programmers to use emacs. Even then, you should know that it has a steep learning curve. No pain, no gain brother.

 

[drhowarddrfine]

I have a very successful web dev business that deals mostly with ecommerce sites and I've been doing this for 9 years and have been a system engineer since the early 90s. The only thing we use is vim. I've not taken the time to learn emacs though I want to. We get lots of dev work done using only vim as an editor. Of the other programmers who work for me, none of them know emacs either though a couple of free-lancers do. I wish they had the time to teach it to me.

 

[andyzammy]

Thanks for all the replies so far! Please keep them coming!

Well I do not see how you can expect to get any real development work done using vi, unless your development is restricted to fiddling around with system files. The only viable solution is for real programmers to use emacs. Even then, you should know that it has a steep learning curve. No pain, no gain brother.

Please could you give some real-world scenarios and examples as to why you think this? I have never been keen on emacs due to the 'chord-like' way of operating it. I have also heard of cases of RSI being caused by emacs (I like my hands).

Functionally though, I always thought that vi and emacs are equally capable, they just have different user interfaces... are you saying this isn't the case?

 

[kpedersen]

I find using midnight-commander as the file manager and setting up vim as the editor works really well.

In mc, you can have the .h in one panel and the .cpp in the other and then just tab between them.

For vim, make sure you enable the ability to remember previous location, it makes it much easier when working on a large amount of source.

I then also take advantage of tmux and usually end up calling `make -f Makefile.FreeBSD` on screen 0, and then the mc/vim combo on screen 1. (Obviously toggling between them).

 

[Zare]

Check out devel/motor

 

[NewGuy]

I think the command grep -R function-name *.h would probably show you where a function was defined most of the time.

 

[expl]

I think the command grep -R function-name *.h would probably show you where a function was defined most of the time.

1. This will work only if you keep all header files in one place, very rarely the case in larger projects.
2. Will not work for library header files with custom include paths.
3. Grep is slow, primitive and just a slug in general.

Most modern IDEs use smart code assistance algorithms and methods mainly based on initial scan&cache and on file state changes.

To original author:
Vim & emacs are just text editing 'specs' that can be achieved on big IDEs like Elipse using plug-ins. There are probably some tools for a bare metal emacs to add some sort of code assistance general features, but they are far from what you could get in a proper IDE.

In general:
I rarely understand the pop culture in *nix programming, to go for purely terminal based development.

 

[drhowarddrfine]

In general:
I rarely understand the pop culture in *nix programming, to go for purely terminal based development.

It's simple.
It works everywhere.
Everyone knows how to use it.
The tools follow the Unix philosophy.
You can create your own tools by combining existing tools.
You don't have to rely on an IDE to eventually build a feature you want.

 

[expl]

It's simple.

Usually its the oposite of simple, taking very long time to set-up a proper working environment in comparison to just installing IDE+Plug-ins you like.

It works everywhere.

Define 'everywhere'. can I develop using my toaster? If not its not really an advantage over most popular IDEs that run on any computer and OS that have graphical display (no longer a privilege since late 80s).

Everyone knows how to use it.

What is 'it'? Emacs, vim or just terminal in general? For first two its hardly true.

The tools follow the Unix philosophy.

Really depends on what tools you are referring to, 'Unix philosophy' is also very vague definition. However emacs and vim definitely fallow 'Linux philosophy' as of having hundreds of flavors and editions to choose from if you are into that kind of type of hard to please.

You can create your own tools by combining existing tools.

Thats how any proper IDEs work as well, spend some time and study Elipse and its vast plug-in system and how they all work together.

You don't have to rely on an IDE to eventually build a feature you want.

I rarely use autobuilding features in Eclipse and write all Makefiles myself and it is as easy as changing couple flags in project configuration.

 

[kpedersen]

I also agree with the benefit that it works generally everywhere such as over ssh (a big advantage for me).
Vi/vim/emacs also has a much higher chance of working on a toaster than eclipse. With NetBSD this is very much a reality AFAIK.

- Eclipse/CDT (C++) is completely broken on most UNIX and isnt even available for most UNIX.

- Anjuta is pretty broken.

- Netbeans uses java and is thus "broken".

- Monodevelop will be dead as soon as Microsoft drops .NET and goes to the next gimmick (codenamed WinRT)

Anything else isnt quite featureful enough (gedit, scite, nedit) to be used as an IDE whereas Vim (with plugins) provides much more (such as project navigation, refactoring, intellisense etc...)

Also, now this doesn't apply to everyone but I dislike wasting time learning new things when I am on a deadline. I havn't had to relearn a new IDE since I started using Vim. Whereas Visual Studio since version 6 has changed an absured amount.

Not to mention, plugins for eclipse, Visual Studio etc... break daily. Vim plugins simply never break.

I can also maintain a version of Vim myself incase the developers go crazy (and merge it with systemd etc...) unlike eclipse, where I am at the whims of the developers (and IBM!) or Oracle with netbeans. Or Microsoft with Monodevelop...

 

[expl]

I also agree with the benefit that it works generally everywhere such as over ssh (a big advantage for me).

I myself use vi over ssh for quick 'fixes' or editing configs. But its not suited for development as you need relatively low latency to work properly as anything above 100ms causes discomfort (at least for me).

- Eclipse/CDT (C++) is completely broken on most UNIX and isnt even available for most UNIX.

- Netbeans uses java and is thus "broken".

Both Eclipse and Netbeans are written in Java. Actually Java would be the only way to build any cross platform GUI interface without forking, so I do not believe any other language&toolkit combination would be very suited.

I haven't tried running Eclipse outside Linux/OSX/FreeBSD but on first two its fully functional out of the box and in later it needs to be tweaked a bit as the autobuilding is broken due to bsd make, other than that it works. Haven't tried Netbeans outside OSX, but on OSX it runs very smooth.

Besides you do not need to run IDE on specific OS to develop for it as you can run building remotely straight from IDE.

Personally I use OSX for all of my development + VirtualBox for any target OS building.

Also, now this doesn't apply to everyone but I dislike wasting time learning new things when I am on a deadline. I havn't had to relearn a new IDE since I started using Vim. Whereas Visual Studio since version 6 has changed an absured amount.

Well both Eclipse and Netbeans have intuitive interfaces so there is not much to learn. That is not the case with VS or XCode.

Not to mention, plugins for eclipse, Visual Studio etc... break daily. Vim plugins simply never break.

I am not using that many plug-ins, just GIT/SVN, GDB front-ends and they haven't failed on me a single time. Main drive for using it is code assistance and object navigator/explorer.

I can also maintain a version of Vim myself incase the developers go crazy (and merge it with systemd etc...) unlike eclipse, where I am at the whims of the developers (and IBM!) or Oracle with netbeans. Or Microsoft with Monodevelop...

You can always stick with a fixed earlier version for Eclipse/Netbeans if you do not like changes.

 

[kpedersen]

You can always stick with a fixed earlier version for Eclipse/Netbeans if you do not like changes.

I am not sure I could maintain these large ports myself. Especially eclipse which is a strange mixture of Java and C++. I certainly wont be able to maintain them for all operating systems I tend to use at work.

I also find when working on very large projects, an IDE is generally impossible to use due to the sheer amount of files that it contains. For example, opening up the Linux kernel in Visual Studio would be quite horrid.

 

[expl]

I am not sure I could maintain these large ports myself. Especially eclipse which is a strange mixture of Java and C++. I certainly wont be able to maintain them for all operating systems I tend to use at work.

Thats why its best practice to settle to single OS and build over SSH (there are plug-ins for that, or you can use self made scripts).

I also find when working on very large projects, an IDE is generally impossible to use due to the sheer amount of files that it contains. For example, opening up the Linux kernel in Visual Studio would be quite horrid.

In case of very large code bases its best to segment them to separate project files just like you are segmenting build scripts. Like specific driver would then be a separate Eclipse project.

 

[kpedersen]

Thats why its best practice to settle to single OS

Ah this is probably where our methodology differs. My aim was to be platform agnostic and be able to maximize a terminal emulator and not really know or care what platform I am on.
For example, when developing for android (and gimmicky shite like that), I just plug in a keyboard, fire up a terminal emulator on the tablet and write code / debug as usual. Rather than use eclipse on a desktop PC and an emulator / connecting to the device via USB and plugins (which I never got working properly).

The terminal / vim solution is admittedly the lowest common denominator, but now that I have learnt and gotten used to it (to a point where I am more proficient with it than an IDE), I am quite happy to not change and unless things like gnome 3 radically change and become useful again, the command line will be my sanctuary lol.

Each to their own, and the fact that there are now many many IDEs around, does suggest that they have advantages that I am probably missing out on.

 

[andyzammy]

I then also take advantage of tmux and usually end up calling `make -f Makefile.FreeBSD` on screen 0, and then the mc/vim combo on screen 1. (Obviously toggling between them).

I achieve a similar thing by creating a script called m in ~/bin (added to $PATH of course) and hitting :!m inside vi. I think it's faster and neater, though I do multiplex too.

As for using mc, interesting suggestion, I've not used it yet. Seems like a reasonable tool to browse source files/trees.

 

[andyzammy]

Personally I use OSX for all of my development + VirtualBox for any target OS building.

I am in agreement with points others have raised against your argument for IDE. I'm also interested in embedded development so it is very realistic that I might one day have to develop on a 'toaster'. I like the idea of having a set of tools that I can take absolutely anywhere.

What IDE do you use on OSX out of curiosity? xcode?

 

[expl]

a set of tools that I can take absolutely anywhere.

That is far from true, there are platforms that are not command tool friendly. For example Symbian, iOS and embedded Windows devices. For these you will need to run native IDEs or waste a lot of time and then in the end use the native IDEs anyways. If you can do that on Android it does not make it universal.

What IDE do you use on OSX out of curiosity? xcode?

Well if you had carefully read my posts here(this topic) you would find out that I do not like XCode and use Eclipse . Even though you have to use XCode at least for the iOS programming, also making other IDEs work well with cocoa is problematic so XCode is the right tool for that.

 

[andyzammy]

That is far from true, there are platforms that are not command tool friendly. For example Symbian, iOS and embedded Windows devices. For these you will need to run native IDEs or waste a lot of time and then in the end use the native IDEs anyways. If you can do that on Android it does not make it universal.

Absolutely, I wouldn't really class these as embedded platforms anyway (well obviously they are, but when you're developing apps for iphones and such you're not really doing embedded development - you're just developing). Right tool for the right job. However, in situations where I'm not forced to use an IDE I would try to use vi/vim first (can't speak for windows or blackberry but iOS and Android look to have command line tools).

Well if you had carefully read my posts here(this topic) you would find out that I do not like XCode and use Eclipse . Even though you have to use XCode at least for the iOS programming, also making other IDEs work well with cocoa is problematic so XCode is the right tool for that.

I did pick up on what you liked and used but the way you said you used OSX for your development that made me think you were using something OSX specific too, which is why I asked

I'm surprised this thread hasn't received more interest. Maybe it would get more input on the mailing lists?

 

[expl]

but iOS and Android look to have command line tools

Only if you jail break the iOS device and install them, otherwise no. And as far as I understand iOS apps can not be bundled and signed locally on the device itself since the bundler is closed source and part of XCode package, so you will need XCode anyways.

I did pick up on what you liked and used but the way you said you used OSX for your development that made me think you were using something OSX specific too, which is why I asked

If I have to use cocoa (that is not very often) I will use XCode, but I really dislike it as it feels weird and takes long time to get used to it. Also Apple completely changing it's interface with every major version does not help out.

Maybe it would get more input on the mailing lists?

Probably, its more of a 'consumer' than a development forum.

 

[andyzammy]

Only if you jail break the iOS device and install them, otherwise no. And as far as I understand iOS apps can not be bundled and signed locally on the device itself since the bundler is closed source and part of XCode package, so you will need XCode anyways.

I know about this method but I wasn't actually referring to that one. There is a tool(s) called xcodebuild which allows compilation from the command line on the development computer. It's not native development but it allows removal from the IDE.

I think I will post on the lists. I'm interested to see exactly how a big code base such as FreeBSD is developed and maintained.

Thanks for the input everyone!

 

[kpedersen]

For example Symbian, iOS and embedded Windows devices. For these you will need to run native IDEs or waste a lot of time and then in the end use the native IDEs anyways. If you can do that on Android it does not make it universal.

Other than Symbian (which I have not developed for), I have only ever used the command line to develop for iOS, Windows Mobile and Android.
The only reason why most tutorials / help documents for these platforms uses an IDE is because these types of platforms are more directed towards the amateur / hobby developer market.

From all of them, Android was the most pain to create Makefiles and a proper build system for for because most of the documents were targeted towards the Ant build system and I effectively had to reverse engineer the build steps.

Luckily, I can plug in a keyboard on my android device, fire up the terminal, tmux, mc and vim and develop straight on the device.

http://code.google.com/p/terminal-ide/
https://play.google.com/store/apps/details?id=com.spartacusrex.spartacuside&hl=en

You can't do that if you are stuck requiring Eclipse or Visual Studio

Interestingly, Windows Mobile was the easiest to get building via the command line (using msbuild) because they have a large amount of documentation to help with scripting continuous integration systems such as bamboo, jenkins etc...