The learning curve of vim was pretty steep, but once over the hump you get some massive benefits. That said, I bet I'm only using 1% of the available commands.
Going back to Windows makes you really appreciate the speed of bash, vim and grep.
I never liked cygwin much, though used it for a bit. For a long time I was a fan of portable ubuntu (http://sourceforge.net/projects/portableubuntu/) which allows you to run ubuntu as a service inside of windows. It was pretty good but it was still not the same as running linux natively or creating a VM that shares all the harddrives and you can ssh into by setting a static IP with your router.
There's a lot that does, though, and it's a huge set of functionality that windows doesn't provide natively. Even something as simple as:
ipconfig | grep IP
Not possible in windows. Then there's the rest of the userland tools unix people take for granted like rsync, screen, diff, tr, wget, etc. The standard shells and scripting languages all work. Plus I always set up an ssh server to run on localhost, so that I can use putty as my terminal rather than the windows' crummy cmd.exe.
Yes, ultimately it's still a windows box and cygwin's distribution definitely isn't on par with ubuntu or fedora. It's not going to be cutting edge and there will be difficulties integrating with hardware and the windows environment. It's generally not a good choice for running desktop apps or servers, and will probably require some extra work to set up a serious development environment.
But if you have other reasons to use windows (Outlook calendar, games, etc.), cygwin makes it a LOT more tolerable.
You don't need to give up vim and grep on windows. gVim works great and since vim has the built-in vimgrep command, you can use that. You do lose the awesomeness of a shell like bash or zsh.
I don't think these tips are that great. Some random criticisms:
ifconfig is deprecated (use "ip" instead).
There is not much value in knowing vim if you know Emacs. If you want to edit something in your terminal, well, emacsclient -t to your Emacs session. Or use mg, which is a very fast and light Emacs workalike -- just enough for editing your /etc/apt/sources.list to get Emacs installed :)
You don't think these tip are that great for you. But they're not written for Unix command-line ninjas. They're written for average users (like me) who run Ubuntu or some other flavor of Linux and just use the basic commands. I bookmarked the tips and will definitely be revisiting them regularly to improve my command line fu.
Sorry you didn't get anything out of it, but I suspect you don't need tips like "learn vim" and "be familiar with chown".
Functionally as a sysadmin, I've heard ifconfig is deprecated before yet I've never used ip. just 'ifconfig' on the command line tells me everything I need to know about what interfaces are up, their status and basic info.
'ip' just gives me the standard syntax description.
The power of the basic shell is that there's usually a few hundred ways to skin a cat. And just because there's documentation saying something is deprecated as often as not it's still so widely used that in practice, it's not.
ifconfig is deprecated, so probably a good idea to get out of that habit. Particularly if you are using it in scripts.
'ip addr' should give you all the information that 'ifconfig' does. You can also make the output a little less chatty by doing 'ip -o -4 addr' to get IPv4 addresses on one line per interface, or 'ip -o -0 addr' to get MAC addresses displayed similarly. This can make awking / cutting for addresses to use in scripts a little more elegant.
I didn't know about the one-per-line option, so thanks for that.
Commands I use regularly instead of using ifconfig:
# link up/down
ip link set dev eth0 up|down
# add a new address
ip addr add dev eth0 172.16.43.124/24
# to clear all IP addresses from eth0
ip addr flush dev eth0
# delete an address
ip addr del dev eth0 172.16.43.124/24
# add default route
ip route add default via 172.16.43.254
Why would I want to type more to accomplish the same task?
This is the same reason as to why I hated that Linux decided to have an ifconfig for physical interfaces, an iwconfig for wireless interfaces. It seems redundant...
Nothing, as long as it's working for you (your Linux distribution probably patched some of the remaining ifconfig problems themselves). You likely won't have a problem until you want to use network features that were implemented after 2001.
true, but that's how we've always done it where I work.
We use chroot to support multiple web apps with their own ip/domain on a single box. real simple to just add a new /etc/sysconfig/network-script/ifcfg-eth#:# with the proper network config. We can then ifup and ifdown them as necessary, they come up on boot if the config is set...
Wait, what? ifconfig is deprecated? Now I need to start typing ip on Linux , yet another variation from my BSD machines where ifconfig is definitely still in use, and Windows where I have to use ipconfig.
'ip' does a hell of a lot more than just list devices. It's really worth learning how to use it.
you also don't need root rights to use it for display - although ifconfig can be run as a regular user, it's not on the path by default so it usually won't show up.
ifconfig is on the PATH by default for FreeBSD, Mac OS X, and OpenSolaris... to me it was always rather irritating that wasn't the case in Linux when I needed to find out the IP address of a machine.
I really don't understand why there is a need to throw out a perfectly good tool to replace it with something that is completely different and requires re-learning, and re-writing of scripts that are already using ifconfig.
I think you still need to be comfortable with basic vi commands as it is _the_ standard editor in Unix. Many a times I've found myself in situations when I had to quick-edit a config file on a new bare-bones server with only vi installed.
As for the quick Emacs workalikes - they are exotic and you can't always be expected to know the packaging commands of the odd Unix system you happen to be working with. And sometimes installing new packages is not an option.
At first I thought you meant "use 'ipconfig' instead" and I was like, "Whaaaaat?!". Then I checked the man page for "ip". Thank you. It looks rather useful. I don't mess with routing or devices too much but I have in the past and only knew about ifconfig.
Deprecated by whom? Is there any source on this? Nothing is mentioned in the man page, and googling for it turns up a wikipedia article with a [citation needed], a reddit discussion from today linking to wikipedia, and this discussion.
Or use mg, which is a very fast and light Emacs workalike
There's also zile, another mini-emacs (great if you run Linux on small embedded computers.) I haven't used mg yet, so I don't know how they stack up against each other.
I do have a creeping feeling I should some day bite the bullet and learn more than 4 vi commands, though.
Basic vi knowledge may not be needed if you only work in Linux, but in my job I can work on Linux, AIX, Solaris, and HP-UX, and vi is the only editor that you can find on all of them in their base installs.
Why not? My servers have no passwords at all -- they either use SSH keys or kerberos.
Once you have access to a local shell, the game is over. Acquiring root is easy, between local exploits or simply piggybacking on (or sniffing) a valid, passworded sudo login.
Work on it how? Acquiring root locally is easy because local exploits are a dime a dozen, and once you have local access you can simply piggyback on valid authentication:
alias sudo="sudo and do something evil instead"
Once an attacker has local access, you've lost. It's a short leap from there to root. What's more, by requiring that users supply passwords to use sudo, you're practically guaranteeing that they will reuse passwords that thy use elsewhere, exposing your network to further compromise should those passwords be acquired from a compromised server.
do you know how many web/ISP hosting providers are out there that give out non-root SSH access to their customers? or how many do shared PHP hosting that make it easy to run local commands on the server? do you really think all of those servers have been rooted? here are two free shell providers:
do you know how many web/ISP hosting providers are out there that give out non-root SSH access to their customers? or how many do shared PHP hosting that make it easy to run local commands on the server?
Yes. In the late 90s, I worked in security for a company that ran one of the largest (at the time) shared hosting providers.
do you really think all of those servers have been rooted?
If someone was interested enough to capture an administrator's user account, then yes, they have been rooted.
if your operating system has no local user security, you should really upgrade it or switch to a different operating system.
There's no such thing. The local user attack surface is just too large.
As related to sudo, it's silly to think that local OS security can protect you from someone with access to an administrator's shell -- even if using sudo requires a password.
Let me break this down into simple steps:
Scenario 1:
- I acquire access to your password.
- I log in as you, then use your password to sudo to root. Game over.
Scenario 2:
- I acquire access to your SSH key or an active terminal on your server. I do not have your password.
- Logged in as you, I notice that sudo requires your password.
- Since you use zsh, I add the following to your zshrc:
sudo () { /usr/bin/sudo sh -c "echo \"pwned. Game over.\" && $==*" }
- You log in, and run some innocious sudo command. You enter your password, and then get a surprise:
nupark@fish:~> sudo ls /var/cores
Password:
pwned. Game over.
tar-3493.core
nupark@fish:~>
Under what scenario will the password requirement protect you? If the attacker can't take advantage of the situation immediately, they can just as easily leave a landmine that you won't notice until it's too late, if ever.
Once someone has a local shell -- especially an administrator's shell -- the machine is effectively compromised.
Requiring a password for sudo is at best a minor speed bump, not an obstacle, and it results in the propagation of password usage throughout your infrastructure. Many of those passwords, once acquired by an attacher, will likely grant access to other, possibly more critical systems.
"Learn what the number inside something like ls(1) or perror(3) means."
you got me there, I don't know what it means and now I'm curious and can't find it on google
I'm a big fan of ack, I love the --output feature, which is super handy. Unfortunately it is hardly ever installed when I need it. It's considerably slower than the highly tuned GNU regex code, which only really matters when you're grepping through a ton of material.
When first stumbling my way around the shell, after learning about tab completion I discovered the magic wizardry that is command reverse/history lookup (cntrl-r start typing command ... see last command you entered that matches)
The 'learn bash, it's available everywhere' really bit me when I moved from being a Linux Sysadmin to an AIX Sysadmin. Only ksh is available in this case. It took quite a few months to get used to.
Tell me about it. I've always worked with Linux, so was used to bash and its conveniences. Then I got a job where they use ancient Solaris systems with csh. Luckily, tcsh is generally installed which at least supports command line completion (after having to start it manually), otherwise I'd go mad.
Same thing happened to me a few years ago with Solaris and Irix. I used to use bash but the best shell available at work was tcsh. Now I have so much invested in tcsh that it is difficult to change back.
If you are halfway through typing a command but change your mind, hit Ctrl-A, add a # at the beginning to make it a comment, and press enter. You can then return to it later via command history.
A faster way would be to hit Alt-# (does the same thing with just one key combo).
It's great seeing all of these commands and shortcuts, and seeing that you know a lot of them. These never cease to be useful.
Even though it seems simple to someone who knows Linux, you can always impress marketing/business people by flying through Linux with these helpful commands, shortcuts, and tips.
You've got bigger issues if you've got marketing people looking over your shoulder while you're looking through grep's output. (And I doubt they care much about your Linux wizardry, that's why they're in marketing.)
Why? C-r and C-s already do each of these, and C-p and C-n are for going back and forward in history. (Personally, I use M-p and M-n so that bash in the terminal works like Emacs.)
One thing that's definitely missing from that list is the "undo" feature of bash which is bound to Ctrl-/ by default. It reverts the last edit you did on the command line. (The keybinding invokes the undo action also in emacs.)
I always found modal editing most valuable when editing and navigating through large bodies of text. I'm not quite sure that it makes sense on the command line, where you're rarely dealing with more than a few lines of text, and seldom need to rearrange those particular lines.
Nevertheless, I switched to zsh on Sunday, and with it, vi keybindings. It's getting better, but it still doesn't feel quite right.
I use vim almost pathologically, but I gave up on set -o vi. Since there's no visual indicator of which mode you're in, it's easy to make confusing mistakes and not the right feedback. It just wasn't worth it.
I use vi mode in my shell all the time, and love it. It only took a day or so to get used to it. But then again, I am a die-hard vim user.
What I'd really like, though, would be a vim mode for the shell, not just a vi mode. Then I could use some of vim's more advanced features, which would make the mode even more useful.
I can only speak for myself. Give it a day or two, and it will quickly become as transparent as your editing sessions. Once you cut over, you can forget about chording and arrow keys. Just one key: <Esc>.
I found myself using Emacs keybinding for line wise operation and movement in both vim and shell. It is just verbose to switch between editing modes sometimes.
Going back to Windows makes you really appreciate the speed of bash, vim and grep.