created Saturday, 2003-12-06 T 20:01:01Z
updated Friday, 2013-01-11 T 10:58:38Z
mkhomepg(or whatever it's called) command & give pointers to other articles about HTML & CGI.
bboard/GENERAL, so it's not a frivolous request. Hmmm...
This is for people who are new to unix, especially people who are new to unix & new to Super Dimension Fortress (SDF), a public access unix system.
I sometimes hang out in the chat rooms on SDF, & almost every day someone enters who has recently created an account & asks how to get started using unix & the features of SDF. It's an awkward situation because there is a lot to know to get started with unix; it would be difficult to explain it all in a chat room. What's more, most of the regulars in those chat rooms have seen & answered the question enough times that they understandably do not look forward to doing so again.
So I'm answering that question here, once. If all goes well, when someone enters a chat room & asks how to start learning about unix, someone can point them to this article.
If you already know what unix is, or if you don't but you also don't enjoy reading about petty controversies about a definition, skip the ``What is Unix'' chapter & start reading the Some Basic Commands chapter.
What is unix? That's a loaded question.
The short answer is ``Unix is an operating system''. So is Gnu/Linux, which is often just called Linux. So are HP/UX, AIX, NeXT STEP (now called Apple Macintosh OS 10), & Microthought Winders (often called many uncomplimentary things).
If this short answer is enough for you, congratulations on knowing the value of keeping things simple. Now skip ahead to the Some Basic Commands chapter.
The long answer is ``It depends on who you ask''.
In my opinion, unix is a description of the function of an operating system. I even say that unix is an Application Programmer's Interface (API). Any operating system which implements the unix API is a unix; it's an implementation of unix. Gnu/Linux is a unix.1 Gnu/Linux is often called Linux, but strictly speaking, Linux is a unix kernel, but not a whole unix operating system. There are many other implementations of unix. I can name original BSD, OpenBSD, FreeBSD, NetBSD, HP/UX, AIX, Minix, Apple Macintosh OS 10, NeXT STEP, QNX, & Lynx. There are probably others.
Now for some legal bullshit. ``UNIX'' is a trademark of The Open Group. From what I can infer from their web site about their opinions of what unix is, they would agree with me that it's a description of the function of a family of operating systems, but they would also add ``that we have certified to be UNIX''. So legally, it's not a UNIX unless The Open Group certifies it as a UNIX. So a lot of those operating systems I listed as unices are not UNIXes. It's a thoroughly sad case of legalities getting in the way of simplicity & sanity.
Anyway, I say that if an operating system behaves like unix, then it's a unix, though not necessarily a UNIX™.
Another opinion, which I don't share, is that Unix is a particular product. HP/UX is another. AIX is another. Gnu/Linux is another. You get the idea.
Fine, except that there is no product simply called ``Unix'' for sale today. You can't even point at a product that is the direct descendant of the original Unix that Ritchie & Thompson wrote at AT&T. Their Unix was the definitive Unix, the original, the one named Unix. You can't buy it today, methinks. And many of those that you can obtain today shared code with the original Unix. BSD is Unix as modified by students at the University of California in Berkeley. That's where sockets were invented. BSD branched into many implementations, several of which are alive & well today. Theoretically, each of those implementations has at least some of the original Unix code in them. Yet somehow BSD isn't a unix? Get real. I'm sure there are similar examples of cross-pollination between the other unix operating systems available today.
Another problem with the claim that BSD, Gnu/Linux, & the others are not unix is that it takes little effort to write a program that runs on all of them. There are enough differences that a non-trivial program requires a little care to be portable, but it's not like portability concerns affect the architecture of your program. All in all, it is easy to port code between HP/UX, AIX, Gnu/Linux, & the BSDs. This isn't an accident. Those products are implementations of a single idea of what an operating system should be. That idea needs a name so that when you ask me what kind of operating system I program for a living, I don't have to reply with ``I'm an HP/UX, Gnu/Linux, AIX, FreeBSD, NetBSD, OpenBSD, QNX, & others programmer''. I say the name for that concept is ``unix''. If not, then it's POSIX, but POSIX is also a trademarked term with a certification schedule from The Open Group (together with IEEE).
So somewhat out of contempt for our legal system's petty concerns for terminology, I say it's all ``unix''. There you have it, in more detail & controversy than anyone with a sense of perspective would ever want.
When you login to a unix system, you'll be on a command
line. It'll have a prompt like ``
bash-2.04\$ '' or maybe ``
\%''. There are other
The command line is how you communicate with the shell. The shell is a program that reads commands from a command line & runs other programs. It does some other things, but they are mostly details. The main point of a shell is to run programs.
The traditional, original shell on unix is called the Bourne shell. If you're wondering why it's called the Bourne shell, ask yourself who might have written it.
The Bourne shell program is named
/bin/sh, but that
program on most modern unices is actually a pointer to the
Korn shell or the Born Again shell. Those two shells are
more modern than the Bourne shell, but they are backward
compatible with it.
There are other shells, including C shell (
& the restricted shell. You can change your shell on many
unices with the
chsh\ command. Since a shell is just a program,
no magic behind it, you can use damned near any program you
want as your shell. You could use Perl as your shell, I've
used clisp as a shell (just for an experiment), or you could
write your own shell.
The important thing about a shell is that most of the things
you type to it are interpreted as requests to run a
program. If you type ``
ls'', you're asking your shell
to run a program called ls. If you type ``
-k lap -f lap woo woo -d hickie'', you're asking it to run
a program called bogie with all that other crap as
command line arguments.
Enough about shells for now.
On unix, the ls program gives you lists of files.
If you just type ``
ls'', you'll get a list of the
files in the current directory. Like this:
bash-2.04$ ls #unx.tex# RCS unx.aux unx.bbl unx.blg unx.log unx.tex unx.tex~ unx.toc bash-2.04$
Notice that ls, when used in this plain way, doesn't show you files sizes or permissions or anything like that. Unix is traditionally tery terse. Programs show you only the information you requested, plus error messages. You don't have progress messages like ``2003-12-06T16:16 beginning to read files'' and ``2003-12-06T16:17 reading first file'' and other nonsense cluttering your screen. The programs just print what's important.
If you want ls to print the details about the files,
give it the ``
-l'' option. That's a minus sign
-) followed by a letter el (
l). Like this:
bash-2.04$ ls -l total 52 -rw-r----- 1 gene gene 9181 Dec 6 16:18 #unx.tex# drwxrwx--- 2 gene gene 4096 Dec 6 14:03 RCS -rw-rw---- 1 gene gene 1390 Dec 6 14:47 unx.aux -rw-rw---- 1 gene gene 49 Dec 6 14:47 unx.bbl -rw-rw---- 1 gene gene 878 Dec 6 14:47 unx.blg -rw-rw---- 1 gene gene 4201 Dec 6 14:47 unx.log -rw-r----- 1 gene gene 6387 Dec 6 14:47 unx.tex -rw-rw---- 1 gene gene 1212 Dec 6 13:49 unx.tex~ -rw-rw---- 1 gene gene 658 Dec 6 14:47 unx.toc bash-2.04$
The first column, which has all those minus signs, rs, & ws, shows the file permissions. The next column is the number of links to the file. The next column is the user who owns the file. The next is the group of the file. Then there's the number of bytes in the file. Then the date the file was modified. Then the file's name.
Here's an exercise: Type ``
echo *'' on the command
line, like this:
bash-2.04$ echo * #unx.tex# RCS unx.aux unx.bbl unx.blg unx.log unx.tex unx.tex~ unx.toc bash-2.04$
Now go figure out why or how echo differs from ls.
All unix systems have a file system whose root directory is
/. Your home directory is somewhere inside a
directory in the file system. Maybe your home directory is
/usr/hm0/you or whatever. The
details depend on the unix. To learn your home directory,
echo \$HOME'', like this:
bash-2.04$ echo $HOME /home/gene bash-2.04$
Unix has a notion of a current working directory. To
see what your current working directory is, type
pwd'', like this:
bash-2.04$ pwd /home/gene/library/website/docsrc/unx bash-2.04$
To change your current working directory, use the cd
command. Give it the name of the new directory you want.
If you want to move to the current working directory's
parent, use ``
..''. Here are some examples:
bash-2.04$ pwd /home/gene/library/website/docsrc/unx bash-2.04$ cd .. # move to parent bash-2.04$ pwd /home/gene/library/website/docsrc bash-2.04$ cd .. # move to parent again bash-2.04$ pwd /home/gene/library/website bash-2.04$ cd share # move into the "share" directory bash-2.04$ pwd /home/gene/library/website/share bash-2.04$ cd /tmp # move to this absolute directory bash-2.04$ pwd /tmp bash-2.04$
vi is an editor, but its cursor-movement commands are often used by other programs. The next table shows vi's cursor-movement commands.
|h||move cursor left|
|j||move cursor down|
|k||move cursor up|
|l||move cursor right|
The vi commands might not make much sense at first, but notice that you can use all of them with the fingers from the right hand. They may not be the most mnemonic commands, but they are very functional.
The hjkl commands are to the unix world like the wasd are to the PC gaming world. Some programs besides vi which use the vi cursor-movement commands include:
mutt mail reader, but just the j & k keys in its menus
/usr/games/worm, an old game & an excellent way to learn the vi commands
Most unix systems give you multiple options for how to read your e-mail.
If you want to read your e-mail with a text-only program you run from the command line (which is how I read e-mail), some common programs are mutt and pine. Just type the name of either of those programs. If you see a list of e-mail, it means the program is available, & you are running it. If you see an error message that says ``command not found'', it means your shell couldn't find it, maybe because it's not available on your unix.
You can figure out the basics of mutt or pine just by using them. People become almost religiously devoted to their favorite e-mail programs, so you can learn more detailed or subtle ways of using a mail program by asking someone who prefers that program. People are usually happy to tell you more than you want to know about how to use their favorite e-mail program. So pick one of them, figure out the basics on your own, & then go find a long-time user of that program & strike up a conversation about it with him.
I've never used pine, so I can't tell you how. I sometimes use mutt, so here is some super-quick info on using mutt.
The official documentation about mutt is at FTP
To transfer files between your home computer & a remote unix, use the program called ftp. Your home computer almost certainly has a copy, even if you run Microthought Winders at home.
To run ftp, first go to a command line. Then type
ftp ftp.freeshell.org'' to connect to the FTP server
The ftp client has a command line interface. Here are some of the commands it understands:
In general, use the cd command to enter the correct directory on the remote FTP server. Then set the correct mode (ascii or binary). Then use get to download a file or put to upload one.
The ftp client program supports many more commands.
man ftp'' for more information about FTP.
In case you are interested: FTP refers to the File Transfer Protocol; it was one of the three requirements that created the Arpa Net which became the Internet. Ftp is also the name of the File Transfer Program which implements FTP.
scp is the Secure Shell Copy Program. It's name is also a reference to rcp, the Remote Copy Program.
Use scp like you would use cp, but it can copy from one computer to another.
For example, if I want to copy
myfile.cpio.bz2 on my
computer into the
tmp directory in my account on SDF,
I would run this: ``
email@example.com:tmp/''. The scp program will
probably prompt me for my password, then it will copy the
man scp'' to get more information about using
In my experience, scp takes longer than ftp to transfer files, & it gives up easily. If either computer or the network is slow, scp gives up quickly. So I prefer ftp.
Ed Chang has told me that there is an implementation of scp for Microthought Winders called WinSCP, at winscp.sourceforge.net/eng/about.php. I haven't tried it myself, but it sounds like it might be pretty good.
You can't use rcp on SDF, so this section applies when copying files between other unix systems.
An old but pretty cool program for copying files between two unices is rcp, the Remote Copy Program.
For rcp to work, you must first configure the
files in your accounts on the unix systems. Then
you can copy files from one system to another with the
For example, if I want to copy
myfile.cpio.bz2 on the
computer into the
tmp directory in my account on a
I would run this: ``
overthere:tmp/''. The rcp program will
copy the file; it won't ask me for my password.
If you don't have FTP on your home computer, you can transfer files via e-mail.
First, make sure you have an e-mail account that allows you to send files as attachments. You might use the e-mail account that your ISP supplied with your Internet connection, or you might create a Web e-mail account on Yahoo!, Hotmail, or any of the many other systems that provide free Web e-mail accounts.
To transfer a file from your home computer to SDF, you create an e-mail message on your e-mail account that is not on SDF. Attach the file; with a Web e-mail account, it'll allow you to upload the file into the e-ail message. Then send the message. Give it a minute to arrive, then login to your account on SDF. Receive the message with an e-mail program which knows how to deal with attached files. Mutt & pine both know about attachments. Use that e-mail program to save the attachment to a file.
To transfer a file from SDF to your home computer through e-mail, login to SDF & send the file to your non-SDF account as an attachment to an e-mail message. Then receive the message on your non-SDF e-mail account & save the file to your home computer's file system.
There are two great religions in the modern world: emacs and vi.
The two most popular file editors on unix are emacs and vi.
Emacs is more properly called Gnu Emacs because emacs
is a way of programming file editors, & Gnu Emacs is just
one editor written in that way. I believe Gnu Emacs was the
first big production product of Gnu. Richard Stallman wrote
it himself. It is a Lisp with screen-handling functions
built-in. It's a great big powerful editor, an operating
environment, & I love it. To try emacs, type
wait for the screen to update, then type the
Escape key, the
x key, then ``
info'', then press
Return. Carefully read & follow the instructions you see
on the screen. It's kind of difficult to learn emacs from
the start, but once you do, it's great.
The other popular editor on unix is vi. I don't use vi much. Some web sites that discuss it are
Most of a unix system is documented in the online manual,
called the man. If you want to know about a program,
you look it up in the man. For example, if you want
to learn more about the ls program, type ``
The man also has a simple search capability. The
command line option tells the man to give you a list
of entries that mention a particular keyword, which you also
supply on the command line. If you want to
get a list of the manual entries that menion networking, you
would type ``
man -k network''.
The man is divided into sections. If you don't specify a
section when you ask the man to lookup documentation for a
program, the man takes a guess about what section you mean,
& it usually assumes you mean the most general, high-level
section available (section 1). You can specify a section as
the second argument to man, before the keyword. For
example, if I want to read about the
in section 2 (the kernel API), I would type ``
Here are some things I recommend reading in the man to get started with unix. I give you the exact command to type, then an explanation of why I recommend that entry in the man.
man 2 intro'' & all the other intros for sections 3 through 9.
I tell newbies about the man all the time, but they usually don't try it.
I don't know why they don't believe me. I started
using unix in college in 1985. In a class, the professor
gave everyone an account & told us to login after class &
man man''. He didn't tell us anything else,
not even what ``man man'' would do. By exploring the manual
on my own time for a couple of evenings, plus a couple of
conversations with the unix gurus that worked in the lab, I
was pretty good with unix. It was an excellent way to start
using & programming unix.
Maybe the newbies do believe me, but they're lazy.
Besides the unix man, Gnu/Linux computers usually have some information in a hypertext system call info.
To use info from the command line, just type
If you are a Gnu Emacs user, you can run emacs &
info, & you'll be presented with the same
data in the same format that info would.
Info is an interactive hypertext system. It predates the Web by at least five years, methinks. Read & follow the instructions on the screen & you'll be alright.
Info systems are not always maintained as well as the man, but most are pretty good, & some have a lot of excellent information. It is often well-written, too. It's an enjoyable read, & since you can page through the entire system one screen-full at a time by typing the Space bar, it's convenient to read.
Though it's not for beginning users, I'll mention here that one of my favorite sections in info is the documentation for Autoconf.
I can't recommend any books on using unix. I learned it so long ago that I don't remember what books I used, or even if I used any books. Here are some interesting books about unix, though not exactly about using unix.
I like Mike~Gancarz's book, The Unix Philosophy, a lot. It talks about the reasons behind writing applications the unix way: with small programs piped together, & with flat, plain text data files. Eric Raymond's book, The Art of UNIX Programming, is similar & excellent.
Even though we're talking about using unix, I think an understanding of how operating systems work is useful to know, & Andrew S. Tanenbaum's Modern Operating Systems is an excellent book. It includes a good section about unix. He points out that the defining characteristic about early unix was its 40 system calls. We've added more system calls, but the unix kernel still has a fairly small number of elegant, well-chosen system calls. That's an important part of what makes unix what it is.
One of the cool things about unix is that it has played an intimate part in the folklore of computing since the late 1970s. There are all sorts of interesting tales & personalities to explain or help you remember why something was done a particular way. The history is not hidden inside a corporation. It's out in the open, & lots of people know it.
That's also one of the bad things about unix because it means you need to talk to people to learn what you need to learn next. Hopefully people will write downt he folklore & also link to it so that new unix users & programmers can find it.
You can learn the folklore by talking (or typing) to an experienced unix user or programmer. A good place to read about it online is The Jargon File.
Here is some quick reference information about using Super Dimension Fortress (SDF). I'm not a member of SDF's staff, so the information here is not definitive. If you find a discrepancy between what I say & how things actually work on SDF, it's an error in what I've said, not in how SDF behaves.
Use the faq or help commands to get information about SDF. These are not standard unix programs. They are specific to SDF.
The help command mostly gives you lists of other
commands. If you type ``
help'', you'll see a menu
SDF Help System - v8, 1993 - sdf!smj [a] Directory and File Utilities [b] Email Information [c] USENET Information [d] User and Process Information [e] Tutorials and Very Useful Commands [f] ARPA Services (internetworking) [g] Homepage, VHOST and MetaARPA Utilities [q] Quit SDF Help System Your Choice? For more help, type 'faq' For a list of basic UNIX commands, type 'unix' to remove your account, type 'delme'
Most of the letters in the menu will give you lists of
commands. After you quit the help program with
q'', you could run the commands or read more about
them in the online manual I discussed earlier.
Some of the programs are specific to SDF & are not
discussed in the man. SDF's excellent com program is
an example of a program that is not discussed in the man.
To me, the faq program is more useful. In it, you can find short explanations of unix file permissions, uploading & downloading, SDF's policies, & the history of SDF.
To enter the faq, type
faq'' on the command line, & the
you a list of sections. This is faq's main menu. You can
exit by typing ``
q'' here. If you type ``
g'', it will
ask you for the name of a section. You enter a section
name & press return, & you'll see the section's menu.
In a section's menu, you have a numbered list of questions
or topics. If you type ``
g'', & press return, you'll see
main menu again. If you type ``
t'', you'll be prompted for
the number of a question or topic. Type that & press
return. You should type the number exactly as it appears in
the menu, including leading zeros.
Some things you can learn from the faq include:
SDF has its own chat system, called
com. It's like a
stripped-down IRC, but much cooler than IRC because people
actually talk, & you don't get unwanted pop-up download
files & you don't have tons & tons of bots waiting to
download ``warez''. Anyway,
com is like IRC except
com is cool.
To use com, type ``
com'' on the command line. You'll
be plopped into the lobby, which is the default room.
Com uses single-key commands mostly. If you are new to
you might want to read
COM Command Discussion
in this same
article. If you are having trouble exiting from the
program, then you definitely need to read
COM Command Discussion.
This table shows the most frequently
|h||Get a list of all the commands|
|?||Get a list of all the commands|
|space bar||Enter text that you ``say'' into the room|
|return||Enter text that you ``say'' into the room|
|g||goto another room|
|q||Quit COM Mode|
Also, from COM Mode, you can compete with others in games of Nethack, Netris, & some others. If you can master the ``h'' command in COM, it will show you the commands for playing these games.
com commands are hot. By that, I mean that
you type a command character, &
com immediately takes
action. You must be careful to type only the command
character you intend. If you type other characters along
with the character you intend, one of those other characters
might be interpreted as a command, & the character you
intend will be interpreted as an argument to that command.
It might sound like I'm being pedantic, but people who are
com often have this problem.
The next list shows the proper sequence of
steps for entering a command in
com. It assumes you
are already running
com & that you are not currently
com commands. You are just reading the
text in the room.
[your-handle] the-command'', where your-handle is your login name & where the-command is the command key you intended, you did it incorrectly.
Step number 4 is critically
important & deserves further discussion.
In step number 4, you touch (or ``type'') the command key.
You do not touch (or type) any other keys on your keyboard
or on any other keyboard. You don't need to ``enter'' the
command by typing the Return or Enter key on your keyboard;
com will acknowledge your command key
A common error for new users is to type the Return (or
Enter) key after they type the command key.
executes the command key fine, then it notices the Return
key. Return is a command, so
com executes it. The
Return command gets you a prompt so that you may enter text
that you ``say'' for other people to ``hear'' in the room.
Because of the Return key,
com is not interpreting the
new user's keystrokes as commands.
Then the new user tries to type another command, such as the
``q'' (quit) command, but
com interprets it as text to
say into the room. The new user is under the impression
that he needs to end commands with Return, so he does that,
com to print ``q'' into the room for
everyone to see. The new user is confused about why his
command doesn't execute, so he types ``h'' & Return again.
The ``h'' is interpreted as a command & gets him a menu,
but the Return is also interpreted as a command & puts him
into enter-a-line-of-text mode. He sees the ``q'' command
in the menu, types it & Return, & the cycle repeats.
All of this discussion may seem silly to most people, but a
lot of new users have huge amounts of trouble when
they learn to enter a command into
Let's walk a new user named newbie through his first
com'' & pressing the Return key.
comstart. (I think new users see a menu of the
comcommands & have to answer Yes that they have read & understood the menu.) After
comstarts, Newbie will be in the lobby & will see a list of the people in that room. (The lobby is the default room & is where most of the chatting happens.)
[newbie]'' prompt. Then Newbie types ``Hi all. I'm new.'' & then types the Return key.
[newbie] Hi all. I'm new.''.
com, but she can't remember the command, so she types ``h'' to get a menu & pressed Return. This was a mistake. Newbie should have typed ``h'' alone & not pressed Return.
Comsees Newbie's ``h'' command & prints the help menu. That's good, but
comalso sees Newbies Return & assumes Newbie wants to ``say'' a line of text into the room. So
comprints a ``
[newbie]'' prompt & waits for Newbie to type some text, but Newbie is busy reading the help menu & doesn't notice the prompt.
Comthinks Newbie is typing a line of text to say into the room, so her ``q'' is not interpreted as a command. Also, Newbie is still under the incorrect belief that she must end
comcommands with a Return.
[newbie] q'' into the room.
com's modality & Newbie's failure to realize that
comis modal. Sometimes,
comis waiting for Newbie to type a command. Some commands are single key. (The ``q'' & ``h'' commands are examples.) Other commands wait for Newbie to type something, & during that time,
comdoes not interpret her keystrokes as commands. (The Space Bar and Return commands, both of which are for saying text into the room, are examples.)
comis waiting for her to type a command or waiting for her to type text. What's more, whenever they say something like ``Type h by itself'', Newbie types an ``h'' & then a Return. So Newbie keeps going around & around.
comis waiting for her to type a command. At this time, Newbie types ``q'' (& does not type any other characters at all).
comprint an ``Unlinking tty'' message, & then Newbie is dropped back into her unix command line.
The problem is that
com is modal &
new users sometimes fail to realize that.
What does it mean for a program to be modal?
It means that sometimes,
com is waiting for you to type a
command, & sometimes it is waiting for you to type
arguments to a command. Some commands are single key. (The ``q'' &
``h'' commands are examples.) Other commands wait for
you to type something, & during that time,
does not interpret her keystrokes as commands. (The Space
Bar and Return commands, both of which are for saying text
into the room, are examples.)
If you find yourself in the
Com Newbie loop, here's
how to get out of it. Follow the exact steps from
the next list. Type only what it says to
type. Do not type anything else. Do not type Return unless
a step in the table says to type Return.
comto print ``Unlinking tty''.
comor go do something else.
Here's why those steps work:
comis waiting for you to type a command, then you could type the command anyway, but you type Space, which gets you a prompt (
comisn't interpreting commands). Then you type Return, which ends that prompt. So now
comis waiting for a command again. So the Space Bar & Return sequence was unnecessary, but it did not harm. (People in the room won't even see it because if you try to ``say'' an empty line,
comdoesn't print anything.)
comhas prompted you & is not interpreting your commands, the Space Bar won't do anything useful, but the Return key will end that prompt. If you had mistakenly typed Return earlier &
comwas waiting for you to say something into the room, the Space Bar will do nothing, but the Return will end that mode, &
comwill now wait for you to type a command.. (If you had typed things before the Space Bar, you will ``say'' them into the room.)
I have heard that early versions of COM Mode were fairly simple shell scripts that ran tail on a common file. Excellently unixly elegant. COM Mode is in about version 6 now, & it works across a bunch of computers networked at SDF, so I don't know if it's still just some shell scripts.
If you type ``
bboard'', you'll enter the bulletin
board. Its commands resemble those of the faq:
So you want to learn to program? Good. Programming is fun, creative, & fascinating. (It used to be a well-paying career, too. I guess it still is, if you are in India or China.)
There are billions & billions of programming languages. Well, not that many, but there's a damned lot.
You'll probably want to learn one of the most popular ones, which is too bad because most of the currently popular languages aren't very good. They are complex versions of the exact same features that have been available in programming languages since the 1960s. That's right: Even after forty years of hyped, new languages, we've effectively come full-circle to Algol 1960.
But I'm a bitter & opinionated old programmer, so ignore what I just wrote. Here's some actually useful information:
You can use just about any language you want on unix. At the moment, it might be difficult to find a fully functioning C\# compiler for unix, but one is coming, & there is no technical reason that C\# won't work on unix. Many other programming languages are available for unix. Heck, many were developed on unix. So you can pick pretty much whichever you want.
No matter what you pick, I highly recommend that you also do some plain, vanilla C. That's because the programming language of unix is C. When you need to write some programs to experiment with some feature of unix to learn the details of how it works before you use it in a larger program you are writing, the best language for writing those experimental programs is C because it hides the least from you. It's not that C is better, & I'm not saying it's better for writing applications. I mean that because unix's API is for C, C is the best language for discovering how unix's system calls work. C doesn't hide anything from you.
There are two books you need to do serious C programming.
The first is the original & the classic The C Programming Language, by Kernighan & Ritchie. Yeah, it's old & small, but since when is information bad just because it's old? And since when would you rather take days to read a humongous tome that contained no more information than in a small book like K&R?
The second book you need for C programming is The Standard C Library, by P.\ J.\ Plauger (1992).
The C standard library is another good description of the Standard C Library.
Here are some languages that are available on SDF. You may have to be validated or even ARPA to use some of them, but I don't know for sure.
|Bourne (or other)||/bin/sh|
|Open Lisp (not Common)||/sys/pkg/uxlisp/uxlisp|
To learn a language, I recommend studying at least one book, not just online sources.
Obtain, read, & understand a book about data structures. Learn it & learn to love it. Data structures separates the scripters from the programmers.
So you want to hack? To break into computers? Take them over? Get root access? Crash them or use their CPU cycles to do work for you?
Aim high, but I have some advice. Those activities aren't hacking. Those activities are part of cracking. For more information about the meaning of hack, you might read two other chapters from The Jargon File:
You might find some people in COM Mode who would like to talk about these things, but most of them are really tired of kiddies coming into the lobby & asking ``Do any of you know how to hack?'' So you'll need to be more subtle. It's like real life; you don't walk into a room, interrupt the current conversation, & loudly ask if anyone will sell you nose candy. It's just rude.
Information about security holes is pretty easy to find without help. Just use DuckDuckGo or your inferior favorite search engine on terms like ``computer security virus hole exploit''. What you need is the knowledge to make use of that information. You need to learn straightforward programming techniques, especially networking, before you can make use of all that security information that is readily available. So instead of asking people to teach you to crack, it might be more worthwhile (& fun) to talk programming with people.
While we're on the topic, I guess I can throw out a bone. Take a look at CIFS: Common Insecurities Fail Scrutiny & cifs.txt. As of 2013, they're dated but still interesting & hopefully a good start.
Also, be aware that most of the protocols in use on the Internet are defined in the Request For Comment (RFC) documents. One database of RFCs is The RFC Editor. Another such database is RFCs at Ohio State University.
Why do you care about the RFCs? Because to find a hole in some protocol, you need to know the actual protocol, not just heresay that people slip to you in a chat room. To know the protocol, you need to refer to its definitive source. For most protocols on the Internet, that's the RFCs.
For example, let's say you wanted to research holes in Internet multicast. You could go to either of those RFC databases & search for ``multicast''. You conclude that any of these RFCs were worth your time
|RFC1112||Host extensions ofr IP multicasting||S.E. Deering||1 Aug 1989|
|RFC3513||Internet Protocol Version 6 (IPv6) Addressing Architecture||R. Hinden, S. Deering||Apr 2003|
|RFC3261||SIP: Session Initiation Protocol||lots of blokes||Jun 2002|
That's just an example. By the way, if none of those title make you at least a little curious to know what's in those documents, then you might not be cut-out to be a computer hacker or a cracker.
comfrom reacting instantly, but it will react without you pressing any other keys.