Slashdot Mirror
Common Traits of the Veteran Unix Admin
snydeq writes "Deep End's Paul Venezia offers a field guide to understanding your resident Unix veteran, laying out the nine traits common to this grizzled, hardcore set. From not using sudo, to wielding regular expressions like weapons, to generally assuming the problem resides with whomever is asking the question, each trait is key to 'spotting these rare, beautiful creatures in the wild,' Venezia writes. 'If some of these traits seem anti-social or difficult to understand from a lay perspective, that's because they are. Where others may see intractable, overly difficult methods, we see enlightenment, borne from years of learning, experience, and overall, logic.'"
Don't forget the neck beards.
The problem with veteran Unix admins is they never get first post.
vim? svelt? Puhleez. When not using ed(1), Real Unix vets use Bostic's One True vi, not some fagged-up Vegas showplace of an editor like vim.
wielding regular expressions like weapons
Reminds me of:
Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.
- Jamie Zawinski
Things you think are in the Constitution, but are not.
Lemme just email this to all my friends with the subject line "If you know someone like this pass it on LOL"
Real Unix admins would be reading this post in lynx.
This guy lost me with the first thing on the list. Going directly to root is great - if you're a noob in mom's basement. Nobody who has ever run systems in a serious environment mucks around as root as an alternative to something like sudo.
Guilty as charged to all nine counts...
We also throw a nickel at the rookie Windows sys admins and tell them, "Here's a nickel. Get a real operating system, kid."
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Butterflies - and no, emacs is not an option, unless you code the command yourself and store the code in your deepest vault.
Questions raise, answers kill. Raise questions to stay alive.
There's not a single mention about them scent marking their turf.
"National Security is the chief cause of national insecurity." - Celine's First Law
http://ozguru.mu.nu/Photos/2005-11-11--Dilbert_Unix.jpg
Someday we'll hit the human carrying capacity. And the band will just play on.
We will never (ever) admit we are at fault
If an off-by-one error results in the monthly report generation failing if the last day of the month falls on a saturday, then we'll quietly fix the code and tell the user this was a one-off problem most likely caused by incorrect user input but if it ever happens again to let you know
Bull fucking shit.
If you're familiar with the BOFH you know all you'll ever need to.
Have gnu, will travel.
Pretty much spot-on, I'm afraid. A little depressing to be described that accurately by a total stranger.
Unless unix veteran is a code word for idiot of course.
Take #9: "Our thinking here is there's no reason why a reboot should ever be necessary other than kernel or hardware changes, and a reboot is simply another temporary approach to fixing the problem.". When a run away program fills the disk or sets off the OOM killer then after fixing the problem itself rebooting is the obviously wise thing to do - who knows what random proceess got put in a bad state by the resource exhaustion best reboot and get everything into a known good state.
And of course have fun when the machine does need to be rebooted for a "kernel of hardware change" and some vital service doesn't restart because no one checked that the damn init script was enabled.
That was creepy to read. I'm guessing a few of you will understand what I mean.
You just prefix each command with "sudo". It becomes a reflex. You've essentially turned your regular account into a root account. You no longer really have a regular account.
That "#" prompt was invented for a reason: it provides a reminder. While you certainly could be oblivious to such a reminder, that is less a risk than always being one thinko away from doing root actions while feeling all safe and usery.
Better is a separate login window, keyboard, seat, font, color scheme, desktop, etc.
Lawn dwarves rulez the r00st!!1!1! http://dilbert.com/strips/comic/1995-06-24/
Long before you become "grizzled", you learn time. You learn calendars. You think in UTC. All the jobs happen on UTC. With the correct leap years plotted out for the next thousand years.
That's because you ran into that problem during your development and you learned it and kept your code.
http://www.jerkcity.com/jerkcity526.html
While I'm guilty of some of these things myself, this piece reads like a check-it-out-I'm-a-Unix-Guru. Somehow I don't see most vi-using folks looking down on those who prefer Emacs.
Eagles may soar, but weasels don't get sucked into jet engines.
The reason that Unix SAs don't like to reboot is deep seated in the history of Unix running decades ago on hardware for which a reboot cycle meant interrupting potentially dozens of people all sharing the same machine for a sequence that might take 10 to 20 minutes if nothing went wrong. Rebooting was correctly viewed as something to avoid whenever possible.
Windows was not engineered for long uptimes until NT 4.0 and is a johnny-come-lately OS in comparison. Windows didn't run on significant (read: capable of simultaneously supporting more than one user in a non-trivial way) hardware until, what, 1994 or 1995? Meanwhile Unix and its intellectual antecedents had been supporting multi-dozen-user installations for nearly three decades.
When there's only one user, rebooting isn't nearly as big a deal as when there are 20, 30 or more. That dichotomy alone drove the reliability of Unix, and the the lax attitude of Windows.
Personally, even though rebooting my desktop Linux computer with it's fast processor, SSD and RAID disks, takes well under a minute, I still don't like doing it. There's something wrong: It shouldn't need to be done. If I'm rebooting for a non-hardware related issue, it's because I'm being sloppy.
Put my fist through my alarm clock with its ding-dong death inside my ear. - The Blackjacks.
You've already ticked me off by wasting my time.
Link to the print version next time: http://www.infoworld.com/print/151276
I prefer my password. It's just a PITA that changes daily. alias s='sudo -i'
Same result as "su -" but with less typing.
Yes, root's password was set / changed. It's insanely long. I like it that way.
PS: this /. interface sucks now :wq
You're not a real unix admin unless you've written a compiler in awk or emacs in sed.
Support SETI@home
That's why generally only the sysadmin would have root. Other users that may need root once in a while (for whatever reason) are given specific sudo permissions. And if you are at a site that has multiple sysadmins who share responsibility for a group of servers, then auditing is simple. You ask the group "who did it". That's probably trait #10, deep integrity. Because a good sysadmin knows that if he is caught trying to hide a mistake, he will probably never regain the company's trust again.
http://www.theregister.co.uk/odds/bofh/
I am the unwilling control for my Origin.
The only admins I've seen that are allergic to rebooting are basically children who are new to a paying job. Most experienced Unix admins I've known have no problem with rebooting, when they feel it's the most appropriate option. They're pragmatic, above all else.
#DeleteChrome
best xkcd ever!
"Where others may see intractable, overly difficult methods, we see enlightenment, borne from years of learning, experience, and overall, logic."
Really? Rather than doing something a simple way, over the years veterans learn that complicated and difficult is better? K.I.S.S! There's even an acronym for it!
This sounds like it was written by a junior admin or programmer who's in awe of what some of the more seasoned vets are doing.
Sounds like tis group has a fair bit in common with your ornery curmudgeon.
What, they've built Angry Birds into emacs now?
That works fine until you have 30 sysadmins... because you have 1500 systems in your environment.
Really.. sudo su - is not appropriate in serious environments at scale that need to meet strong AAA and governance requirements.
vim? svelt? Puhleez. When not using ed(1), Real Unix vets use Bostic's One True vi, not some fagged-up Vegas showplace of an editor like vim.
That's like saying Real Unix vets still use telnet and rsh to remotely administer machines. Sometimes it's nice to be able to move up and down lines without having to leave edit/write mode. vim is used by Real Unix vets who have kept up with the times, just like ssh. Only washed up has-beens don't learn to eventually use better tools.
Damn programmers and their butterflies, the bane of a real sys admin.
Well, I'm glad /. has confirmation that 'veteran' unix admins are superior to all other users. What a pathetic group of people. I thought chefs were egotistical..
Keep on trippin'.
Sometimes, you can, you go to hell for the rest of your life! That's a true thing.
I have to go with the GP on this one. It's not that vim is inherently bad, it's just that it's *unnecessary*. It includes tons of features that an old-school admin has no use for. Sure, most of us use it anyway because modern Linux systems usually don't include our good friend vi (it's usually just a symlink to vim), but we rarely use the features that separate vim from vi. Moving in and out of edit mode is second nature. Hell, even using the arrow keys to move around is a needlessly inefficient waste of motion, since the arrow keys are usually far from any other useful key on the keyboard. The first thing we do in vim is turn off syntax highlighting and silently curse whoever keeps turning it back on.
The comparison to ssh is inaccurate as well. We use ssh because ssh gives us clear security advantages over telnet and rsh, and allows us to use one tool where we previously needed two. Any Unix admin worth his salt, no matter how long and luxurious his neck beard, will gladly upgrade his tools to improve his own efficiency or increase security. SSH does both of those things, while vim does neither.
When not using ed(1), Real Unix vets use Bostic's One True vi, not some fagged-up Vegas showplace of an editor like vim.
Indeed.
A particularly nasty vim change is that:
- In vi "u" undoes the last change - even if it was another "u". Hit "u" repeatedly and the screen flips between with and without the last change, making it blink. Useful if a multi-change command may have done something goofy.
- In vim "u" backs you through a history of changes. Handy sometimes. But to redo you have to "control-r". Forget about blinking the screen to use your eye's motion sensors to spot the trouble. Also watch out for accidentally undoing a bunch of changes just before you close and exit. Oops!
Geez, guys. If you want to add new stuff (like a history to go backward through), don't change the behavior of an existing command. Add another, or at least make it configurable - preferably with the default the old behavior.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
mmmmm colorized bash with as dash of dialog.
For example, I use virtual desktops. The first one is reserved for stuff involving root. On that desktop I open one xterm for root commands, and several others for related stuff such as checking man pages. I immediately make the non-root windows big, reducing the temptation to read man pages as root. For the root xterm, I do "exec su -" and keep it small.
I don't use any of those windows for random user stuff. (not even the non-root windows) I switch to a different desktop when I am not doing root-related actions.
If I were more serious about safety, I'd eliminate both sudo and su. It is unsafe to elevate privilege. The safe choice is a direct login, preferably on the bare non-X11 Linux console. (do Alt-Ctrl-F2 if you're unfamiliar with this) Hit the SAK sequence to be extra safe. An ssh login directly as root from a trusted client is a tolerable alternative, at least if you use pre-shared key information.
Seriously. Vi for quick and dirty. Emacs for longer and complex. Ksh/Perl for automated and repeatable...or if I have to do something more than, say, say five times... You get the picture. We keep many tools handy and polished. Each has a purpose. Other than that, the list is pretty accurate - speaking with 25+ years experience *as* one of those admins, as well as system/application programmer. :-)
It must have been something you assimilated. . . .
The trick is one never closes Emacs down - so it's always there. Just flick to the window with your Emacs, edit the file, save it, and go back to what you were doing. Those "editor AND the kitchen sink" jokes are very true, but you only have to open it once.
Even better, using TRAMP you can be running your Emacs as your normal user, and use the sudo method to edit a system config file - avoiding running the editor as root. Pretty nifty, eh?
I'm proud of myself - two holy wars (Vi/Emacs and su/sudo) in one post!
I run it as root, for weeks at a time. Who needs vi?
Oh yeah? Are they really gung ho to reboot a monstrosity with dozens of GB of RAM, many terabytes of disk, and dozens of virtual machines it it? Because it can easily take 15-30 minutes to get the shole shebang fully back up.
Malicious code could mess with your shell so that even "/bin/su -" doesn't do the right thing.
The proper solution is direct login as the desired user. If using SE Linux, also specify the correct role and MLS info at login.
Use the bare Linux console. If you absolutely must be remote, use a trusted client with pre-shared ssh keys or a hard-wired serial line.
That article is total bull! I, for example, am nothing like that and I admin Unix systems all the time. In fact, I'd say that article describes a bad, stuck with old crappy methods, Unix admin.
More like a thousand problems, if sed goes wrong.
Well, doesn't that make me feel inadequate. I like vim syntax highlighting. Makes config files easier to read. And I still use telnet, mainly for connecting to remote http and smtp servers. Great for troubleshooting issues, or even finding out what type/version a webserver is.
For sure, a REAL unix admin uses ex, not the VIsual editor. how are you going to edit the config file using vi if your only output is a line-printer - yes, i know, that does not happen often, but to me using ex at least one time saved me the effort of carrying the monitor into the next room to edit the config file to get the machine with the printer back online on the net.
sudo ed /dev/mem
(follow with a bit of editing to change the inode number of the working directory in your process structure)
You can use "sudo vi /dev/mem" or even "sudo gdb /dev/mem" if you're a wimp.
And the Dilbert perspective...
This space unintentionally left blank.
Why the hell didn't my link show up? http://i4.photobucket.com/albums/y129/Scarletdown/Dilbert-Unix.png
This space unintentionally left blank.
Except vim does increase your efficiency, which kinda goes against your terrible point. Get off your own lawn.
All the major changes are documented under ":help vi_diff.txt". You can set the undolevels option to 0 to get the vi behavior. Also see ":help undo-two-ways".
Awk, what's that you sed?
Siriusly, I gave up sysadmining when I realized bds unix (i.e., Apple) already done that for me, and all I had to worry about was how to fork Perl.
``Tension, apprehension & dissension have begun!'' - Duffy Wyg&, in Alfred Bester's _The Demolished Man_
but mainly a sudo bash ;)
1: We don't use sudo /' a server anyway and bring it back within a day or this points to a whole other problem, i.e. no backups, or no emergency restore plan.
True but we don't use 'su -' either like the article suggested. We use SSH keys to log in as root directly so we can run commands and scripts from a central server over hundreds of servers without having to log into them. Sudo is like training wheels. I should be able to 'rm -rf
2: We use vi, not emacs, and definitely not pico or nano
No we don't. We use 'joe' because we learned how to code C on Borland Turbo C and we like our Wordstar command keys. I never understood the use of a separate view/edit mode either anyway.
7: We have more in common with medical examiners than doctors
True, when we fix a problem, we do spend a bit of time on finding out _why_ it occurred, but most of our time, we'll spend DOCUMENTING! I can't believe the guy never even mentioned that word in his whole article.
9: Rebooting is almost never an option
Rebooting is _always_ an option. A veteran admin knows it is sometimes better to ask for forgiveness then it is to ask for permission. Also we're busy people, and I feel better when I know a server comes up again after a reboot after I made changes.
I feel the guy in the article is already a seasoned admin, but he's got some way to go before he's really a veteran.
Did you try this:
:set cpoptions+=u
And it even talks about your issue under ":help u". Including how to do the above.
Daniel Klugh
Not being a US citizen all I know about N*ggers is that only N*ggers can say N*ggers.
I have to go with the GP on this one. It's not that vim is inherently bad, it's just that it's *unnecessary*. [...]
I currently had to learn vi. Not vim, but the original vi. I had to do some work on some Solaris and AIX machines. vi was the only tool that was available on all of them. Most of them dad vim, some even emacs. But only vi was on all of them.
So I would say the reason to deal with vi instead of the better/newer editors is not so much that the other editors are not necessary. But the other editors might be unavailable.
I now try to use always vi, to practice its usage. The next time when no other editor is available, I will be prepared.
I still use telnet, mainly for connecting to remote http and smtp servers.
Telnet sends terminal management information included in the byte stream. Use netcat or socat if you just want to pipe stdin into a TCP session.
Geez, guys. If you want to add new stuff (like a history to go backward through), don't change the behavior of an existing command. Add another, or at least make it configurable - preferably with the default the old behavior.
I wholeheartedly second that!
It's a frustrating experience when you have to unlearn routine things like your example, at least is is for me.
Well said, IMHO.
Down With Slashdot BETA!!! I've been around the corner and seen the oliphant; you can only abuse me from your perspecti
...documented...
Your Szchwartz is almost as big as mine!
Having kept up with the times, if I have to read documentation I'm doing something I'm not supposed to do. If googling and three clicks doesn't bring me to an Ubuntu user who has already had my problem and solved it, I pipe the issue to my To-Do list, AKA. /dev/null. Meaning I just forget about it and go back to whining about lack of GPU accelerated flash video support.
Mouse-driven copy-paste is what it's all about. That's why nano.
All rites reversed 2010
You should really look into netcat to replace telnet for troubleshooting, it can do that and is a lot more flexible.
The way to corrupt a youth is to teach him to hold in higher value them who think alike than those who think differently
I would just add that customizing vim is a great idea. Because you'll never want to run vim on a new system you haven't extensively configured before... And besides, inconsistent behavior is just the spice pod life, you're sure to notice immediately, make no mistakes because of it, and just have a laugh about it later.
Seriously, nvi is awesome. Shows you the dos crlf breaks in your config file that are hosing up your server with a nonsense error message and no useful indications. Tiny, notably faster than vim, and much less nonsense popping up and showing you down.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
You didn't close the anchor tag. It's a bug.
Finally had enough. Come see us over at https://soylentnews.org/
This. I'm a hardcore emacs user - I wrote my own variant in TECO on a PDP-11 called "MINE" (unoriginally named after FINE - FINE Is Not Emacs) back around 1980, but I gave in and learned the basics of vi a few years back, simply because emacs isn't always available, and sometimes "echo whatever >> temp.sh" just won't cut it.
The should be bourne from years of learning.
SCNR
The first thing we do in vim is turn off syntax highlighting and silently curse whoever keeps turning it back on.
Why? I have seen this before, but never understood why anybody would prefer their C-code (or whatever) without syntax highlighting. Can you explain what is wrong with syntax highlighting?
And what about having 2 undo functions? u in classic style and ctrl+z for the young.
if I have to read documentation I'm doing something I'm not supposed to do.
Chances are, if you DON'T read documentation you're also doing something you're not supposed to do.
The only difference is that while you're reading, atleast you're not screwing up.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
The first thing we do in vim is turn off syntax highlighting and silently curse whoever keeps turning it back on
I second the other poster's WTF here. It's one thing not to rely on the advanced features of vim - after all, the Single UNIX Spec only mandates vi, so it's the only thing you can guarantee being available, but it seems crazy to not take advantage of them when they are available. Do you also turn of auto-indenting and multi-level undo so that you can spend more time typing and less time actually being productive?
I am TheRaven on Soylent News
As I recall, it does default to the vi behaviour. The newer stuff is only enabled with :set nocompatible. Of course, on most GNU/Linux distros, vi is a hard link to vim and both read the system vimrc, which sets this by default. If you use a real OS, vi and vim are separate binaries, vi behaves like vi and vim behaves like vim.
I am TheRaven on Soylent News
Here is how you do the "replace every third character unless it is followed by 4" using python: d = open('infile.txt', 'rb').read() d = ''.join(('R' if (idx % 3 == 0 and ch1 != '4') else ch) for (idx, (ch, ch1)) in enumerate(map(None, d, d[1:]))) open('outfile.txt', 'rb').write(d) I doubt you can write that as succintly using regexps. To bad slashdot fucked the code up.
Football Odds
While I'm sure some people use sudo to help keep them from doing stupid things in a root shell, that's really not the main purpose. There are a whole slew of legitimate things you can do with sudo that have nothing to do with protecting the system from typos/etc.
1. Allow multiple admins to each have their own "root" password -- no password sharing required.
2. Avoid setting a root password, so it's impossible to get direct root access via password-authenticated
3. Log every command run with elevated privileges for auditing purposes.
4. Prevent (or at least make it harder) for someone to leave a root shell unattended. sudo requires re-authentication on whatever interval you desire; a root shell has no such feature
5. Reduce the amount of typing related to run a single command with elevated privileges
6. Allow non-admin users (including non-root daemons) to run specific commands with elevated privileges -- for example, allow users to edit their own config files without admin assistance and without granting them access to all config files.
7. Allow certain commands to be run with elevated privileges without a password prompt based on group memebership/etc. For example, allow anyone in the "print_admin" group to run `killall -1 lpd` without further authentication. It's not a command you want anyone running willy-nilly, but it's not dangerous enough to require re-authentication of the session either.
And I'm sure there's a whole slew of other reasons to use sudo. That's not to say a root shell isn't still a useful tool in some scenarios -- if you're going to do a series of high-privilege tasks and you're not worried about strict audit trails a root shell makes sense. But you could still get there with a non-shared password if you used sudo for privilege elevation rather than `su`.
Rebooting destroys information. If you reboot for any petty reasons, you miss the truly important problems.
Here's a practical example: I have a server that had been running uninterruptedly since it was first installed, in August 2007. The air conditioning system at the site had been giving a lot of trouble recently, and everybody complained, but the upper management thought there was no reason to upgrade it.
Recently there was a long, several hours, failure of the AC and the server gave a temperature alarm and had to be rebooted. An event that happens once in three years is a *strong* message that something is seriously wrong. If I had rebooted the system frequently, the AC failure would have been business as usual.
Hey, *real* developers/sysadmins use *rocks*.
Aside: I find it brilliant that all the one-upsmanship can come from the exact same source.
You probably think you are kidding, but I personally loath vi and its evil, twisted spawn to the extent that I actually will use ed instead if ed is available.
What do I prefer to use for text editing? kwrite if the gui is available. jed if it isn't.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
While I'm sure some people use sudo to help keep them from doing stupid things in a root shell, that's really not the main purpose. There are a whole slew of legitimate things you can do with sudo that have nothing to do with protecting the system from typos/etc.
Alright, time to debunk this charlatan, who I strongly suspect of having once used Windows.
1. Allow multiple admins to each have their own "root" password -- no password sharing required.
There can be only one! If two admins ever exist, they must do battle until this natural state is restored. It is the way of the admin.
2. Avoid setting a root password, so it's impossible to get direct root access via password-authenticated
Anyone knows that you can simply disable the root password to be used as a login at all. What imposter is this that does not know this? This guy might not just use windows, he might even have a MS Phone!
3. Log every command run with elevated privileges for auditing purposes.
The other name, the hidden name for admin is root, root audits, no one audits root. Only a peer or superior can perform an audit and root will not meet a peer until his time on this earth has come to and end and he goes to the great server room in the ether.
4. Prevent (or at least make it harder) for someone to leave a root shell unattended. sudo requires re-authentication on whatever interval you desire; a root shell has no such feature
If anyone dares touch the machine of an admin, then he is no true admin. You do not protect the sacred contents of the temple with foolish traps but with sheer physical terror installed through decades of ritual abuse of your subjects.
5. Reduce the amount of typing related to run a single command with elevated privileges
I am root, my aliases are so powerful I merely have to glance at the keyboard to convey my will. Typing is for secretaries.
6. Allow non-admin users (including non-root daemons) to run specific commands with elevated privileges -- for example, allow users to edit their own
config files without admin assistance and without granting them access to all config files.
Users, with ROOT? BLASPHEMY! We must burn this heretic!
7. Allow certain commands to be run with elevated privileges without a password prompt based on group memebership/etc. For example, allow anyone in the "print_admin" group to run `killall -1 lpd` without further authentication. It's not a command you want anyone running willy-nilly, but it's not dangerous enough to require re-authentication of the session either.
Alright, that is it, GET HIM!
And I'm sure there's a whole slew of other reasons to use sudo. That's not to say a root shell isn't still a useful tool in some scenarios -- if you're going to do a series of high-privilege tasks and you're not worried about strict audit trails a root shell makes sense. But you could still get there with a non-shared password if you used sudo for privilege elevation rather than `su`.
Gosh, I would have thought putting him on a burning cross would shut him up. Alas, this poor MS drone has been so well indoctrinated his feeble mind can even in the last moments of life do nothing but spill his vile master lies. My the root have mercy on his soul.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
VI vs Emacs is an old and silly argument. This guy loses major points for essentially claiming that the only one true editor for "veteran UNIX admins" is VI.
I liked reading your reasoning on vim - especially the "Hell, even using the arrow keys to move around is a needlessly inefficient waste of motion, since the arrow keys are usually far from any other useful key on the keyboard," as that's exactly what i was thinking. Then I used 'j' and 'k' to try to scroll up and down accidentally ;)
How should I know if it works? That's what beta testers are for. I only coded it.
-- Attributed to Linus Torvalds, somewhere in a posting
A particularly nasty vim change is that
Indeed, i've been bitten by this a few times. Worse is: the redo will be seen as an edit, so all your undo's could be lost. I like finding an old piece of text by doing undo, yank, and redo, but the redo will break if you edit after undo of course. Perhaps vim is clever enough to store the whole tree of redo's/undo's - would be a great feature i guess - but I didn't look it up, just cursed vim that it ate my work, something that could have been avoided by doing the sensible thing: don't change such fundamental behaviour by default.
Between the VIM/VI/Emacs talk and SUDO/SU I charcoal where my asbestos undies used to be. The Perl vs. AWK/GREP/SED comment on the site made me feel like Wile E. Coyote after running over my own TNT trap.
~~ Behold the flying cow with a rail gun! ~~
The colors clash with my decor.
Meaning I just forget about it and go back to whining about lack of GPU accelerated flash video support.
But doesn't Flash 10.2 have it, even on LInux?
If you are using some incredibly fucking expensive commercial software that runs on clusters that is exactly what gets used by their cluster tools that should have been rewritten more than a decade ago.
Using ed was actually the sane and quick solution to reset the root password on a solaris 8 machine by using an install CD and a serial terminal.
The significant benefit of Sudo is you don't have to remember two passwords. 'Sudo bash' is fine; just one password to remember; or none if you config sudo right.
The biggest problem with Sudo is too many characters; you should alias it to "op"; then it clearly kicks su's ass.
vim? svelt? Puhleez. When not using ed(1), Real Unix vets use Bostic's One True vi, not some fagged-up Vegas showplace of an editor like vim.
That's like saying Real Unix vets still use telnet and rsh to remotely administer machines. Sometimes it's nice to be able to move up and down lines without having to leave edit/write mode. vim is used by Real Unix vets who have kept up with the times, just like ssh. Only washed up has-beens don't learn to eventually use better tools.
Honestly, I hate VIM. By default it has all these stupid colours that have no useful purpose. On RH-based systems I always remove the vim-enhanced package. I just want 'vi' when I type in the command 'vi'. If I wanted VIM I'd type in 'vim'. Making that the default is absolutely fucking stupid and just gets in my way--I find it as irritating as Clippy.
For writing code I generally use Emacs, but if I just want to edit nsswitch.conf or something then I don't need fucking colours and all these other useless gimmicks.
Ditto for all those stupid colours when i do 'ls'. I have no fucking idea what "blue" means or "magenta" or whatever. I know what having a '/' or '@' at the end of the file name means. Especially since my default terminal is white/grey text on a black background; blue text can't be read at all.
Honestly, Unix was designed to get out of the user's way as much as possible, and all these "features" just irritate the hell out of me.
With the greatest possible respect for whatever you do for a living and are most likely good at - you have no clue at all here and are just handing out dangerous and misleading advice based on TOTAL ignorance so go play in a different sandpit and leave the grownups alone. Rebooting with a full disk is a WISE thing to do? You've mixed up wise with incredibly fucking stupid. With a lot of systems that can give you a something that will not come back up after the reboot and I can tell you I've seen that as recently as last year and over a dozen times previously.
Also, the real "Unix Admin" who works in my shop better get used to using sudo. Only one guy in IA has the root password, the rest of us just have full sudo privs. From a pure security standpoint it's pointless of course, with "sudo su -" you can still become root (we often do) or mess with the audit trail (we don't), but the idea is just to keep a record of when we logged in and when we used root privs. It's a somewhat silly exercise that assumes we're all honest, but it rarely causes any issues and keeps IA happy.
I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
We're talking about admins, not programmers.
Give me Classic Slashdot or give me death!
I gotta wonder this too. I can see not *needing* it, I don't, but I don't turn it off either. When it's available it's helpful and I use it. When it's not I do without. I can't see how it ever hurts. If nothing else the huge blocks of pink "String colored" text tell me where I forgot to close that quote :-)
I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
Again, how are the colors "getting in your way"? Ignore them. Turn them off if you want (it's trivial), but even then I don't see why. It's not like they hurt anything, and if you could learn what the "/" and "@" mean you can just as easily learn what the four colors mean. It's not like it occupies a huge amount of cranial space. Most of these posts are starting to smack of "it's different, and therefore bad". Even if it'll save you a little time and effort int he long run, the 30 seconds to learn it is too much to be arsed with.
I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
So, add "set compatible" to your .vimrc and voila you have your vi behavior including undo that you like. I on the other hand prefer VIM's undo tree but then again, I'm a developer not an admin :D.
As the island of our knowledge grows, so does the shore of our ignorance.
That's actually not true. Redo does not purge your edits. VIM's undo is a tree and simply a new branch in the undo tree is created. Look at :h undo-branches
to see how you can get to another undo branch and how to see them all.
As the island of our knowledge grows, so does the shore of our ignorance.
Veteran *nix admins certainly do *know* vi -- after all, with a freshly installed system or a system that's not theirs, it may be all that's available -- but many do prefer emacs and use it regularly. Nice job of the article to throw religion into the mix, to give their own belief as if it was the One True Belief.
It is right about pico, however -- even if a masochistic admin did prefer it for some strange reason, they'd never admit it :)
ed? real sysadmins use cat & sed to edit!!
Vim has so many added features that it's become the Emacs of text editors.
is a damn idiot.
'vi' is learned because it's on EVERY system, while the others are not.
There's a saying about regular expressions "Once there was a man with a problem and he declared, 'I can solve this with regular expressions,' and now he has two problems." I see a lot of nasty ugly regular expressions when using awk to do exact matches off of columns GETS IT RIGHT. Unfortunately, even most "grizzled" sys admins can't gain the cognitive abilities of a bell labs patent clerk.
Actually the difference from vi to vim is huge
Having worked on an AIX installation that only had vi, 1st task was to get vim running
really, it's water to wine
how long until
Any Unix admin worth his salt, no matter how long and luxurious his neck beard, will gladly upgrade his tools to improve his own efficiency.
Which is why, as a seasoned UNIX admin, I remove all vi from my systems (to prevent broken programs that do not use $EDITOR or /etc/alternatives from dropping me into vi) and use emacs exclusively. Or jove on small systems.
C-X-( and M-x yank-rectangle improve my efficiency vastly for the one-off scenarios which it is not worth scripting.
Original article author apparently has never met seasoned admins of the emacs species. Specist! :-)
Someone had to do it.
Thanks for that. I've been aware of netcat, but haven't really bothered to look into it deeply, as telnet pretty much solves my remote troubleshooting needs, and it's quite ubiquitous, even available on the windows command line.
Still, I'm always up for learning a new command. I'll check it out more thoroughly, and see what it can do.
One feature I do not find unnecessary is ability to edit really big files. vi does not let you do this, vim does.
Yeah, I use vim, but with the -e option.
Why would you turn off syntax highlighting? I take it you don't write much code. Syntax highlighting is very helpful when writing perl, bash, or python scripts. Also, plain vanilla vi doesn't have code folding. If I write a function that's 30-40 lines long, and it works fine, I don't need to see it while I'm editing the rest of my script.
http://www.vim.org/scripts/script.php?script_id=1494
There's another trait that's missing here: Professionalism.
Real Veteran Unix Admins are true professionals who know how to function in a business environment without being arrogant or prickly. They are comfortable enough in their own skins and emotionally secure enough that they never need to engage in put-downs of others who don't rise to their level of technical acumen. They never play at being the high priests of the sanctum sanctorum of Unix administration which should not be desecrated by mere mortals. They are capable of doing their jobs without needing constant stroking by management or self-stroking by engaging in endless pissing contests and self-aggrandizement.
Unfortunately there is a small subset of Unix admins who are technically brilliant but emotionally insecure. They can do amazing things with systems but they are often difficult to integrate into a team or an organizational culture. They are high-maintenance employees, both blessing and curse to the companies they work for. With proper structure and coaching (and sometimes therapy) some of these can be developed to become true professionals. Some may be impervious to all efforts to help them mature and become more stable - they will have to be compartmentalized for the good of the organization or let go.
I will leave it to my gentle readers to decide which group the author of the article belongs in.
The great keepers of Unix lore are stirring from their hammocks, putting down their mai-tais, and shooing the mice out of their beards. This is what they have said to me.
When I log into my Xenix system with my 110 baud teletype, both vi
*and* Emacs are just too damn slow. They print useless messages like,
'C-h for help' and '"foo" File is read only'. So I use the editor
that doesn't waste my VALUABLE time.
Ed, man! !man ed
ED(1) UNIX Programmer's Manual ED(1)
NAME
ed - text editor
SYNOPSIS
ed [ - ] [ -x ] [ name ]
DESCRIPTION
Ed is the standard text editor.
---
Computer Scientists love ed, not just because it comes first
alphabetically, but because it's the standard. Everyone else loves ed
because it's ED!
"Ed is the standard text editor."
And ed doesn't waste space on my Timex Sinclair. Just look:
-rwxr-xr-x 1 root 24 Oct 29 1929 /bin/ed /usr/ucb/vi /usr/bin/emacs
-rwxr-xr-t 4 root 1310720 Jan 1 1970
-rwxr-xr-x 1 root 5.89824e37 Oct 22 1990
Of course, on the system *I* administrate, vi is symlinked to ed.
Emacs has been replaced by a shell script which 1) Generates a syslog
message at level LOG_EMERG; 2) reduces the user's disk quota by 100K;
and 3) RUNS ED!!!!!!
"Ed is the standard text editor."
Let's look at a typical novice's session with the mighty ed:
golem> ed
?
help
?
?
?
quit
?
exit
?
bye
?
hello?
?
eat flaming death
?
^C
?
^C
?
^D
?
---
Note the consistent user interface and error reportage. Ed is
generous enough to flag errors, yet prudent enough not to overwhelm
the novice with verbosity.
"Ed is the standard text editor."
Ed, the greatest WYGIWYG editor of all.
ED IS THE TRUE PATH TO NIRVANA! ED HAS BEEN THE CHOICE OF EDUCATED
AND IGNORANT ALIKE FOR CENTURIES! ED WILL NOT CORRUPT YOUR PRECIOUS
BODILY FLUIDS!! ED IS THE STANDARD TEXT EDITOR! ED MAKES THE SUN
SHINE AND THE BIRDS SING AND THE GRASS GREEN!!
When I use an editor, I don't want eight extra KILOBYTES of worthless
help screens and cursor positioning code! I just want an EDitor!!
Not a "viitor". Not a "emacsitor". Those aren't even WORDS!!!! ED!
ED! ED IS THE STANDARD!!!
TEXT EDITOR.
When IBM, in its ever-present omnipotence, needed to base their
"edlin" on a UNIX standard, did they mimic vi? No. Emacs? Surely
you jest. They chose the most karmic editor of all. The standard.
Ed is for those who can *remember* what they are working on. If you
are an idiot, you should use Emacs. If you are an Emacs, you should
not be vi. If you use ED, you are on THE PATH TO REDEMPTION. THE
SO-CALLED "VISUAL" EDITORS HAVE BEEN PLACED HERE BY ED TO TEMPT THE
FAITHLESS. DO NOT GIVE IN!!! THE MIGHTY ED HAS SPOKEN!!!
?
Is this a terrible, terrible joke? That's 186 characters. Comparatively:
sed -r -ie "s/(.{3})A/\1B/g" somefile
Or:
perl -pi.orig -e 's/(.{3})A/$1B/g' somefile
A trivial Perl script to wrap that if you want it programmatically is 98 characters, with proper spacing and no golfing at all.
Python:
python -c "import os,re;[open('outfile.txt','a').write(re.sub(r'(.{3})A', r'\1B', line)) for line in open('infile.txt','rb')]"
Yes, that's golfed a tad to make it convenient as a oneliner, but the "re.sub" bit is much, much shorter than your ridiculous map+join combination. Just because you don't know regular expressions doesn't mean they're not more efficient.
"The more corrupt a society, the more numerous are its laws." -Tacticus
Bollocks!
In the modern world, telnet and rsh are deficient tools for access. ssh is a _necessary_ modern tool, and is ubiquitous.
vim is neither a necessary replacement for vi, nor is it ubiquitous. A full install of Solaris doesn't have it included, so you have to add it by hand - to each machine you admin.
The nature of being a sysadmin is to be completely comfortable with the minimal tools available at 3am on a half-broken system. At one point that was sed, awk, and ed. vi and perl are both reasonable assumptions nowadays, but vim isn't. (and emacs never has been - it is and should always be an editor of programmers.)
Use vim all you want, but make sure you aren't dependent on multi-level undo or flashy colours if you're the guy they call in the middle of the night.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
Where others may see intractable, overly difficult methods, we see enlightenment, borne from years of learning, experience, and overall, logic.
^ That is not sane.
You know, our tools, and I mean the whole enchilada - OS and ISV unix software, they really really suck.
"UNIX|unix" OS software needs to GTFOOMW. The unix administration model has too much overhead for what the average person needs to do with it which is 9/10 times run some application in a little container of sorts without touching the dirty sides of the OS it sits in.
Flat files for configuration are fine, IF
YOU PICK A CONSISTENT FORMAT AND RUN WITH IT,
DOCUMENT IT,
DESIGN IT FOR SOMETHING OTHER THAN YOUR OWN PARSER TO UNDERSTAND.
Incidentally, if a Unix vet has sufficient grey hairs in his ample beard, he won't bother with that new-fangled vi(m) either, let alone emacs or pico. He will use the One True Editor. Emacs was originally built as a suite of macros for this, but I never really got to grips with emacs. The only drawback to TECO was the memory usage involved in remembering all those cryptic commands. However, it was, and is the most powerful and scriptable text (originally tape) editor ever created.
Back in the early '90s many of us were still using TECO (rebadged as "SPEED" on Data General mini/mainframes) for quick-and-dirty-but-so-fast-it-became-permanent batch processing of job control CLI files.
Whatever your choice is its subjective to the user - but saying hardcore unix cats don't use Emacs is insane - hmmmm RMS anyone??
OK, old-school admins use sudo in a multi-admin environment. It's not for security, it's for auditing, i.e. "All right, which one of us fucked up server ?" (Aside: Veteran admins take responsibility for their own mistakes.)
Some other signs of veteran unix admins:
0) We don't use command aliases. It galls me to no end that RedHat aliases mv, cp, and rm commands FOR ROOT! Babysitting routine activity isn't just annoying, it's dangerous! What happens when some Linux admin hops onto a Unix system and issues an "#rm lib*" command, expecting to be able to step through which libraries to delete? (and don't get me started on coloured output from ls on a black background. If you want it, YOU add it, don't make me remove it!)
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
Yeah, seriously. This article reads like a feature list for an old model vehicle you should put out to pasture, to boot:
Veteran Unix admin trait No. 1: We don't use sudo
Well why the hell not? You realize that it can significantly increase security and auditing by doing so, right?
If you're a one-man show, then shame on you for (likely) having a weak root password.
Veteran Unix admin trait No. 2: We use vi, not emacs, and definitely not pico or nano
And what's wrong with emacs? vi/vim regex are backwards.
Don't get me wrong - I use vi, and have for over a decade. But emacs is a bit more powerful and doesn't have as awkward a command set. For anything vim can do, something else can do it better simply because figuring out the arcania for vi is a bit difficult at times.
Veteran Unix admin trait No. 3: We wield regular expressions like weapons
Yes, yes they do. And they don't use a single goddamn comment, because "this stuff is easy".
Regex are awesome. I use them daily, but come back a week later? I'll have to figure them out again if there's a problem. A one-line (10+ character) regex should have multiple lines of comments. Just because it's only a couple lines and performs a lot does not mean you don't have to document it.
Veteran Unix admin trait No. 4: We're inherently lazy
Yes, yes they are. They're lazy to the point of incompetence: they don't document their work, and don't play well with others as a result.
Veteran Unix admin trait No. 5: We prefer elegant solutions
This goes back to the 'lazy' part.
Something isn't an elegant solution if it needs maintenance, pruning, etc. - who cares if you bashed out a crude perl script in a couple minutes for a single function and put it into production? Was it commented? Is it robust? Is it mentioned in system documentation? No? Then it's not a solution, it's a crude hack.
Veteran Unix admin trait No. 6: We generally assume the problem is with whomever is asking the question
This would actually be correct: the person asking the question should know better than to ask a self-centered, misanthropic, paranoid, backwards unix codger anything, because they're not going to a) get a complete answer or b) get a useful answer.
Veteran Unix admin trait No. 7: We have more in common with medical examiners than doctors
This is often/normally true, but it's true for those who have similar level of experience/skill yet adhere to good system administration practices as well. (WHy not hire them instead?)
Veteran Unix admin trait No. 8: We know more about Windows than we'll ever let on
Yes - except for the type of veteran unix admin who meets the first page of traits. They're myopic and think their precious systems are the end-all, be-all.
Veteran Unix admin trait No. 9: Rebooting is almost never an option
Correct. Forget those pesky kernel or base system upgrades for security, or routine reboots for maintenance, which are all considered generally good practices. We'll just leave the systems running until it's time to replace them, or let the next guy deal with a completely undocumented system that hasn't been rebooted in years. Surely, nothing bad will happen, and the employer is wise to keep such people in their employ. (This is where the 'forensic' abilities that good admins have come into play.)
If some of these traits seem antisocial or difficult to understand from a lay perspective, that's because they are. Where others may see intractable, overly difficult methods, we see enlightenment, born of years of learning, experience, and most of all, logic.
Most of these are difficult to understand from a 'business continuity' or 'connected to the Internet' perspective. What i
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
This article should be renamed common traits of the old guy who makes too much money, considers himself a priest beyond supervision, and should be downsized as quickly as possible.
I've been a sysadmin for 13 years, and I hate it when I run into these maladjusted weirdos in their 50s who think they're great but have let their skills (technical, business, and social) go.
and by the way, pico/nano is way better than vi or vim.
A real unix vet may use rsh because they've got kerberized rlogin.
WTF?? I'm not a unix admin, but I've tried - tried and tried - to use VI. I can't do it. It take too many keystrokes to do anything useful. I've got a 25 year old version of Emacs that I've kept alive and carried with me from job to job over the years, and it works like a charm. It's also small, VERY easy to customize, and very reliable. Also, I'm thoroughly familiar with it and don't have to think when I want to do something. I know, I know, VI users don't have to think about VI either. VI is a steaming dung heap. Emacs - my version, anyway - is sweet nectar of the gods!!!
The first thing we do in vim is turn off syntax highlighting and silently curse whoever keeps turning it back on.
You're just being dogmatic now. There is no reason to turn it off.
I was surprised a bit that Apple ships the Mac OS X with VIM installed. I had never even checked until I read this and sure enough there it is in all of its glory.
no comment
This is exactly why I chose to learn and use vi, and not emacs, or even vim. In fact my first unix editor was joe.
At 3AM with a system that I didn't install. A system that will just barely boot to single user mode. I damn well better be able to use the tools that are installed by default because installing something else will not be an option.
If I were God, wouldn't I protect my churches from acts of me?
Sure, most of us use it anyway because modern Linux systems usually don't include our good friend vi (it's usually just a symlink to vim)
RedHat systems have vi as a separate executable.
Vimium for chrome. I love using j/k to scroll. Accidently hitting 'd' to close a tab is kind of a pain sometimes, though.
I generally use j and k to scroll on slashdot. At least on the main page.
Where others may see intractable, overly difficult methods, we see enlightenment, borne from years of learning, experience, and overall, logic.
One sign of the veteran Unix admin: dealing with archaic absurdities will have driven them completely mad. You may see them referring to things like Xorg, init.d scripts, or anything else about Unix (besides how certain variants are licensed) as "Enlightened" or "Logical".
It's apparent from your rant that you aren't a good enough manager to be able to deal with people who know how to get the job done right the first time for all time.
I suspect you prefer to deal with the currently predominant types of admin:
I have the luck of currently dealing with admins for our datacenter who are a frightening mix of both. If they had just one "veteran Unix admin" who would spend a little more time and do the job right the first time, but not take weeks to do it, things would run a lot smoother.
And, I'm not kidding about the weeks or months to get anything done, as currently after full testing of changes to web pages (no matter how small), it takes 3 weeks before those changes roll out to the production system, as there need to be two meetings a week apart where the changes get signed off on twice. Meanwhile, these same bozos will patch production database servers without telling anyone. The problem is that their attitude is that the underlying system (OS, DB servers, web servers, etc.) is "theirs" and they make sure it is "correct" ASAP, without regard to the fact that applications need those resources to run. The sys admins don't care that the apps are what are important to the business process, but the "veteran Unix admin" understands that.
Administer? No. Debug? Yep! http://www.linuxplanet.com/linuxplanet/tutorials/7295/1/
I don't run vim if it's not part of the OS. I run /usr/bin/vi because it's part of the OS. On Linux it might be vim. On BSD it might be nvi, on Solaris it's vi.
Real Unix vets know how to use the tools that came with the OS and don't *have* to use extra stuff. But we'll use nmap if we have it. Or emacs.
FWIW, you can use echo * when ls isn't available.
"....to generally assuming the problem resides with whomever is asking the question...."
But.... In roughly sigma-two percentage points of situations, it IS a PEBKAC situation. Or, at least it is in the Unix/Linux world....
];)
Regards;
It's not that vim is inherently bad, it's just that it's *unnecessary*. It includes tons of features that an old-school admin has no use for. Sure, most of us use it anyway because modern Linux systems usually don't include our good friend vi (it's usually just a symlink to vim), but we rarely use the features that separate vim from vi.
Maybe I'm the odd one here, but on this Mac I'm using now, and also on the linux box on the desktop behind it, I have a number of terminal windows open in which I'm explicitly runnng vim and using those features.
The most important one is UTF-8 support, so I can sensibly edit text in a language other than English without it going all mojibake on me when I email it to someone or even try to print it. Thus, there's a window poking out behind this firefox window that's showing a mixture of English and Chinese text, displayed and edited easily by vim.
But I suppose a lot of those "old-school" admins would have the usual American/British organizational contempt for all languages other than English (plus maybe Fortran and Cobol ;-). But some of us are part of the new world of i18n that's been slowly creeping up on everyone. People who speak only English are now a distinct minority on the Internet. For the rest of us, tools like vim are quite useful.
Now if I could only get an xterm that handles Arabic and Hebrew sensibly ...
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
telnet pretty much solves my remote troubleshooting needs, and it's quite ubiquitous, even available on the windows command line.
Not by default any more. With Win7 you have to add it on using Programs and Features. Probably the same with Win2k8. In fact, I recently noticed that RHEL6 doesn't include telnet client in their list of default packages either.
Which is why, as a seasoned UNIX admin, I remove all vi from my systems (to prevent broken programs that do not use $EDITOR or /etc/alternatives from dropping me into vi) and use emacs exclusively. Or jove on small systems.
This is just stupid. Yes, not using $EDITOR is wrong, but removing vi is wronger. I love Emacs (and do all my coding in it) but vi is the single greatest editor for quick and dirty edits, and is what I use almost exclusively for admin related edits.
C-X-( and M-x yank-rectangle improve my efficiency vastly for the one-off scenarios which it is not worth scripting.
Original article author apparently has never met seasoned admins of the emacs species. Specist! :-)
Here I have to agree. From time to time I need to work on a rectangular region, and Emacs is just awesome there. It also has superior macro capabilities to vi (though vim has mostly caught up), which is quite often quicker and easier than writing some quick perl. You nailed two of the three times where I use emacs instead of vi for admin related tasks. The third time is when using Oracles sqlplus, which if run inside an Emacs shell you can get easy command history, plus treating the output of a select as a text buffer is super convenient.
Learn both editors, learn where they are strong and where they are weak, and use the right tool for the job.
I have to go with the GP on this one. It's not that vim is inherently bad, it's just that it's *unnecessary*. It includes tons of features that an old-school admin has no use for. Sure, most of us use it anyway because modern Linux systems usually don't include our good friend vi (it's usually just a symlink to vim), but we rarely use the features that separate vim from vi. Moving in and out of edit mode is second nature. Hell, even using the arrow keys to move around is a needlessly inefficient waste of motion, since the arrow keys are usually far from any other useful key on the keyboard. The first thing we do in vim is turn off syntax highlighting and silently curse whoever keeps turning it back on.
That's all you have to do to make vim very close to vanilla vi.
And if you're cursing the one who turned on syntax highlighting, why not edit your .vimrc and disable it?
Real Unix vets don't use something new-fangled like vi. It's either "ed" when they're lazy, or "cat > /unix" when someone is watching over their shoulder.
To get back on topic: veteran unix admins don't read docs either, but they sometimes write them.
Put some more years under your belt grasshopper and you to will fit the examples described.
Got Code?
Real unix admins use "op" instead of the inferior "sudo".
The first thing we do in vim is turn off syntax highlighting and silently curse whoever keeps turning it back on.
[snip]
Any Unix admin worth his salt, no matter how long and luxurious his neck beard, will gladly upgrade his tools to improve his own efficiency or increase security. SSH does both of those things, while vim does neither.
You've contradicted yourself there. Colourization is an extra channel of information that improves efficiency. Syntax highlighting is one use; vimdiff is another.
...Stu
Yes, vim. I love the way it highlights whatever code I'm writing. I even wrote a filter to add syntax highlight for my own configuration files when I program something new. So make no mistakes, vim is a very improved tool, and as I can use vi where vim is not to be found, I prefer myself the improved version over any other text editor in the world. Did you know there's a version for Windows too?
Thanks for trying, but that regexp is not even close to working: re.sub(r'(.{3})A', r'\1B', 'abcdefgh') => 'abcdefgh'. Try harder.
Football Odds
While perhaps true, since the thread is about old-school Unix admins, this comment is perfect for /.
And in the end, nvi is free as in the yeast to make your own beer while GNU vim is free as in the yeast that slut gave you.
betcha he ain't a 'unix vet'. sudo or su -c is always a better option than su.
need a reboot? fine but be sure to find out WHY you needed a reboot. 'to fix things' is not a good answer and ideally you should not have to reboot twice for the same reason. this isn't windows. unix systems are not supposed to shit themselves and if they do, you gotta find out why. that, in a nutshell, is what a unix vet does. that and shell scripting -- those crazy masochists.
nc is the more flexible, featureful
Socat has 80 different options for how to connect (stdio, TCP, raw IP packets, unix sockets, fifo files, UDP, openssl-wrappings, ...).
gzip < /dev/sdb | nc -l 33333; nc foohost 33333 | gunzip > /dev/sdb
I'd want to do that with some cryptographic authentication---that is, integrity. Whether I want to my disk keep secret or not is a different matter, but I sure as heck don't want my ISP (or just cosmic rays) corrupting my file system. Maybe ssh or stunnel is the right option here.
Real hard-core sysadmins don't use perl, they use sed, awk, grep, cut, etc.
Tiller's Rule: Never use a word in written form that you've only heard and never read. You will end up looking foolish.
prejudice
...there is no sig...
Not to mention that vim has a "vi-compatible" mode (that's enabled by default when invoked as vi and not overriden in the vimrc) that makes it act like vi for almost all intents and purposes.
All the major changes are documented under ":help vi_diff.txt".
You can set the undolevels option to 0 to get the vi behavior. Also see ":help undo-two-ways".
Of course you can. But you missed the point-- the cardinal rule is "leave existing behavior alone; make all new behavior an option that must be explicitly enabled."
It's the same with the bozo who decided that it'd be nifty to alias "vi=vim" in /etc/profile.d/vim.sh -- don't screw with my rhubarb!
I'd bet against you, but while I can write regexps and even enjoy it when I do it I don't enjoy writing one without proper purpose - and thus I won't try. However I do believe that this example is of the type that even if it's code wise smaller and clearer it's such simple thing to do without regular expressions and the solution for this made using substr calls, etc. instead of regexes would be much more memory and resource intensive - though it's unlikely that it would make any significant difference, such of that it would matter, unless some really bad programmer choosed wrong method in case where amounts of data, requirements for resource usage limits, etc. would clearly dictate that no matter what it's time to optimize this for *speed*, and while for some things, I would bet that for this one the regex solution would NOT be faster or consume less resources. However my point is not against or pro regex (though I am pro regEx) - I don't see a fight there and I think that everyone who does is stupid and a coder that can't comprehend that there are situations where regexes and others where non-regex solutions simply rock. One thing, btw, where it gives enormous powers is on command line, as there are numerous tools that are invoked from command line and use regexe's you enter for them to manipulate data - and given the different utilities and tasks you might want to do, without common system like regexps there would be either unrealistic amount of tools with very different weird ways for things or more likely there would not be so nice command tools available and for what you could do with couple one-liners and piping you would have to just do scripts for whatever comes to your mind... I mean, scripting when it's meaningful is different, but would you really want to do all those *nix hackers belowed data manipulations with stuff like that code of yours (except much more complex ones) on command line? No? Well, scripts it is then...