Then delete a line from the file by typing "dd."

but that would be very bad -- because the reader would be prone to

type the string d-d-dot, and it happens that in `vi(1)' dot

repeats the last command accepted. The net result would be to delete

*two* lines!

The Jargon File follows hackish usage throughout.

Interestingly, a similar style is now preferred practice in Great

Britain, though the older style (which became established for

typographical reasons having to do with the aesthetics of comma and

quotes in typeset text) is still accepted there. "Hart's Rules" and

the "Oxford Dictionary for Writers and Editors" call the hacker-like

style `new' or `logical' quoting.

Another hacker habit is a tendency to distinguish between `scare'

quotes and `speech' quotes; that is, to use British-style single

quotes for marking and reserve American-style double quotes for actual

reports of speech or text included from elsewhere. Interestingly,

some authorities describe this as correct general usage, but

mainstream American English has gone to using double-quotes

indiscriminately enough that hacker usage appears marked [and, in

fact, I thought this was a personal quirk of mine until I checked with

Usenet --ESR]. One further permutation that is definitely

*not* standard is a hackish tendency to do marking quotes by

using apostrophes (single quotes) in pairs; that is, 'like this'.

This is modelled on string and character literal syntax in some

programming languages (reinforced by the fact that many character-only

terminals display the apostrophe in typewriter style, as a vertical

single quote).

One quirk that shows up frequently in the {email} style of Unix

hackers in particular is a tendency for some things that are normally

all-lowercase (including usernames and the names of commands and C

routines) to remain uncapitalized even when they occur at the

beginning of sentences. It is clear that, for many hackers, the case

of such identifiers becomes a part of their internal representation

(the `spelling') and cannot be overridden without mental effort (an

appropriate reflex because Unix and C both distinguish cases and

confusing them can lead to {lossage}). A way of escaping this dilemma

is simply to avoid using these constructions at the beginning of

sentences.

There seems to be a meta-rule behind these nonstandard hackerisms to

the effect that precision of expression is more important than

conformance to traditional rules; where the latter create ambiguity or

lose information they can be discarded without a second thought. It

is notable in this respect that other hackish inventions (for example,

in vocabulary) also tend to carry very precise shades of meaning even

when constructed to appear slangy and loose. In fact, to a hacker,

the contrast between `loose' form and `tight' content in jargon is a

substantial part of its humor!

Hackers have also developed a number of punctuation and emphasis

conventions adapted to single-font all-ASCII communications links, and

these are occasionally carried over into written documents even when

normal means of font changes, underlining, and the like are available.

One of these is that TEXT IN ALL CAPS IS INTERPRETED AS `LOUD', and

this becomes such an ingrained synesthetic reflex that a person who

goes to caps-lock while in {talk mode} may be asked to "stop shouting,

please, you're hurting my ears!".

Also, it is common to use bracketing with unusual characters to

signify emphasis. The asterisk is most common, as in "What the

*hell*?" even though this interferes with the common use of the

asterisk suffix as a footnote mark. The underscore is also common,

suggesting underlining (this is particularly common with book titles;

for example, "It is often alleged that Joe Haldeman wrote

_The_Forever_War_ as a rebuttal to Robert Heinlein's earlier novel of

the future military, _Starship_Troopers_."). Other forms exemplified

by "=hell=", "\hell/", or "/hell/" are occasionally seen (it's claimed

that in the last example the first slash pushes the letters over to

the right to make them italic, and the second keeps them from falling

over). Finally, words may also be emphasized L I K E T H I S, or by a

series of carets (^) under them on the next line of the text.

There is a semantic difference between *emphasis like this* (which

emphasizes the phrase as a whole), and *emphasis* *like* *this* (which

suggests the writer speaking very slowly and distinctly, as if to a

very young child or a mentally impaired person). Bracketing a word

with the `*' character may also indicate that the writer wishes

readers to consider that an action is taking place or that a sound is

being made. Examples: *bang*, *hic*, *ring*, *grin*, *kick*, *stomp*,

*mumble*.

One might also see the above sound effects as <bang>, <hic>, <ring>,

<grin>, <kick>, <stomp>, <mumble>. This use of angle brackets to mark

their contents originally derives from conventions used in {BNF}, but

since about 1993 it has been reinforced by the HTML markup used on the

World Wide Web.

Angle-bracket enclosure is also used to indicate that a term stands

for some {random} member of a larger class (this is straight from

{BNF}). Examples like the following are common:

So this <ethnic> walks into a bar one day...

There is also an accepted convention for `writing under erasure'; the

text

Be nice to this fool^H^H^H^Hgentleman,

he's visiting from corporate HQ.

reads roughly as "Be nice to this fool, er, gentleman...". This comes

from the fact that the digraph ^H is often used as a print

representation for a backspace. It parallels (and may have been

influenced by) the ironic use of `slashouts' in science-fiction

fanzines.

A related habit uses editor commands to signify corrections to

previous text. This custom is fading as more mailers get good editing

capabilities, but one occasionally still sees things like this:

I've seen that term used on alt.foobar often.

Send it to Erik for the File.

Oops...s/Erik/Eric/.

The s/Erik/Eric/ says "change Erik to Eric in the preceding". This

syntax is borrowed from the Unix editing tools `ed' and `sed', but is

widely recognized by non-Unix hackers as well.

In a formula, `*' signifies multiplication but two asterisks in a row

are a shorthand for exponentiation (this derives from FORTRAN). Thus,

one might write 2 ** 8 = 256.

Another notation for exponentiation one sees more frequently uses the

caret (^, ASCII 1011110); one might write instead `2^8 = 256'. This

goes all the way back to Algol-60, which used the archaic ASCII

`up-arrow' that later became the caret; this was picked up by Kemeny

and Kurtz's original BASIC, which in turn influenced the design of the

`bc(1)' and `dc(1)' Unix tools, which have probably done most to

reinforce the convention on Usenet. The notation is mildly confusing

to C programmers, because `^' means bitwise exclusive-or in C.

Despite this, it was favored 3:1 over ** in a late-1990 snapshot of

Usenet. It is used consistently in this lexicon.

In on-line exchanges, hackers tend to use decimal forms or improper

fractions (`3.5' or `7/2') rather than `typewriter style' mixed

fractions (`3-1/2'). The major motive here is probably that the

former are more readable in a monospaced font, together with a desire

to avoid the risk that the latter might be read as `three minus

one-half'. The decimal form is definitely preferred for fractions

with a terminating decimal representation; there may be some cultural

influence here from the high status of scientific notation.

Another on-line convention, used especially for very large or very

small numbers, is taken from C (which derived it from FORTRAN). This

is a form of `scientific notation' using `e' to replace `*10^'; for

example, one year is about 3e7 seconds long.

The tilde (~) is commonly used in a quantifying sense of

`approximately'; that is, `~50' means `about fifty'.

On Usenet and in the {MUD} world, common C boolean, logical, and

relational operators such as `|', `&', `||', `&&', `!', `==', `!=',

`>', `<', `>=', and `=<' are often combined with English. The Pascal

not-equals, `<>', is also recognized, and occasionally one sees `/='

for not-equals (from Ada, Common Lisp, and Fortran 90). The use of

prefix `!' as a loose synonym for `not-' or `no-' is particularly

common; thus, `!clue' is read `no-clue' or `clueless'.

A related practice borrows syntax from preferred programming languages

to express ideas in a natural-language text. For example, one might

see the following:

In <jrh578689@thudpucker.com> J. R. Hacker wrote:

>I recently had occasion to field-test the Snafu

>Systems 2300E adaptive gonkulator. The price was

>right, and the racing stripe on the case looked

>kind of neat, but its performance left something

>to be desired.

Yeah, I tried one out too.

#ifdef FLAME

Hasn't anyone told those idiots that you can't get

decent bogon suppression with AFJ filters at today's

net volumes?

#endif /* FLAME */

I guess they figured the price premium for true

frame-based semantic analysis was too high.

Unfortunately, it's also the only workable approach.

I wouldn't recommend purchase of this product unless

you're on a *very* tight budget.

#include <disclaimer.h>

--

== Frank Foonly (Fubarco Systems)

In the above, the `#ifdef'/`#endif' pair is a conditional compilation

syntax from C; here, it implies that the text between (which is a

{flame}) should be evaluated only if you have turned on (or defined

on) the switch FLAME. The `#include' at the end is C for "include

standard disclaimer here"; the `standard disclaimer' is understood to

read, roughly, "These are my personal opinions and not to be construed

as the official position of my employer."

The top section in the example, with > at the left margin, is an

example of an inclusion convention we'll discuss below.

More recently, following on the huge popularity of the World Wide Web,

pseudo-HTML markup has become popular for similar purposes:

<flame>

Your father was a hamster and your mother smelt of elderberries!

</flame>

You'll even see this with an HTML-style modifier:

<flame intensity="100%">

You seem well-suited for a career in government.

</flame>

Hackers also mix letters and numbers more freely than in mainstream

usage. In particular, it is good hackish style to write a digit

sequence where you intend the reader to understand the text string

that names that number in English. So, hackers prefer to write

`1970s' rather than `nineteen-seventies' or `1970's' (the latter looks

like a possessive).

It should also be noted that hackers exhibit much less reluctance to

use multiply nested parentheses than is normal in English. Part of

this is almost certainly due to influence from LISP (which uses deeply

nested parentheses (like this (see?)) in its syntax a lot), but it has

also been suggested that a more basic hacker trait of enjoying playing

with complexity and pushing systems to their limits is in operation.

Finally, it is worth mentioning that many studies of on-line

communication have shown that electronic links have a de-inhibiting

effect on people. Deprived of the body-language cues through which

emotional state is expressed, people tend to forget everything about

other parties except what is presented over that ASCII link. This has

both good and bad effects. A good one is that it encourages honesty

and tends to break down hierarchical authority relationships; a bad

one is that it may encourage depersonalization and gratuitous

rudeness. Perhaps in response to this, experienced netters often

display a sort of conscious formal politesse in their writing that has

passed out of fashion in other spoken and written media (for example,

the phrase "Well said, sir!" is not uncommon).

Many introverted hackers who are next to inarticulate in person

communicate with considerable fluency over the net, perhaps precisely

because they can forget on an unconscious level that they are dealing

with people and thus don't feel stressed and anxious as they would

face to face.

Though it is considered gauche to publicly criticize posters for poor

spelling or grammar, the network places a premium on literacy and

clarity of expression. It may well be that future historians of

literature will see in it a revival of the great tradition of personal

letters as art.

:Email Quotes and Inclusion Conventions:

========================================

One area where conventions for on-line writing are still in some flux

is the marking of included material from earlier messages -- what

would be called `block quotations' in ordinary English. From the

usual typographic convention employed for these (smaller font at an

extra indent), there derived a practice of included text being

indented by one ASCII TAB (0001001) character, which under Unix and

many other environments gives the appearance of an 8-space indent.

Early mail and netnews readers had no facility for including messages

this way, so people had to paste in copy manually. BSD `Mail(1)' was

the first message agent to support inclusion, and early Usenetters

emulated its style. But the TAB character tended to push included

text too far to the right (especially in multiply nested inclusions),

leading to ugly wraparounds. After a brief period of confusion

(during which an inclusion leader consisting of three or four spaces

became established in EMACS and a few mailers), the use of leading `>'

or `> ' became standard, perhaps owing to its use in `ed(1)' to

display tabs (alternatively, it may derive from the `>' that some

early Unix mailers used to quote lines starting with "From" in text,

so they wouldn't look like the beginnings of new message headers).

Inclusions within inclusions keep their `>' leaders, so the `nesting

level' of a quotation is visually apparent.

The practice of including text from the parent article when posting a

followup helped solve what had been a major nuisance on Usenet: the

fact that articles do not arrive at different sites in the same order.

Careless posters used to post articles that would begin with, or even

consist entirely of, "No, that's wrong" or "I agree" or the like.

It was hard to see who was responding to what. Consequently, around

1984, new news-posting software evolved a facility to automatically

include the text of a previous article, marked with "> " or whatever

the poster chose. The poster was expected to delete all but the

relevant lines. The result has been that, now, careless posters post

articles containing the *entire* text of a preceding article,

*followed* only by "No, that's wrong" or "I agree".

Many people feel that this cure is worse than the original disease,

and there soon appeared newsreader software designed to let the reader

skip over included text if desired. Today, some posting software

rejects articles containing too high a proportion of lines beginning

with `>' -- but this too has led to undesirable workarounds, such as

the deliberate inclusion of zero-content filler lines which aren't

quoted and thus pull the message below the rejection threshold.

Because the default mailers supplied with Unix and other operating

systems haven't evolved as quickly as human usage, the older

conventions using a leading TAB or three or four spaces are still

alive; however, >-inclusion is now clearly the prevalent form in both

netnews and mail.

Inclusion practice is still evolving, and disputes over the `correct'

inclusion style occasionally lead to {holy wars}.

Most netters view an inclusion as a promise that comment on it will

immediately follow. The preferred, conversational style looks like

this,

> relevant excerpt 1

response to excerpt

> relevant excerpt 2

response to excerpt

> relevant excerpt 3

response to excerpt

or for short messages like this:

> entire message

response to message

Thanks to poor design of some PC-based mail agents, one will

occasionally see the entire quoted message *after* the response, like

this

response to message

> entire message

but this practice is strongly deprecated.

Though `>' remains the standard inclusion leader, `|' is

occasionally used for extended quotations where original variations in

indentation are being retained (one mailer even combines these and

uses `|>'). One also sees different styles of quoting a number

of authors in the same message: one (deprecated because it loses

information) uses a leader of `> ' for everyone, another (the

most common) is `> > > > ', `> > > ', etc. (or

`>>>> ', `>>>', etc., depending on line length and

nesting depth) reflecting the original order of messages, and yet

another is to use a different citation leader for each author, say

`> ', `: ', `| ', `} '

(preserving nesting so that the inclusion order of messages is still

apparent, or tagging the inclusions with authors' names). Yet

*another* style is to use each poster's initials (or login name)

as a citation leader for that poster.

Occasionally one sees a `# ' leader used for quotations from

authoritative sources such as standards documents; the intended

allusion is to the root prompt (the special Unix command prompt issued

when one is running as the privileged super-user).

:Hacker Speech Style:

=====================

Hackish speech generally features extremely precise diction, careful

word choice, a relatively large working vocabulary, and relatively

little use of contractions or street slang. Dry humor, irony, puns,

and a mildly flippant attitude are highly valued -- but an underlying

seriousness and intelligence are essential. One should use just

enough jargon to communicate precisely and identify oneself as a

member of the culture; overuse of jargon or a breathless, excessively

gung-ho attitude is considered tacky and the mark of a loser.

This speech style is a variety of the precisionist English normally

spoken by scientists, design engineers, and academics in technical

fields. In contrast with the methods of jargon construction, it is

fairly constant throughout hackerdom.

It has been observed that many hackers are confused by negative

questions -- or, at least, that the people to whom they are talking

are often confused by the sense of their answers. The problem is that

they have done so much programming that distinguishes between

if (going) ...

and

if (!going) ...

that when they parse the question "Aren't you going?" it seems to be

asking the opposite question from "Are you going?", and so merits an

answer in the opposite sense. This confuses English-speaking

non-hackers because they were taught to answer as though the negative

part weren't there. In some other languages (including Russian,

Chinese, and Japanese) the hackish interpretation is standard and the

problem wouldn't arise. Hackers often find themselves wishing for a

word like French `si' or German `doch' with which one could

unambiguously answer `yes' to a negative question.

For similar reasons, English-speaking hackers almost never use double

negatives, even if they live in a region where colloquial usage allows

them. The thought of uttering something that logically ought to be an

affirmative knowing it will be misparsed as a negative tends to

disturb them.

In a related vein, hackers sometimes make a game of answering

questions containing logical connectives with a strictly literal

rather than colloquial interpretation. A non-hacker who is indelicate

enough to ask a question like "So, are you working on finding that bug

*now* or leaving it until later?" is likely to get the perfectly

correct answer "Yes!" (that is, "Yes, I'm doing it either now or

later, and you didn't ask which!").

:International Style:

=====================

Although the Jargon File remains primarily a lexicon of hacker usage

in American English, we have made some effort to get input from

abroad. Though the hacker-speak of other languages often uses

translations of jargon from English (often as transmitted to them by

earlier Jargon File versions!), the local variations are interesting,

and knowledge of them may be of some use to travelling hackers.

There are some references herein to `Commonwealth hackish'. These are

intended to describe some variations in hacker usage as reported in

the English spoken in Great Britain and the Commonwealth (Canada,

Australia, India, etc. -- though Canada is heavily influenced by

American usage). There is also an entry on {{Commonwealth Hackish}}

reporting some general phonetic and vocabulary differences from

U.S. hackish.

Hackers in Western Europe and (especially) Scandinavia report that

they often use a mixture of English and their native languages for

technical conversation. Occasionally they develop idioms in their

English usage that are influenced by their native-language styles.

Some of these are reported here.

On the other hand, English often gives rise to grammatical and

vocabulary mutations in the native language. For example, Italian

hackers often use the nonexistent verbs `scrollare' (to scroll) and

`deletare' (to delete) rather than native Italian `scorrere' and

`cancellare'. Similarly, the English verb `to hack' has been seen

conjugated in Swedish. European hackers report that this happens

partly because the English terms make finer distinctions than are

available in their native vocabularies, and partly because deliberate

language-crossing makes for amusing wordplay.

A few notes on hackish usages in Russian have been added where they

are parallel with English idioms and thus comprehensible to

English-speakers.

:Crackers, Phreaks, and Lamers:

===============================

From the late 1980s onward, a flourishing culture of local,

MS-DOS-based bulletin boards has been developing separately from

Internet hackerdom. The BBS culture has, as its seamy underside, a

stratum of `pirate boards' inhabited by {cracker}s, phone phreaks, and

{warez d00dz}. These people (mostly teenagers running PC-clones from

their bedrooms) have developed their own characteristic jargon,

heavily influenced by skateboard lingo and underground-rock slang.

Though crackers often call themselves `hackers', they aren't (they

typically have neither significant programming ability, nor Internet

expertise, nor experience with UNIX or other true multi-user systems).

Their vocabulary has little overlap with hackerdom's. Nevertheless,

this lexicon covers much of it so the reader will be able to

understand what goes by on bulletin-board systems.

Here is a brief guide to cracker and {warez d00dz} usage:

* Misspell frequently. The substitutions

phone => fone

freak => phreak

are obligatory.

* Always substitute `z's for `s's. (i.e. "codes" -> "codez").

* Type random emphasis characters after a post line (i.e. "Hey

Dudes!#!$#$!#!$").

* Use the emphatic `k' prefix ("k-kool", "k-rad", "k-awesome")

frequently.

* Abbreviate compulsively ("I got lotsa warez w/ docs").

* Substitute `0' for `o' ("r0dent", "l0zer").

* TYPE ALL IN CAPS LOCK, SO IT LOOKS LIKE YOU'RE YELLING ALL THE

TIME.

These traits are similar to those of {B1FF}, who originated as a

parody of naive BBS users. For further discussion of the pirate-board

subculture, see {lamer}, {elite}, {leech}, {poser}, {cracker}, and

especially {warez d00dz}.

:How to Use the Lexicon:

************************

:Pronunciation Guide:

=====================

Pronunciation keys are provided in the jargon listings for all entries

that are neither dictionary words pronounced as in standard English

nor obvious compounds thereof. Slashes bracket phonetic

pronunciations, which are to be interpreted using the following

conventions:

1. Syllables are hyphen-separated, except that an accent or

back-accent follows each accented syllable (the back-accent marks

a secondary accent in some words of four or more syllables). If

no accent is given, the word is pronounced with equal

accentuation on all syllables (this is common for abbreviations).

2. Consonants are pronounced as in American English. The letter `g'

is always hard (as in "got" rather than "giant"); `ch' is soft

("church" rather than "chemist"). The letter `j' is the sound

that occurs twice in "judge". The letter `s' is always as in

"pass", never a z sound. The digraph `kh' is the guttural of

"loch" or "l'chaim". The digraph 'gh' is the aspirated g+h of

"bughouse" or "ragheap" (rare in English).

3. Uppercase letters are pronounced as their English letter names;

thus (for example) /H-L-L/ is equivalent to /aych el el/. /Z/

may be pronounced /zee/ or /zed/ depending on your local dialect.

The Jargon File, Version 4.0.0, 24 Jul 1996 · 第 16 / 18 题