My IDE is full screen emacs, with one emacs window running a shell for when I just want a command line. This works great on MacOSX and on Linux. It gives me integrated debugging, code navigation (with cscope-mode), code completion, git support and more. The downside is the steep learning curve, but I climbed that years ago and haven't looked back.
OK, wonderful. What text editor do you use in this environment? vim? emacs? ed? Where do you run your command line? A command line can run in a dedicated terminal emulator, or it can run...inside of an IDE, or inside of emacs, or tmux. How do you do compile/edit cycles--vim quickfix? Just run the compiler in a separate window and manually move to each error?
The post mentions composition, extensibility, and keyboard instead of mouse. Many IDEs can do that. Certainly emacs can. Then it says that the UNIX way has "consistency." If that were true I wouldn't spend so much time reading the bash man page when I'm trying to figure out all the ${parameter:?expansion} options.
This is not really a specific post. It's your usual paean to old-school UNIX but it does not say what it really means to use "the command-line as a programming environment".
Heh. I am one of those old-school UNIX people, and this post does little for me. It's really just somebody's thoughts out loud.
It's also their first and only blog post on his blog which, now that I look at it, he calls "My random thoughts."
Hmmm. I'm wondering how this got upvoted...
Reading a little bit more about the person on their about page: "I was relatively successful,creating and managing over 10 websites on a dedicated server generating around 5000 users/day at peek time. Along the way, I’ve created a couple of softwares to promote websites, scrape data, post content, break captchas etc…"
I can't speak for the poster, but I use vim quickfix, often populated from the shell. alias cbuf='vim - -c "cbuf!"' allows for things like `git grep -n frobnitz | cbuf`.
I would love to see more projects embrace this method of development as a lowest-common-denominator. I'd be great to be able to download a library and build it using the least number of tools. For a Java project, this might just be javac. The project could include build descriptors for ant, maven, etc. as well as IDE config.
It feels like half the time I download a Java/Maven project, there is some issue with the build that I have to spend time debugging. I'm not familiar with Maven, and Maven is pretty complicated, so this is a pain.
> It feels like half the time I download a Java/Maven project, there is some issue with the build that I have to spend time debugging. I'm not familiar with Maven, and Maven is pretty complicated, so this is a pain.
Maven actually simplifies a lot and luckily has been kind of the standard on Java for the last few years.
For simple projects, as long as you have a working jvm and mvn on the path it is just a matter of mvn build. Also IDEs, at least IntelliJ and NetBeans tends to understand pom natively.
For more complicated projects my gut feeling is they would have been even more complicated without maven.
It may be standard for Java, but I wouldn't say it's simple. I'll give you an example.
Say I want to use protobufs. There are a couple prerequisites: 1) I have to know the protobuf syntax. 2) I have to know how to compile the protobuf file into my language of choice.
If you're using maven, you also have to know which plugin to use (a simple google search), and add the 30 lines of XML to your build file. This is not such a big deal, except you're also hoping that the plugin supports all the protoc features that you may need. And what versions of protoc does the plugin work with? And is the plugin well documented?
Compare this to using make, or even using the <exec> ant task. protoc is well documented and you can access all the features you want in a standard way (command line options and arguments).
Fair point. But I'd say the dependency management in maven is actually more of a hassle than it's worth. For me, I understand jars in a lib directory well enough. Dependency management can become complicated pretty fast (e.g. version resolution).
I find that after I discovered tmux, I was able to use the command line full-time much more easily. Now everything I do is command-line-unix-ey, from my coding (with Emacs) to my web browser (Elinks).
It's kind of a pain in the butt to learn, but I feel that it helps me stay focused on my work; there are a lot less distractions in the command-line world.
I like the idea of text-mode browsing, but I find the translation of CSS causes practical problems whether its elinks link lynx etc. For example, Hacker News nested comments are displayed as being on one level. There is a hack to fix this, but per-site hacks is not a usable way to browse the web.
> For example, Hacker News nested comments are displayed as being on one level.
I think that this is because syntactically they are on the same level. Assuming I'm reading the source correctly, they're all cells in a table, at the same level, rather than being nested.
So elinks et al. are correct; the site is using CSS to indicate something not in the structure.
>For example, Hacker News nested comments are displayed as being on one level.
Interesting. I just tried reading HN on Firefox Mobile recently, and noticed that the comments all show as on one level, not nested. But show okay in mobile Chrome.
In a Slashdot interview in 2004, in response to the question:
... have you embraced the new UNIX based MacOS X as the OS you want to use when you "Just want to go to Disneyland"?
he replied:
I embraced OS X as soon as it was available and have never looked back. So a lot of In the Beginning...was the Command Line is now obsolete. I keep meaning to update it, but if I'm honest with myself, I have to say this is unlikely.
> I embraced OS X as soon as it was available and have never looked back.
I used the original Mac OS from 1984-2000. I've used Windows since before 1995 until earlier this year. I've used Linux since 1998. I've used Mac OS X every once in awhile when using other folks' computers.
I honestly don't know why someone who's comfortable on the command line (and doesn't need certain proprietary desktop-publishing programs) would use Mac OS X (or Windows). It doesn't give me a decent window manager. It doesn't let me keep my hands on my keyboard (right now, my mouse is almost two feet from my hand, and yet I'm completely happy and able to get around as I need). It doesn't use screen space very well. It's not free. Where having the menubar atop the screen was a good design decision in 1984 with a monitor a few inches tall, it's a horrible choice on a modern large screen: I spend so much time moving the mouse that I spend very little time actually using the computer, rather than moving-and-reading. It certainly doesn't feel like a well-designed, well-integrated whole: it feels like a colossal heap of mystery meat navigation, where nothing is obvious or intuitive, things bounce and slide for no apparent reason and I can't just get my work done.
I get that for certain desktop publishing tasks it's superior, and that if one wants proprietary software then it's a friendlier alternative to Windows (which is the obvious best choice if one wants proprietary software support). But other than that, why pay extra for a Mac? A modern Linux has terminals, web browsers and editors; sound and graphics are not the pain they were in the 90s; what else does one need than a command line, a web browser, a decent editor and some music?
And people using IDEs sometimes use the command line even if they think they are not. Example: a team I trained to Ruby on Rails recently was using Ruby Mine, an IDE for Ruby. Nearly all the advanced stuff (rake this, rake that) involved looking for some menu entry and typing in the rake arguments. If they had an open terminal in the project directory they'd get those tasks done much quickly. Obviously they resisted the idea.
The exec system call in Unix has an argument named argv which is an array of strings. Each of these strings has traditionally been called a command-line argument. Also, when the user of a Unix shell hits the return key, a string or line of text is submitted to the shell for interpretation, and that string used to be called a command line.
For those writers who insist on using the term "command line" to mean avoiding pointing devices and doing everything through a terminal-emulation application, please tell me what term I should switch to to refer to the elements of argv or to refer to a string submitted to a Unix shell. I want a term that does not through endless repetition on HN and other forums leave the reader with the impression that the terminal-emulation app (or the Linux console) is my preferred interface to my computer.
Suppose for example that TextMate or Atom on OS X or Linux is my preferred programming environment and that from my preferred programming environment, I frequently run programs like grep, dict and ping -- with the output from those programs collected by and presented to the user by a TextMate or Atom extension. grep, dict and ping adhere to certain conventions, such as flags or switches that start with a hyphen, and the convention of writing ordinary output to a file descriptor named stdout while writing notifications of abnormal conditions to stderr. What term should I use to refer to those conventions?
The difference between a Command-Line Interface (argv-based) and a Textual User Interface (e.g. ncurses or fdisk-style interactive) is very important; the latter generally just means "a very bad but low-bandwidth GUI with no mouse support", but the former implies several attributes that allow for automation and programability: the course of interaction with a program (its command-line invocation) becomes an object trivially manipulable in its own right by users and programs.
We need to improve from the command-line by enabling even more expressive operations on programs invocations: programs should cooperate to enable perfect completion in a way that doesn't require writing custom completion scripts for every (shell, tool) combination, and they could describe their input and output formats to allow the shell to do "program search" in the space of command-lines. Given fairly rough user input, the shell can help guide the user to where they were trying to go with less work. Computers should be using some CPU time to actually help us figure out what we're trying to do, instead of everyone still hunting down syntax errors and reading man pages like it's the 1980's.
> What term should I use to refer to those conventions?
POSIX.
But note that using pure POSIX limits you because you don't get advantage of easy-to-use composability using pipes & substitution. It's a free world, of course.
Good answer to an excellent question. But I do not agree.
POSIX is the whole of a lot of utilities. Most of these utilities I never use, and there is a lot of utilities not part of POSIX that I would consider part of the "command line experience" (editor, tmux, some home grown tools, a REPL or debugger, ...), ssh, ...
Sometimes I refer to shell programs, or shell environments. This adapts to all that I actually use quite flexibly. Both to the tools, and with a special attention to the glue: the POSIX, Ba-, Da-, Z sh.
Interchageably, I also happen to use TTY (pronounced as Tee Tee Why ;) ), terminal, and Console .
I am not particularly happy with any of these, and also do not have a strong preference. I would like to be more consistent in my wording, so opiniated replies are most welcome :)
