4 ms·

I agree that many underestimate the power of bash for development. Make, in particular, is much more widely usable. However, there are some things that I find v

I agree that many underestimate the power of bash for development. Make, in particular, is much more widely usable. However, there are some things that I find very convenient in an IDE that are harder to do at the command line. Finding usages of a name (variable or function); finding the definition of same. Renaming same throughout the code base. Yes, I know about "find | xargs grep", but it's a bit more convoluted than IDE usage. Maybe I just don't know enough. Can anyone point to command line or vim tools to accomplish these tasks? Code analysis and warnings are another thing IDEs seem to do better.

lubutu 14y ago
You're looking for ctags or cscope, the first of which is mentioned in the blog. As for code analysis and warnings, surely that's a property of the compiler being used?
- tallpapab 14y ago
  Thanks for the reply. ctags is a great tool, but it is not as easy as an IDE. IDEs keep track without my having to explicitly rebuild the tag data base. IDEs have plugins for different languages. The dynamic flagging of errors and warnings without having to explicitly compile is a time saver. Refactoring tools can also save quite a bit of time. Renaming a function becomes trivial in an IDE. Of course, there are many things for which vim and bash (":%! sort -n" anyone?) are far superior to an IDE. I tend to use both.
  - NickPollard 14y ago
    There are some things IDEs do better, but these Unix tools give you more choice. It should be pretty simple to add a hook to vim to rebuild the tags whenever you save a buffer, for example. That should take the load off your mind. The issue with IDEs I find is that this stuff is automatic and no way to turn it off, and then I find at the worst time that Visual Studio is crawling to a halt as it runs a load of complex parsing in the background on my 500k lines of C++, just when all I wanted to do was write some code. Think of it as separation of concerns - you wouldn't write a program where all the code was in one tightly bound monolithic system. Why do so for your tools?
    - tallpapab 14y ago
      As quickly as you can turn your back on Visual Studio. (Sorry, just kidding ... sort of.) Eclipse and NetBeans are a couple IDEs (there are others) that use a module system to build what can appear to be a monolith. Look into OSGi which is an attempt to standardize modularizing GUIs. Of course, I haven't run these tools on 500k lines of C++ just half that of java code. P.S. I used "find . -name \*.java | xargs cat | wc -l" to count the lines of java code. I did not use the IDE for that, giggle.
  - truncate 14y ago
    Plus ctags isn't really that smart, or you can say the way it is used. For example I have a struct "foo" that has different independent declarations in several files in my source tree. Whenever, I would try to open that tag, list of all tags would show up regardless the files included in the current source files. This is quite irritating. Another not-so-smart feature is auto completion (in C++ at least) and refactoring. However I can live with these missing features as once you get used to something like Vim or Emacs, its quite frustrating to work on bloated IDE's.
    - tallpapab 14y ago
      How does ctags do when a variable name is repeated in a different scope? I do rather wish for a really good vim type replacement for the editor in NetBeans though. I keep inadvertently entering vim motion commands in my java text - sigh.
      - Symmetry 14y ago
        Well, if you're using ctags through vim it guesses by default, or you can use :ts to get a list of the possibilities. Not ideal, I know, but often good enough.
      - falcolas 14y ago
        It picks the "best" one (typically the one in the scope of your current file), and lets you change which one to go to, without ruining your tag stack. For example, if I Ctrl-] over `open`, and it pops me to the wrong one, I can then type :ts and pick the proper entry (typically with info about the file, type, and container). I can then Ctrl-t back to the previous context as normal.
deleted 14y ago
[deleted]
deleted 14y ago
[deleted]
enduser 14y ago
This is a significant reason that many Unix hackers prefer languages like C or Common Lisp where the same symbol means the same thing system-wide. Plain text grep, sed, and ex commands make refactoring quite simple and don't require fancy plugins to figure out what a name means in a given context.
- kevinnk 14y ago
  > "This is a significant reason that many Unix hackers prefer languages like C or Common Lisp where the same symbol means the same thing system-wide." I don't know about lisp, but that's not even close to true for C. typedef struct A { int A; } A; is an easy counter example and that doesn't even take into account macros or any of the other tools that play horribly with grep and friends. The reason Unix hackers prefer C is because it's rock solid, extremely well supported and plays nicely with hardware. And it doesn't hurt that it's old enough and popular enough that a huge number of people have extensive experience with it.
  - pka 14y ago
    Not true for Lisp (Clojure) either: (defn a (let [a ...] (+ a a)))
babarock 14y ago
I'm going to be a tad pedantic and note the following: - bash and make are completely separate programs. As a matter of fact, I spend half of my time developing with ksh and Solaris make. The two programs you mention don't go 'hand in hand'. - `find | xargs grep` is a terrible construct. 99% of the time (if not a lot more) you'd prefer using something like `find -exec`, I have yet to come across a version of `find` that wouldn't work that way. My point is not to be an arrogant prick, and criticize the parent post. These kind of misconceptions usually indicate poor understanding of the larger Unix philosophy. By her own admission, my parent "just do[es]n't know enough". I believe that in order to truly use Unix as an IDE, one has to go beyond the (arguably bad) reflexes taught by common GUI IDEs. It's not simply a matter of "What command can replace feature X from Netbeans/Eclipse/Visual Studio/...?" Modern IDEs weren't conceived with sed/awk in mind, aren't (for the most part) scriptable like most Unix shells are, and aren't sitting on top of a freaking Lisp machine like emacs is (you know the whole enlightment deal, lisp is superior, bla bla bla). I am sounding like an evangelist, Unix tend to do that to me. I am trying to make a simple point: It's normal to feel that something is missing if one is simply transposing her knowledge from point-and-click IDEs to the Unix shell. (To answer your question, a combination of sed and awk does wonder to rename across the code base. And SO much more ...)
- slurgfest 14y ago
  There needs to be far better evangelism/PR to tell people the right way to do all these things so that they understand how to do all the IDE stuff, the truth is that the number of use cases people need is not unlimited... of course it is good to know the full range of flexible tools, but it's far from obvious to most people whether or not find | xargs grep is good or not, or how to do a method rename
  - npsimons 14y ago
    of course it is good to know the full range of flexible tools, but it's far from obvious to most people whether or not find | xargs grep is good or not, or how to do a method rename It's also far from obvious whether a for or a while loop best fits the problem at hand. How does one figure these things out? By learning about the tools/constructs and using them (experience). Furthermore, it is expected of software developers to know these things. It's all well and good to be an IDE jockey, but being a software developer entails more than clicking through wizards and filling in some logic. Learning tools (such as UNIX CLI tools) opens up a whole other world of untold power in accomplishing not just programming tasks, but everyday tasks as well (how many people know that there is a CLI unit conversion program that not only has more units than you can shake a stick at, but is scriptable and has a tiny footprint to boot?). Not to mention that these tools have been around and ported to just about everything, and will probably continue to be around for ever, and eat less RAM and CPU while being more flexible and powerful than their GUI counterparts. Edit: I didn't mean to come off condescending and scolding, but I forgot to insert some helpful links in response to your statement that there should be better evangelism/PR for shell programming; hope these links fit the bill: http://www.bashoneliners.com http://www.bashoneliners.com http://www.commandlinefu.com http://www.commandlinefu.com http://www.shell-fu.org http://www.shell-fu.org http://noone.org/blog/English/Computer/Debian/CoolTools http://noone.org/blog/English/Computer/Debian/CoolTools http://noone.org/blog/English/Computer/Shell http://noone.org/blog/English/Computer/Shell

lubutu 14y ago

You're looking for ctags or cscope, the first of which is mentioned in the blog. As for code analysis and warnings, surely that's a property of the compiler being used?

tallpapab 14y ago
Thanks for the reply. ctags is a great tool, but it is not as easy as an IDE. IDEs keep track without my having to explicitly rebuild the tag data base. IDEs have plugins for different languages. The dynamic flagging of errors and warnings without having to explicitly compile is a time saver. Refactoring tools can also save quite a bit of time. Renaming a function becomes trivial in an IDE. Of course, there are many things for which vim and bash (":%! sort -n" anyone?) are far superior to an IDE. I tend to use both.
- NickPollard 14y ago
  There are some things IDEs do better, but these Unix tools give you more choice. It should be pretty simple to add a hook to vim to rebuild the tags whenever you save a buffer, for example. That should take the load off your mind. The issue with IDEs I find is that this stuff is automatic and no way to turn it off, and then I find at the worst time that Visual Studio is crawling to a halt as it runs a load of complex parsing in the background on my 500k lines of C++, just when all I wanted to do was write some code. Think of it as separation of concerns - you wouldn't write a program where all the code was in one tightly bound monolithic system. Why do so for your tools?
  - tallpapab 14y ago
    As quickly as you can turn your back on Visual Studio. (Sorry, just kidding ... sort of.) Eclipse and NetBeans are a couple IDEs (there are others) that use a module system to build what can appear to be a monolith. Look into OSGi which is an attempt to standardize modularizing GUIs. Of course, I haven't run these tools on 500k lines of C++ just half that of java code. P.S. I used "find . -name \*.java | xargs cat | wc -l" to count the lines of java code. I did not use the IDE for that, giggle.
- truncate 14y ago
  Plus ctags isn't really that smart, or you can say the way it is used. For example I have a struct "foo" that has different independent declarations in several files in my source tree. Whenever, I would try to open that tag, list of all tags would show up regardless the files included in the current source files. This is quite irritating. Another not-so-smart feature is auto completion (in C++ at least) and refactoring. However I can live with these missing features as once you get used to something like Vim or Emacs, its quite frustrating to work on bloated IDE's.
  - tallpapab 14y ago
    How does ctags do when a variable name is repeated in a different scope? I do rather wish for a really good vim type replacement for the editor in NetBeans though. I keep inadvertently entering vim motion commands in my java text - sigh.
    - Symmetry 14y ago
      Well, if you're using ctags through vim it guesses by default, or you can use :ts to get a list of the possibilities. Not ideal, I know, but often good enough.
    - falcolas 14y ago
      It picks the "best" one (typically the one in the scope of your current file), and lets you change which one to go to, without ruining your tag stack. For example, if I Ctrl-] over `open`, and it pops me to the wrong one, I can then type :ts and pick the proper entry (typically with info about the file, type, and container). I can then Ctrl-t back to the previous context as normal.

deleted 14y ago

[deleted]

deleted 14y ago

[deleted]

enduser 14y ago

This is a significant reason that many Unix hackers prefer languages like C or Common Lisp where the same symbol means the same thing system-wide. Plain text grep, sed, and ex commands make refactoring quite simple and don't require fancy plugins to figure out what a name means in a given context.

kevinnk 14y ago
> "This is a significant reason that many Unix hackers prefer languages like C or Common Lisp where the same symbol means the same thing system-wide." I don't know about lisp, but that's not even close to true for C. typedef struct A { int A; } A; is an easy counter example and that doesn't even take into account macros or any of the other tools that play horribly with grep and friends. The reason Unix hackers prefer C is because it's rock solid, extremely well supported and plays nicely with hardware. And it doesn't hurt that it's old enough and popular enough that a huge number of people have extensive experience with it.
- pka 14y ago
  Not true for Lisp (Clojure) either: (defn a (let [a ...] (+ a a)))

babarock 14y ago

I'm going to be a tad pedantic and note the following: - bash and make are completely separate programs. As a matter of fact, I spend half of my time developing with ksh and Solaris make. The two programs you mention don't go 'hand in hand'. - `find | xargs grep` is a terrible construct. 99% of the time (if not a lot more) you'd prefer using something like `find -exec`, I have yet to come across a version of `find` that wouldn't work that way. My point is not to be an arrogant prick, and criticize the parent post. These kind of misconceptions usually indicate poor understanding of the larger Unix philosophy. By her own admission, my parent "just do[es]n't know enough". I believe that in order to truly use Unix as an IDE, one has to go beyond the (arguably bad) reflexes taught by common GUI IDEs. It's not simply a matter of "What command can replace feature X from Netbeans/Eclipse/Visual Studio/...?" Modern IDEs weren't conceived with sed/awk in mind, aren't (for the most part) scriptable like most Unix shells are, and aren't sitting on top of a freaking Lisp machine like emacs is (you know the whole enlightment deal, lisp is superior, bla bla bla). I am sounding like an evangelist, Unix tend to do that to me. I am trying to make a simple point: It's normal to feel that something is missing if one is simply transposing her knowledge from point-and-click IDEs to the Unix shell. (To answer your question, a combination of sed and awk does wonder to rename across the code base. And SO much more ...)

slurgfest 14y ago
There needs to be far better evangelism/PR to tell people the right way to do all these things so that they understand how to do all the IDE stuff, the truth is that the number of use cases people need is not unlimited... of course it is good to know the full range of flexible tools, but it's far from obvious to most people whether or not find | xargs grep is good or not, or how to do a method rename
- npsimons 14y ago
  of course it is good to know the full range of flexible tools, but it's far from obvious to most people whether or not find | xargs grep is good or not, or how to do a method rename It's also far from obvious whether a for or a while loop best fits the problem at hand. How does one figure these things out? By learning about the tools/constructs and using them (experience). Furthermore, it is expected of software developers to know these things. It's all well and good to be an IDE jockey, but being a software developer entails more than clicking through wizards and filling in some logic. Learning tools (such as UNIX CLI tools) opens up a whole other world of untold power in accomplishing not just programming tasks, but everyday tasks as well (how many people know that there is a CLI unit conversion program that not only has more units than you can shake a stick at, but is scriptable and has a tiny footprint to boot?). Not to mention that these tools have been around and ported to just about everything, and will probably continue to be around for ever, and eat less RAM and CPU while being more flexible and powerful than their GUI counterparts. Edit: I didn't mean to come off condescending and scolding, but I forgot to insert some helpful links in response to your statement that there should be better evangelism/PR for shell programming; hope these links fit the bill: http://www.bashoneliners.com http://www.bashoneliners.com http://www.commandlinefu.com http://www.commandlinefu.com http://www.shell-fu.org http://www.shell-fu.org http://noone.org/blog/English/Computer/Debian/CoolTools http://noone.org/blog/English/Computer/Debian/CoolTools http://noone.org/blog/English/Computer/Shell http://noone.org/blog/English/Computer/Shell