Miguel de Icaza: Learning Unix
tirania.org
tirania.org
Given that Perl's about as ubiquitous as bash (and arguably more so, since I literally don't know any mainstream *nix that ships without Perl in the core, and I know several that ship without bash), why not just use Perl in the first place? This is exactly what it was designed to do well, back in the beginning.
For longer-term scripts over a few lines, it's easier to use a powerful language you're comfortable with (maybe one of Perl, Python, Ruby) than to waste time (re)learning shell scripting whenever you need to extend the script.
On the other hand, Perl rarely changes. If you find yourself forced into a Perl 4 system you can still use the basics of Perl 5. IMO, if you have a relatively complex job to perform, Perl is going to be more reliable than Bash.
It seems like if you're concerned with portability, you shouldn't be writing a shell script in the first place.
Yes the tools behave differently on different systems, but 99.9% of the time there's very basic syntax that is respected across all versions of the tools. Stick to BSD4.4 C Shell syntax (http://docs.freebsd.org/44doc/usd/04.csh/paper.html), don't rely on regular expressions in grep, and stick to the very basics of sed and awk and you can go pretty far in Unix.
Any of the following commands which existed on some archaic version of Unix will still exist and their limited but useful functionality can be extended in lots of ways, and is pretty darn portable. https://secure.wikimedia.org/wikipedia/en/wiki/List_of_Unix_...
FreeBSD doesn't have Perl in the base system (but of course has it in the ports). Same with Bash though, but the Bourne shell is of course in the base.
— Tom Duff
(Minor remark: for smaller tasks [and instead of launching a terminal window] I prefer to use the DirOpus clone "worker" on UNIX.)
Then I picked up computers as a hobby. With all the random typing I did as part of the hobby I quickly found myself in the 70-100 WPM range.
You don't really need a typing tutor program with its learning modules and fluff. You just need to spend time typing. I recommend printing out a color-coded image[1] of a keyboard that shows which fingers to use for which keys and just spending a little time on http://typeracer.com every day trying to stay on home row and follow the color guide.
> Save yourself the embarrassment, and avoid posting on the comments section jwz's quote on regular expressions. You are not jwz.
"But unless you touch-type, you are neither awesome, nor you are in a position to judge the qualities of the world as an oyster or any James Cameron movies."
Thoroughly enjoyable read I must say.
Now, does doubling your typing speed also double your productivity? No, of course not, you spend time thinking, looking through code, reading specs, searching for solutions, compiling, etc. But I don't see how improving your typing speed would not result in at least some productivity gains.
That mean my vision is free to concentrate at the screen. That means that my short-term memory don't have to memorize what I am currently seeing at the screen. This means I have more precious short-term memory to do whatever important task I am doing, like, programming.
Subjectively, touch typing is surprisingly comfortable. So even if I'm completely wrong about the above, I still feel better, and that alone is worth the investment.
http://sites.google.com/site/steveyegge2/practicing-programm...
I don't think I should learn touch typing to further increase my typing speed. Right now most of the time my pondering over coding problems is limiting my typing speed, not my ability to move my fingers.
But maybe it's worth learning touch typing to reduce the stress on the fingers and be more egonomic?
Traditional touch typing trains you to hold your hands in a consistent position over the keyboard. It's the act of holding your hand in the same position all day--whether that's over a keyboard or around a mouse--that leads to carpal tunnel syndrome.
(For the record: I touch type mostly the way I was taught to. My wrists do occasionally bother me. I'm 24. YMMV.)
Coincidentally, I'm trying to learn real touch typing as I think it could help me in Vim.
Personally my style is very anti touch, using 2 fingers for the majority of letters, which I don't have to look at the keyboard for but I probably take more glances at it that a touch typist. I think though in being proficient in navigating the symbols on the keyboard mostly makes up for the loss in outright English typing speed.
However, if you catch yourself needing to even just glance at the keyboard while typing basic stuff, you're not a touch-typist, no matter how fast you are.
Many people feel that being fast is good enough. It has been my observation though, that the lag between typos and their fix is considerably shorter (almost instantaneous) for touch-typists (they're looking at the screen as it's happening). Indeed, I'm always a tiny bit annoyed when while sitting next to someone editing code, they accidentally turn on caps and it takes forever for them to realize it (like 10 characters later).
Unfortunately when I did so, it didn't have special lessons for the numeric keys; hope that changed.
The only gripe i had with it was that it required typing two spaces after a period. I found this just plain weird, so I fixed it in the tutorial files.
I guess using a blank keyboard also helped quite a bit..
Goes to show you don't really need to learn the whole process with some type tutor software. Though in terms of efficiency you may want to be aware of what they suggest. For instance, I think I was hitting the Y key with my left hand rather than right hand at some stage, but long ago changed that.
In fact, the only other memetically famous touch-typing software I know of is Typing Of The Dead¹, and that's not exactly widely-available.
The key to learning how to touch type is just typing _a lot_. You might not be very fast (I'm not), but you can at least get your eyes off your keyboard and use more than one finger per hand.
Absolutely. I don't think that typing-tutor software really does very much teaching at all, it's just a good tool for drilling yourself. But why not have fun in the process, rather than boring and mindless drills? I learned by playing the early Sierra adventure games, before they switched to the all-point and click interface.
Now I'm feeling all nostalgic...time to go download ScummVM.
Why frig around with emacs, pico, nano etc when vi is always there and is the same?
$ ls -l ./etc/alternatives/editor
lrwxrwxrwx 1 root root 9 Sep 7 06:19 ./etc/alternatives/editor -> /bin/nano
(OpenBSD ships with both nvi and mg, FWIW.)
Is emacs?
It seems to me that both religions are not 'standard' anymore. I tend to see pico, nano, joe etc. - occasionally vi (but not vim).
I knew a guy who actually did this - he worked for a company that maintained process control systems for "serious" customers (steel mills, nuclear power stations). One steel plant had some ancient mainframe controlling things and it originally booted from paper tape that had long since worn out in the eons since it was installed and been replaced with a sturdy leather belt.
He had to patch the boot code - so hence had to resort to a handdrill to drill some new holes in the leather belt.
Emacs used to be considered 'expensive' in terms of disk/memory. These days, it really isn't.
Non-Linux unixes are less and less of a factor these days, and even most of those have some sort of packaging system where installing emacs is a quick operation, rather than a laborious download/compile/install.
Emacs itself has remote editing capabilities with Tramp, via ssh that obviates the need to fire up an editor on the target machine in some cases.
If your job involves sitting down at HPUX/Irix/AIX/whatever machines that haven't been updated since 1998, and don't allow remote access, yes, vi is probably a valuable skill. Otherwise, I think this argument is less important than it once was.
That is enough justification, especially when you're at a single user mode console on a ILO card when the machine won't boot and flames are coming out of everything. Vi is there for you and emacs SSH won't be saving you when the network is not up so you cant apt-get or yum emacs. It's also not the sort of time you want to start having to learn vi.
I know this because I've been there.
It's as important as it always was, much as pen and paper are.
However, it's more likely that you will have some version of Vi. The one I'm thinking of is the Busybox version.
The thing is, though, the subset of vi you have to learn to is relatively small. You need to know how to enter and leave insert mode, how to delete, and how to quit with and without saving. (For a non-vi user, the difference between knowing and not knowing those simple things is significant)
This is generally enough to edit the few configuration files you may need to touch before you install emacs (network, sources.list, sudoers, etc).
So even though the use case is small and shrinking, the amount of "vi skill" you need is pretty low as well. There's really no good excuse to avoid it.
As a self-learner out in the wilderness, I don't know how I could have learned Linux without learning that basic Vi alongside. And that really is all you need to know.
though you wont find either on your fresh gentoo install
Any "Unixy" thing you have around these days will have more resources than most computes did in the mid 90s, and the need for a "lightweight" editor like vi is much, much smaller now than it was back then. Even my Buffalo router has nano.
For most Linux distros you install, you typically have nano, pico, joe, jedit or emacs or lots of other editors which (apart from emacs which is its own universe) largely follows the same conventions and at large gives transferable skills. These are IMO much more useful to know.
Why should I bother learning an archaic, non-standard editor from an era when "line-editors" were considered bloated? Why should it even be considered "relevant" today? Even more so, why should it be considered "essential"?
I really don't agree and I really don't see why vi-users insist everyone need to learn their favourite editor.
Arrgghhh!
man readline, and search (/) for inputrc.
ANY app that uses readline can be set to use vi OR emacs keystrokes and history, by setting an entry in .inputrc. If you use either editor regularly this will set your command line skills in lots of software all over the planet to warp speed.
If you write python command line programs, try "import readline."
Harumph!
Other cute things I have discovered lately: You can actually click in ncurses dialogs running in your terminal, even over SSH, if you run a proper terminal. Coming from a PuTTYish background, that is definitely not obvious ;)
esc v
esc gets you out of input mode, and v takes the current command line that you're editing and opens a full vi/vim session initialized with the command line. After you're done editing it, :wq quits vi and executes the command. If you change your mind, delete everything in the buffer and then :wq
This is handy if you're editing a biggish command, particularly one from recent history like a loop or anything with a block.
FTA: "If you learn to use Emacs, you will automatically learn the hotkeys and keybindings in hundreds of applications in Unix."
His point here is not to learn Emacs because it's a good editor, but because the keystrokes transfer to "hundreds of applications in Unix."
Which is true enough. In the (bash etc) shell you can change that to vi keystrokes with set -o vi, and you can change the behavior of those hundreds of applications (like mysql, e.g) by having a .inputrc file, but by default, lots of those apps use emacs keystrokes.
Use whatever editor you want, for whatever reason you want. His suggestion is worth considering, for the reason he states.
Without starting a flamewar, I'd like to point out Emacs is a good editor.
If you are a vim power user, finding yourself using traditional BSD vi is likely to be an unpleasant experience, making the vim is great because vi is installed everywhere weak as an argument.
“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.
I use VIM with only a few extensions (taglist, command-t and snipMate). I also use ctags and cscope, but support for those is built into vim. I really try not to get too dependent on extensions. They are more like convenience rather than something you don't know how to do without. Command+T for example is useful, but you still should know how to get to your files from the command line.
Famous last words ;-)
While I find myself using Emacs more that Vi/Vim these days, I still find Vi key-bindings useful in the less(1) pager, which I use extensively.
I've just discovered that less responds to Emacs movements, but for searching text I rely on the vi slash. Secondly, when navigating multiple files in less, the vi/vim "next/prev file/buffer" commands (n/p) apply.
ESC : q!
Because you never know when some commandline tool is going to drop you into vi (I teach them about the EDITOR variable, but sometimes you ssh somewhere and, you know...), and you need to know how to get out.
True story: the number one cause of issues with source code control systems is a vi session that the students accidentaly opened, managed to flee from with C-z, and didn't realize was still around with an open file holding the subversion lock and preventing them from committing their source code. I'd say I got 5-10 a quarter (~60 students in each quarter's session).
Our tech staff has a gForge installation that has LDAP configured and all the other goop, but only supports svn. Not managing accounts, password resets, and the inevitable extra map from student id jgordon to login SassySystemsHax0r is a big win.
Since it's their first time using SCC, I already have to deal with "but I just forgot to commit!" for the first two weeks. I'm a little worried that with a DVCS, I'd then also have to deal with "but I committed -- what do you mean I have to push, too? Well, can you grade against the local timestamp?" And that will happen all quarter...
lolwat?
downvote all you want. but a clone of norton commander was and always will be a joke.
...saw several sysadmins using it to delete files named with dash because they didn't know "--" is posix for stop taking flags. and that's just one bad vice it foments.
why?
P.S. - if you can answer without the elitist bullshit, people will probably stop down voting you.
The idea of MC never appealed to me so I admit I've never used it. When I see other people using it it seems awkward and slow, and the people using it never seem to know much about unix. Of course it could be that they just don't know the application well and it is in fact really fantastic. So my perception could be completely wrong.
the sysadmins in question used mc to delete weird named files just because they never bothered to learn correct argument passing in bash. they didn't know about quotes for filenames with spaces, they didn't know about '--' flag parsing termination argument. when their badly written script broke, they just manually fixed with mc and call it a day.
it's like seeing someone not using the scroll wheel to scroll. If you think that's elitist so be it. http://www.reddit.com/tb/df8cd