Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Art of Command Line

github.com

Post reply on HN
Print view View original

111–120 of 134 posts

Re: The Art of Command Line

#111

Post by Nemcue »

_jal wrote: post #25
jwcrux wrote: post #14

> Fluency on the command line is a skill that is in some ways archaic... I don't see this to be the case at all. Plus, having this be the opening line may cause people to equate archaic=I don't need this. I'd suggest (would pull request but afk) that you remove "is a skill that is in some ways archaic".

Agree. I've been hearing people saying the command line is archaic since Windows 95, and probably before that. Yet somehow I (any everyone I work with, and have worked with over the past 25 years) still works in a shell daily. I don't understand how someone on the technical end of running large internet services could avoid it. Sure, GUI tools have crept in here and there. And I understand that some toolchains mandat…

It's a fun experience trying to introduce command lines to people who have lived in IDE-land all their lives.

"Command Line?! HAHAHAH"

Re: The Art of Command Line

#112

Post by natch »

willthames wrote: post #102
anc84 wrote: post #98

Earlier quoted context omitted.

Just use Bash's builtin things: for n in {0001..0010}; do echo ${n}; done

Or seq -f %04g 1 10

Sure seq is OK, but jot does everything seq does and more, so I prefer jot.

# generate 10 random numbers between 1 and 1 million

jot -r 10 1 1000000

Re: The Art of Command Line

#114

Post by lloyd-christmas »

_jal wrote: post #25
jwcrux wrote: post #14

> Fluency on the command line is a skill that is in some ways archaic... I don't see this to be the case at all. Plus, having this be the opening line may cause people to equate archaic=I don't need this. I'd suggest (would pull request but afk) that you remove "is a skill that is in some ways archaic".

Agree. I've been hearing people saying the command line is archaic since Windows 95, and probably before that. Yet somehow I (any everyone I work with, and have worked with over the past 25 years) still works in a shell daily. I don't understand how someone on the technical end of running large internet services could avoid it. Sure, GUI tools have crept in here and there. And I understand that some toolchains mandat…

Comparing your first sentence and that of the author, you're missing what I see as the key word: "skill". I use command line everyday. Probably most developers do as well. But I definitely don't have "skill" in it. I think the point is that most developers can get by with nothing more than the basics (whatever "basics" are in the context of their work). The command line isn't archaic, but command line as a fluency might be.

Re: The Art of Command Line

#115

Post by hobarrera »

karmicthreat wrote: post #23

So this is tangentially related by why do people seem to push Vi? Nano is a perfectly serviceable editor. If I need to do extensive editing I always end up loading it into Atom, Sublime or some other editor anyway. I've never really had to use a console editor for more than 10s of lines.

> If I need to do extensive editing I always end up loading it into Atom, Sublime or some other editor anyway.

So you're saying "why would you use X, when you could avoid that by using Y"?

Well, because people prefer X, for a variety of reasons. Not to mention vi is installed everywhere, while sublime and atom are not.

Re: The Art of Command Line

#116

Post by hobarrera »

mediocrejoker wrote: post #58

> To locate a file by name in the current directory, find -iname something . (or similar). To find a file anywhere by name, use locate something (but bear in mind updatedb my not have indexed recently created files). I think this will glob unless you escape the asterisks. Also on my system (debian 8) I need to put the directory to search first, or not at all: find . -iname \ something\ find -iname \ something\ edit:…

This depends a lot on the terminal, and my advise is to always suround the glob with quotes:

    find . -iname "*file*"
zsh will cry that nothing matches the glob if you don't. bash will expand it if something matches, or pass it as-is to the client if something does - which will give you unexpected results.

Re: The Art of Command Line

#117

Post by hobarrera »

School-Cotton wrote: post #28
cbd1984 wrote: post #4

There's no reason to learn vi if you know Emacs. If you claim that Emacs isn't installed everywhere, guess what: Neither is vi. If you want an "installed everywhere" editor, learn ed. If you're willing to take an editor with you (or otherwise make sure a specific editor is everywhere you are), there's no reason it has to be vi.

I can't remember ever encountered a unix-like system without "vi" installed. I've used (and set up) machines running FreeBSD, DragonflyBSD, OSX, Ubuntu, Debian, RHEL, ... Plenty of those didn't have emacs, especially on first boot, when you're most likely to need to modify network configuration files in order to get online to install new packages in the first place... Edit: By "vi" I mean that somewhere in the path t…

Not on OpenBSD on rescue mode, or when booting from bsd.rd. Pretty sure the same applies to several others.

However, ed is available, and vi is closer to ed than emacs is. And emacs won't be available either.

Re: The Art of Command Line

#118

Post by hobarrera »

artursapek wrote: post #57
cbd1984 wrote: post #49

Earlier quoted context omitted.

> I can't remember ever encountered a unix-like system without "vi" installed. Default Ubuntu install.

Ubuntu 14.04, the default Ubuntu on EC2, definitely comes with vi.

It's actually vim symlinked as vi. Which had it's quirks back when I was used to vi instead of vim.

Re: The Art of Command Line

#119

Post by AdieuToLogic »

greggyb wrote: post #107
AdieuToLogic wrote: post #75

Earlier quoted context omitted.

In modern Bourne shell derivatives (Bash, ksh, some POSIX shells), the command: set -o emacs Will give command line editing bindings compatible with Emacs (which is also the default editing keys in MS-Windows and many IDE's BTW). HTH

Emacs bindings are not at all compatible with MS Windows.

You're right. I had misremembered thinking that the control keys often exposed in various GUI's were the same as the cmd ones. Which they are not:

http://ss64.com/nt/syntax-keyboard.html

Also, the original comment was on "console editors" and not on "command line editing", which is what I thought the subject was about. Looks like I struck out on the whole comment.

Re: The Art of Command Line

#120

Post by binarycrusader »

unhammer wrote: post #91
binarycrusader wrote: post #6

Earlier quoted context omitted.

I have to reiterate this; don't do it -- sort order changes and you'll run into other mysterious issues. It's not worth the "performance improvement".

There are good reasons to use LC_ALL=C for certain commands , especially if you want sorting that's stable across different systems. Sometimes you want "aa" to be before "b" even though the Norwegian UTF-8 locale puts it after "å" (which comes after "…zæø"): $ echo $'a\naa\nb\nå'| LC_ALL=C sort a aa b å $ echo $'a\naa\nb\nå'| LC_ALL=nn_NO.UTF-8 sort a b å aa Even worse, some characters that are byte-different collate…

I'm well aware of that, but in general, don't do it still applies :-)

In general, I'd never do it for performance only, it would have to involve one of the issues you've pointed out (there are some components I build that require it, erroneously IMO).

Post reply on HN