mirror of https://github.com/tLDP/LDP
2626 lines
68 KiB
Plaintext
2626 lines
68 KiB
Plaintext
<!DOCTYPE Article PUBLIC "-//Davenport//DTD DocBook V3.0//EN">
|
|
|
|
<Article>
|
|
|
|
<ArtHeader>
|
|
|
|
<Title>From VMS to Linux HOWTO</Title>
|
|
<AUTHORGROUP>
|
|
<AUTHOR>
|
|
<FirstName>Guido</FirstName>
|
|
<Surname>Gonzato</Surname>
|
|
<Affiliation>
|
|
<Address><Email>guido ``at'' ibogeo.df.unibo.it</Email></Address>
|
|
</Affiliation>
|
|
</AUTHOR>
|
|
<AUTHOR>
|
|
<FirstName>Mike</FirstName>
|
|
<Surname>Miller</Surname>
|
|
<Affiliation>
|
|
<Address><Email>miller5@uiuc.edu</Email></Address>
|
|
</Affiliation>
|
|
</AUTHOR>
|
|
</AUTHORGROUP>
|
|
<PubDate>v1.1.4, 22 September 2004</PubDate>
|
|
|
|
<Abstract>
|
|
|
|
<Para>
|
|
This HOWTO is aimed at all those who have been using VMS and now need or
|
|
want to switch to Linux, the free UNIX clone. The transition is made
|
|
(hopefully) painless with a step--to--step comparison between commands and
|
|
available tools.
|
|
</Para>
|
|
|
|
</Abstract>
|
|
|
|
</ArtHeader>
|
|
|
|
<Sect1 id="Introduction">
|
|
<Title>Introduction </Title>
|
|
|
|
<Sect2>
|
|
<Title>Why Linux?</Title>
|
|
|
|
<Para>
|
|
You've heard that UNIX is difficult and balk at the prospect of leaving VMS,
|
|
don't you? Don't worry. Linux, one of the finest UNIX clones, is not more
|
|
difficult to use than VMS; actually, I find it easier. Although VMS
|
|
aficionados may not agree, in many people's opinion Linux is much more
|
|
powerful and versatile.
|
|
</Para>
|
|
|
|
<Para>
|
|
Linux and VMS are both good operating systems and accomplish essentially the
|
|
same tasks, but Linux has a few features that make it a good alternative to
|
|
VMS. Moreover, Linux is available for PCs while VMS is not, and modern
|
|
Pentium-based Linux machines can outperform a VAX. The icing on the cake is
|
|
the excellent performance of modern video cards, which turn an X11-based
|
|
Linux box into a fast graphic workstation; nearly always, quicker than
|
|
dedicated machines.
|
|
</Para>
|
|
|
|
<Para>
|
|
I imagine you're a university researcher or a student, and that you use
|
|
VMS for the following everyday tasks:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<ItemizedList>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
writing papers with TeX/LaTeX;
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
programming in Fortran;
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
doing some graphics;
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
using Internet services;
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
et cetera.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
In the following sections I'm going to explain to you how to do these
|
|
tasks under Linux, exploiting your experience with VMS. Prerequisites:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<ItemizedList>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Linux and X Window System are properly installed;
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
there's a system administrator to take care of the technical
|
|
details (please get help from them, not from me ;-) ;
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
your shell---the equivalent of <Literal remap="tt">DCL</Literal>---is <Literal remap="tt">bash</Literal> (ask your
|
|
sysadm).
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
Please note that this HOWTO is not enough to acquaint you fully with
|
|
Linux: it only contains the bare essential to get you started. You
|
|
should learn more about Linux to make the most of it (advanced <Literal remap="tt">bash</Literal>
|
|
features, programming, regular expressions...). From now on, RMP means
|
|
`please read the man pages for further details'. The man pages are the
|
|
equivalent of the command <Literal remap="tt">HELP</Literal>.
|
|
</Para>
|
|
|
|
<Para>
|
|
The Linux Documentation Project documents, available on <ULink
|
|
URL="ftp://sunsite.unc.edu:/pub/Linux/docs/LDP">ftp://sunsite.unc.edu:/pub/Linux/docs/LDP</ULink>
|
|
are an important source of
|
|
information. I suggest that you read Larry Greenfield's ``Linux User
|
|
Guide''---it's invaluable for the novice user.
|
|
</Para>
|
|
|
|
<Para>
|
|
And now, go ahead.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2>
|
|
<Title>Comparing Commands and Files</Title>
|
|
|
|
<Para>
|
|
This table attempts to compare VMS' and Linux' most used commands. Please
|
|
keep in mind that the syntax is often very different; for more details,
|
|
refer to the following sections.
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
VMS Linux Notes
|
|
------------------------------------------------------------------------------
|
|
|
|
@COMMAND command must be executable
|
|
COPY file1 file2 cp file1 file2
|
|
CREATE/DIR [.dirname] mkdir dirname only one at a time
|
|
CREATE/DIR [.dir1.dir2] mkdirhier dir/name
|
|
DELETE filename rm filename
|
|
DIFF file1 file2 diff -c file1 file2
|
|
DIRECTORY ls
|
|
DIRECTORY [...]file find . -name file
|
|
DIRECTORY/FULL ls -al
|
|
EDIT filename vi filename, you won't like it
|
|
emacs filename, EDT compatible
|
|
jed filename ditto---my favourite
|
|
FORTRAN prog.for g77 prog.f, no need to do LINK
|
|
f77 prog.f,
|
|
fort77 prog.f
|
|
HELP command man command must specify `command'
|
|
info command ditto
|
|
LATEX file.tex latex file.tex
|
|
LOGIN.COM .bash_profile, `hidden' file
|
|
.bashrc ditto
|
|
LOGOUT.COM .bash_logout ditto
|
|
MAIL mail, crude
|
|
elm, much better
|
|
pine better still
|
|
mutt ditto
|
|
PRINT file.ps lpr file.ps
|
|
PRINT/QUEUE=laser file.ps lpr -Plaser file.ps
|
|
PHONE user talk user
|
|
RENAME file1 file2 mv file1 file2 not for multiple files
|
|
RUN progname progname
|
|
SEARCH file "pattern" grep pattern file
|
|
SET DEFAULT [-] cd ..
|
|
SET DEFAULT [.dir.name] cd dir/name
|
|
SET HOST hostname telnet hostname, not exactly the same
|
|
rlogin hostname
|
|
SET FILE/OWNER_UIC=joe chown joe file completely different
|
|
SET NOBROADCAST mesg
|
|
SET PASSWORD passwd
|
|
SET PROT=(perm) file chmod perm file completely different
|
|
SET TERMINAL export TERM= different syntax
|
|
SHOW DEFAULT pwd
|
|
SHOW DEVICE du, df
|
|
SHOW ENTRY lpq
|
|
SHOW PROCESS ps -ax
|
|
SHOW QUEUE lpq
|
|
SHOW SYSTEM top
|
|
SHOW TIME date
|
|
SHOW USERS w
|
|
STOP kill
|
|
STOP/QUEUE kill, for processes
|
|
lprm for print queues
|
|
SUBMIT command command &
|
|
SUBMIT/AFTER=time command at time command
|
|
TEX file.tex tex file.tex
|
|
TYPE/PAGE file more file
|
|
less file much better
|
|
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
But of course it's not only a matter of different command names. Read on.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1 id="Short-Intro">
|
|
<Title>Short Intro </Title>
|
|
|
|
<Para>
|
|
This is what you absolutely need to know before logging in the first
|
|
time. Relax, it's not much.
|
|
</Para>
|
|
|
|
<Sect2>
|
|
<Title>Files</Title>
|
|
|
|
<Para>
|
|
|
|
<ItemizedList>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Under VMS filenames are in the form <Literal remap="tt">filename.extension;version</Literal>.
|
|
Under Linux, the version number doesn't exist (big limitation, but see
|
|
Section <XRef LinkEnd="Numbered-Backups-Under-Linux">); the filename
|
|
has normally a limit of 255 characters and can have as many dots as you
|
|
like. Example of filename: <Literal remap="tt">This.is_a_FILEname.txt</Literal>.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Linux distinguishes between upper case and lower case characters:
|
|
<Literal remap="tt">FILENAME.txt</Literal> and <Literal remap="tt">filename.txt</Literal> are two different files;
|
|
<Literal remap="tt">ls</Literal> is a command, <Literal remap="tt">LS</Literal> is not.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
A filename starting with a dot is a `hidden' file (that is,
|
|
it won't normally show up in dir listings), while filenames ending with a
|
|
tilde '<Literal remap="tt">˜</Literal>' represent backup files.
|
|
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
Now, a table to sum up how to translate commands from VMS to Linux:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
|
|
VMS Linux
|
|
---------------------------------------------------------------------
|
|
|
|
$ COPY file1.txt file2.txt $ cp file1.txt file2.txt
|
|
$ COPY [.dir]file.txt [] $ cp dir/file.txt .
|
|
$ COPY [.dir]file.txt [-] $ cp dir/file.txt ..
|
|
$ DELETE *.dat;* $ rm *dat
|
|
$ DIFF file1 file2 $ diff -c file1 file2
|
|
$ PRINT file $ lpr file
|
|
$ PRINT/queue=queuename file $ lpr -Pprintername file
|
|
$ SEARCH *.tex;* "geology" $ grep geology *tex
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
For other examples involving directories, see below; for details about
|
|
protections, ownership, and advanced topics, see Section <XRef LinkEnd="Advanced-Topics">.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2>
|
|
<Title>Directories</Title>
|
|
|
|
<Para>
|
|
|
|
<ItemizedList>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Within the same node and device, directories names under VMS are in
|
|
the form <Literal remap="tt">[top.dir.subdir]</Literal>; under Linux, <Literal remap="tt">/top/dir/subdir/</Literal>. On
|
|
the top of the directory tree lies the so--called `root directory' called
|
|
<Literal remap="tt">/</Literal>; underneath there are other directories like <Literal remap="tt">/bin</Literal>,
|
|
<Literal remap="tt">/usr</Literal>, <Literal remap="tt">/tmp</Literal>, <Literal remap="tt">/etc</Literal>, and others.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
The directory <Literal remap="tt">/home</Literal> contains the so--called users' `home
|
|
directories': e.g. <Literal remap="tt">/home/guido</Literal>, <Literal remap="tt">/home/warner</Literal>, and so on.
|
|
When a user logs in, they start working in their home dir; it's the
|
|
equivalent of <Literal remap="tt">SYS$LOGIN</Literal>. There's a shortcut for the home
|
|
directory: the tilde '<Literal remap="tt">˜</Literal>'. So, <Literal remap="tt">cd ˜/tmp</Literal> is the same
|
|
as, say, <Literal remap="tt">cd /home/guido/tmp</Literal>.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Directory names follow the same rules as file names. Furthermore,
|
|
each directory has two special entries: one is <Literal remap="tt">.</Literal> and refers to the
|
|
directory itself (like <Literal remap="tt">[]</Literal>), and <Literal remap="tt">..</Literal> that refers to the parent
|
|
directory (like <Literal remap="tt">[-]</Literal>).
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
And now for some other examples:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
|
|
VMS Linux
|
|
---------------------------------------------------------------------
|
|
|
|
$ CREATE/DIR [.dirname] $ mkdir dirname
|
|
$ CREATE/DIR [.dir1.dir2.dir3] $ mkdirhier dir1/dir2/dir3
|
|
n/a $ rmdir dirname
|
|
(if dirname is empty)
|
|
$ rm -R dirname
|
|
$ DIRECTORY $ ls
|
|
$ DIRECTORY [...]file.*;* $ find . -name "file*"
|
|
$ SET DEF SYS$LOGIN $ cd
|
|
$ SET DEF [-] $ cd ..
|
|
$ SET DEF [top.dir.subdir] $ cd /top/dir/subdir
|
|
$ SET DEF [.dir.subdir] $ cd dir/subdir
|
|
$ SHOW DEF $ pwd
|
|
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
For protections, ownership, and advanced topics, see Section <XRef LinkEnd="Advanced-Topics">.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2>
|
|
<Title>Programs</Title>
|
|
|
|
<Para>
|
|
|
|
<ItemizedList>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Commands, compiled programs, and shell scripts (VMS' `command
|
|
files') don't have sort of mandatory extensions like <Literal remap="tt">.EXE</Literal> or <Literal remap="tt">.COM</Literal>
|
|
and can be called whatever you like. Executable files are marked by an
|
|
asterisk '<Literal remap="tt">*</Literal>' when you issue <Literal remap="tt">ls -F</Literal>.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
To run an executable file, just type its name (no <Literal remap="tt">RUN
|
|
PROGRAM.EXE</Literal> or <Literal remap="tt">@COMMAND</Literal>). Caveat: it's essential that the file be
|
|
located in a directory included in the <Emphasis>path of executables</Emphasis>, which is a
|
|
list of directories. Typically, the path includes dirs like <Literal remap="tt">/bin</Literal>,
|
|
<Literal remap="tt">/usr/bin</Literal>, <Literal remap="tt">/usr/X11R6/bin</Literal>, and others. If you write your
|
|
own programs, put them in a directory you have included in the path (see how
|
|
in Section <XRef LinkEnd="Configuring">). As an alternative,
|
|
you may run a program specifying its complete path: e.g.,
|
|
<Literal remap="tt">/home/guido/data/myprog</Literal>; or <Literal remap="tt">./myprog</Literal>, if the current
|
|
directory isn't in the path.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Command switches are obtained with <Literal remap="tt">/OPTION=</Literal> under VMS, and
|
|
with <Literal remap="tt">-switch</Literal> or <Literal remap="tt">--switch</Literal> under Linux, where <Literal remap="tt">switch</Literal> is a
|
|
letter, more letters combined, or a word. In particular, the switch <Literal remap="tt">-R</Literal>
|
|
(recursive) of many Linux commands performs the same action as <Literal remap="tt">[...]</Literal>
|
|
under VMS;
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
You can issue several commands on the command line:
|
|
|
|
|
|
<Screen>
|
|
$ command1 ; command2 ; ... ; commandn
|
|
</Screen>
|
|
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Most of the flexibility of Linux comes from two features awkwardly
|
|
implemented or missing in VMS: I/O redirection and piping. (I have been told
|
|
that recent versions of DCL support redirection and piping, but I don't have
|
|
that version.) Redirection is a side feature under VMS (remember
|
|
the switch <Literal remap="tt">/OUTPUT=</Literal> of many commands), or a fastidious process,
|
|
like:
|
|
|
|
|
|
<Screen>
|
|
$ DEFINE /USER SYS$OUTPUT OUT
|
|
$ DEFINE /USER SYS$INPUT IN
|
|
$ RUN PROG
|
|
</Screen>
|
|
|
|
|
|
which has the simple Linux (UNIX) equivalent:
|
|
|
|
|
|
<Screen>
|
|
$ prog < in > out
|
|
</Screen>
|
|
|
|
|
|
Piping is not readily available under VMS, but has a key role under UNIX. A
|
|
typical example:
|
|
|
|
|
|
<Screen>
|
|
$ myprog < datafile | filter_1 | filter_2 >> result.dat 2> errors.log &
|
|
</Screen>
|
|
|
|
|
|
which means: the program <Literal remap="tt">myprog</Literal> gets its input from the file
|
|
<Literal remap="tt">datafile</Literal> (via <Literal remap="tt"><</Literal>), its output is piped (via <Literal remap="tt">|</Literal>) to
|
|
the program <Literal remap="tt">filter_1</Literal> that takes it as input and processes it, the
|
|
resulting output is piped again to <Literal remap="tt">filter_2</Literal> for further processing, the
|
|
final output is appended (via <Literal remap="tt">>></Literal>) to the file <Literal remap="tt">result.dat</Literal>,
|
|
and error messages are redirected (via <Literal remap="tt">2></Literal>) onto the file
|
|
<Literal remap="tt">errors.log</Literal>. All this in background (<Literal remap="tt">&</Literal> at the end of the
|
|
command line). More about this in Section <XRef LinkEnd="Examples">.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
For multitasking, `queues', and the like, see Section <XRef LinkEnd="Advanced-Topics">.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2 id="Quick-Tour">
|
|
<Title>Quick Tour </Title>
|
|
|
|
<Para>
|
|
Now you are ready to try Linux out. Enter your login name and password
|
|
<Emphasis>exactly</Emphasis> as they are. For example, if your login name and password are
|
|
<Literal remap="tt">john</Literal> and <Literal remap="tt">My_PassWd</Literal>, <Emphasis>don't</Emphasis> type <Literal remap="tt">John</Literal> or <Literal remap="tt">my_passwd</Literal>.
|
|
Remember, UNIX distinguishes between capital and small letters.
|
|
</Para>
|
|
|
|
<Para>
|
|
Once you've logged in, you'll see a prompt; chances are it'll be something
|
|
like <Literal remap="tt">machinename:$</Literal>. If you want to change the prompt or make
|
|
some programs start automatically, you'll have to edit a `hidden' file
|
|
called <Literal remap="tt">.profile</Literal> or <Literal remap="tt">.bash_profile</Literal> (see example in Section <XRef LinkEnd="Configuring">). This is the equivalent of
|
|
<Literal remap="tt">LOGIN.COM</Literal>.
|
|
</Para>
|
|
|
|
<Para>
|
|
Pressing ALT--F1, ALT--F2, ... ALT--F6 switches between `virtual consoles'.
|
|
When one VC is busy with a full--screen application, you can flip over to
|
|
another and continue to work. Try and log in to another VC.
|
|
</Para>
|
|
|
|
<Para>
|
|
Now you may want to start X Window System (from now on, X). X is a graphic
|
|
environment very similar to DECWindows---actually, the latter derives from
|
|
the former. Type the command <Literal remap="tt">startx</Literal> and wait a few seconds; most likely
|
|
you'll see an open <Literal remap="tt">xterm</Literal> or equivalent terminal emulator, and possibly
|
|
a button bar. (It depends on how your sysadm configured your Linux box.)
|
|
Click on the desktop (try both mouse buttons) to see a menu.
|
|
</Para>
|
|
|
|
<Para>
|
|
While in X, to access the text mode (`console') sessions press
|
|
CTRL--ALT--F1 ... CTRL--ALT--F6. Try it. When in console, go back to X
|
|
pressing ALT--F7. To quit X, follow the menu instructions or press
|
|
CTRL--ALT--BS.
|
|
</Para>
|
|
|
|
<Para>
|
|
Type the following command to list your home dir contents, including the
|
|
hidden files:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ ls -al
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
Press SHIFT--PAG UP to back-scroll. Now get help about the <Literal remap="tt">ls</Literal> command
|
|
typing:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ man ls
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
pressing 'q' to exit. To end the tour, type <Literal remap="tt">exit</Literal> to quit your session.
|
|
If now you want to turn off your PC, press CTRL--ALT--DEL and wait a few
|
|
seconds (<Emphasis>never</Emphasis> switch off the PC while in Linux! You could damage the
|
|
filesystem.)
|
|
</Para>
|
|
|
|
<Para>
|
|
If you think you're ready to work, go ahead, but if I were you I'd jump
|
|
to Section <XRef LinkEnd="Advanced-Topics">.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1 id="Editing-Files">
|
|
<Title>Editing Files </Title>
|
|
|
|
<Para>
|
|
Linux doesn't have <Literal remap="tt">EDT</Literal>, but there are scores of editors available. The
|
|
only one that's guaranteed to be included in every UNIX version is
|
|
<Literal remap="tt">vi</Literal>---forget it, your sysadm must have installed something better.
|
|
Probably the most popular editor is <Literal remap="tt">emacs</Literal>, which can emulate <Literal remap="tt">EDT</Literal>
|
|
to a certain degree; <Literal remap="tt">jed</Literal> is another editor that provides <Literal remap="tt">EDT</Literal>
|
|
emulation.
|
|
</Para>
|
|
|
|
<Para>
|
|
These two editors are particularly useful for editing program sources, since
|
|
they have two features unknown to <Literal remap="tt">EDT</Literal>: syntax hilighting and automatic
|
|
indentation. Moreover, you can compile your programs from within the editor
|
|
(command <Literal remap="tt">ESC-X compile</Literal>); in case of a syntax error, the cursor will be
|
|
positioned on the offending line. I bet that you'll never want to use the
|
|
true blue <Literal remap="tt">EDT</Literal> again.
|
|
</Para>
|
|
|
|
<Para>
|
|
If you have <Literal remap="tt">emacs</Literal>: start it, then type <Literal remap="tt">ESC-X edt-emulation-on</Literal>.
|
|
Pressing ALT--X or ESC-X is <Literal remap="tt">emacs</Literal>' way of issuing commands, like
|
|
<Literal remap="tt">EDT</Literal>'s CTRL--Z. From now on, <Literal remap="tt">emacs</Literal> acts like <Literal remap="tt">EDT</Literal> apart from a
|
|
few commands. Differences:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<ItemizedList>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
<Emphasis>don't</Emphasis> press CTRL--Z to issue commands (if you did, you stopped
|
|
<Literal remap="tt">emacs</Literal>. Type <Literal remap="tt">fg</Literal> to resume it);
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
there's an extensive on-line help. Press CTRL-H ?, or CTRL-H T to
|
|
start a tutorial;
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
to save a file, press CTRL-X CTRL-S;
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
to exit, press CTRL-X CTRL-C;
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
to insert a new file in a buffer, press CTRL-X CTRL-F, then
|
|
CTRL-X B to switch among buffers.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
If you have <Literal remap="tt">jed</Literal>: ask your sysadm to configure <Literal remap="tt">jed</Literal> properly.
|
|
Emulation is already on when you start it; use the normal keypad keys, and
|
|
press CTRL--H CTRL--H or CTRL-? to get help. Commands are issued in the same
|
|
way as <Literal remap="tt">emacs</Literal>'. In addition, there are some handy key bindings missing
|
|
in the original <Literal remap="tt">EDT</Literal>; key bindings can also be tailored to your own
|
|
taste. Ask your sysadm.
|
|
</Para>
|
|
|
|
<Para>
|
|
In alternative, you may use another editor with a completely different
|
|
interface. <Literal remap="tt">emacs</Literal> in native mode is an obvious choice; another popular
|
|
editor is <Literal remap="tt">joe</Literal>, which can emulate other editors like <Literal remap="tt">emacs</Literal> itself
|
|
(being even easier to use) or the DOS editor. Invoke the editor as
|
|
<Literal remap="tt">jmacs</Literal> or <Literal remap="tt">jstar</Literal> and press, respectively, CTRL-X H or CTRL-J to get
|
|
online help. <Literal remap="tt">emacs</Literal> and <Literal remap="tt">jed</Literal> are <Emphasis>much</Emphasis> more powerful than good
|
|
ol' <Literal remap="tt">EDT</Literal>.
|
|
</Para>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1 id="TeXing">
|
|
<Title>TeXing </Title>
|
|
|
|
<Para>
|
|
TeX and LaTeX are identical to their VMS counterparts---only quicker :-),
|
|
but the tools to handle the <Literal remap="tt">.dvi</Literal> and <Literal remap="tt">.ps</Literal> files are superior:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<ItemizedList>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
to run a TeX file through TeX, do as usual: <Literal remap="tt">tex file.tex</Literal>;
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
to turn a <Literal remap="tt">.dvi</Literal> file into a <Literal remap="tt">.ps</Literal> file, type
|
|
<Literal remap="tt">dvips -o filename.ps filename.dvi</Literal>;
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
to visualize a <Literal remap="tt">.dvi</Literal> file, type within an X session:
|
|
<Literal remap="tt">xdvi filename.dvi &</Literal>. Click on the page to magnify. This program
|
|
is smart: if you edit and run TeX producing newer versions of the <Literal remap="tt">.dvi</Literal>
|
|
file, <Literal remap="tt">xdvi</Literal> will update it automatically;
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
to visualize a <Literal remap="tt">.ps</Literal> file, type within an X session: <Literal remap="tt">ghostview
|
|
filename.ps &</Literal>. Click on the page to magnify. The whole document or
|
|
selected pages can be printed. A newer and better program is <Literal remap="tt">gv</Literal>.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
to print the <Literal remap="tt">.ps</Literal>: usually the command <Literal remap="tt">lpr mypaper.ps</Literal> will
|
|
do, but if the PostScript printer is called, say, `ps' (ask your
|
|
sysadm) you'll do: <Literal remap="tt">lpr -Pps mypaper.ps</Literal>. For more information
|
|
about print queues, go to Section <XRef LinkEnd="Print-Queues">.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
|
|
</Para>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1 id="Programming">
|
|
<Title>Programming </Title>
|
|
|
|
<Para>
|
|
Programming under Linux is <Emphasis>much</Emphasis> better: there are lots of tools that
|
|
make programming easier and quicker. For instance, the drudgery of
|
|
editing--saving--exiting--compiling--re-editing can be cut short by using
|
|
editors like <Literal remap="tt">emacs</Literal> or <Literal remap="tt">jed</Literal>, as seen above.
|
|
</Para>
|
|
|
|
<Sect2>
|
|
<Title>Fortran</Title>
|
|
|
|
<Para>
|
|
Not substantial differences here, but note that at the time of writing the
|
|
available (free) compilers are not 100% compatible with VMS'; expect
|
|
some minor quirks. (It's actually the VMS compiler which has non-standard
|
|
extensions.) See <Literal remap="tt">/usr/doc/g77/DOC</Literal> or <Literal remap="tt">/usr/doc/f2c/f2c.ps</Literal>
|
|
for details.
|
|
</Para>
|
|
|
|
<Para>
|
|
Your sysadm has installed a native compiler called <Literal remap="tt">g77</Literal> (good but, as of
|
|
version 0.5.21, still not perfectly compatible with DEC Fortran) or possibly
|
|
the Fortran to C translator, <Literal remap="tt">f2c</Literal>, and one of the front-ends that make it
|
|
mimic a native compiler. In my experience, the package <Literal remap="tt">yaf77</Literal> is the
|
|
one that provides best results.
|
|
</Para>
|
|
|
|
<Para>
|
|
To compile a Fortran program with <Literal remap="tt">g77</Literal>, edit the source, save it with
|
|
extension <Literal remap="tt">.f</Literal>, then do:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ g77 myprog.f
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
which creates by default an executable called <Literal remap="tt">a.out</Literal> (you don't have
|
|
to link anything). To give the executable a different name and do some
|
|
optimisation:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ g77 -O2 -o myprog myprog.f
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
Beware of optimisations! Ask your sysadm to read the documentation that
|
|
comes with the compiler and tell you if there are any problems.
|
|
</Para>
|
|
|
|
<Para>
|
|
To compile a subroutine:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ g77 -c mysub.f
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
This creates a file <Literal remap="tt">mysub.o</Literal>. To link this subroutine to a program,
|
|
you'll do
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ g77 -o myprog myprog.f mysub.o
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
If you have many external subroutines and you want to make a library, do the
|
|
following:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ cd subroutines/
|
|
$ cat *f >mylib.f ; g77 -c mylib.f
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
This will create <Literal remap="tt">mylib.o</Literal> that you can link to your programs.
|
|
</Para>
|
|
|
|
<Para>
|
|
Finally, to link an external library called, say, <Literal remap="tt">libdummy.so</Literal>:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ g77 -o myprog myprog.f -ldummy
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
If you have <Literal remap="tt">f2c</Literal>, you only have to use <Literal remap="tt">f77</Literal> or <Literal remap="tt">fort77</Literal> instead
|
|
of <Literal remap="tt">g77</Literal>.
|
|
</Para>
|
|
|
|
<Para>
|
|
Another useful programming tool is <Literal remap="tt">make</Literal>, described below.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2>
|
|
<Title>Using <Literal remap="tt">make</Literal></Title>
|
|
|
|
<Para>
|
|
The utility <Literal remap="tt">make</Literal> is a tool to handle the compilation of programs that
|
|
are split into several source files. The VMS counterparts are <Literal remap="tt">MMS</Literal>
|
|
and <Literal remap="tt">MMK</Literal>, which have a different syntax.
|
|
</Para>
|
|
|
|
<Para>
|
|
Let's suppose you have source files containing your routines, <Literal remap="tt">file_1.f,
|
|
file_2.f, file_3.f</Literal>, and a source file of the main program that uses the
|
|
routines, <Literal remap="tt">myprog.f</Literal>. If you compile your program manually, whenever you
|
|
modify one of the source files you have to figure out which file depends on
|
|
which, which file to recompile first, and so on.
|
|
</Para>
|
|
|
|
<Para>
|
|
Instead of getting mad, you can write a `makefile'. This is a text file
|
|
containing the dependencies between your sources: when one is modified, only
|
|
the ones that depend on the modified file will be recompiled.
|
|
</Para>
|
|
|
|
<Para>
|
|
In our example, you'd write a makefile like this:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<ProgramListing>
|
|
|
|
# This is makefile
|
|
# Press the <TAB> key where you see <TAB>!
|
|
# It's important: don't use spaces instead.
|
|
|
|
myprog: myprog.o file_1.o file_2.o file_3.o
|
|
<TAB>g77 -o myprog myprog.o file_1.o file_2.o file_3.o
|
|
# myprog depends on four object files
|
|
|
|
myprog.o: myprog.f
|
|
<TAB>g77 -c myprog.f
|
|
# myprog.o depends on its source file
|
|
|
|
file_1.o: file_1.f
|
|
<TAB>g77 -c file_1.f
|
|
# file_1.o depends on its source file
|
|
|
|
file_2.o: file_2.f file_1.o
|
|
<TAB>g77 -c file_2.f file_1.o
|
|
# file_2.o depends on its source file and an object file
|
|
|
|
file_3.o: file_3.f file_2.o
|
|
<TAB>g77 -c file_3.f file_2.o
|
|
# file_3.o depends on its source file and an object file
|
|
|
|
# end of makefile.
|
|
</ProgramListing>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
Save this file as <Literal remap="tt">Makefile</Literal> and type <Literal remap="tt">make</Literal> to compile your program;
|
|
alternatively, save it as <Literal remap="tt">myprog.mak</Literal> and type <Literal remap="tt">make -f myprog.mak</Literal>.
|
|
And of course, RMP.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2>
|
|
<Title>Shell Scripts</Title>
|
|
|
|
<Para>
|
|
Shell scripts are the equivalent of VMS' command files, and allow for very
|
|
powerful constructs.
|
|
</Para>
|
|
|
|
<Para>
|
|
To write a script, all you have to do is write a standard ASCII file
|
|
containing the commands, save it, then make it executable with the
|
|
command <Literal remap="tt">chmod +x <scriptfile></Literal>. To execute it, type its name.
|
|
</Para>
|
|
|
|
<Para>
|
|
Writing scripts under <Literal remap="tt">bash</Literal> is such a vast subject it would require a
|
|
book by itself, and I will not delve into the topic any further. I'll just
|
|
give you a more-or-less comprehensive and (hopefully) useful example you can
|
|
extract some basic rules from.
|
|
</Para>
|
|
|
|
<Para>
|
|
EXAMPLE: sample.sh
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<ProgramListing>
|
|
#!/bin/sh
|
|
# sample.sh
|
|
# I am a comment
|
|
# don't change the first line, it must be there
|
|
echo "This system is: `uname -a`" # use the output of the command
|
|
echo "My name is $0" # built-in variables
|
|
echo "You gave me the following $# parameters: "$*
|
|
echo "First parameter is: "$1
|
|
echo -n "What's your name? " ; read your_name
|
|
echo notice the difference: "hi $your_name" # quoting with "
|
|
echo notice the difference: 'hi $your_name' # quoting with '
|
|
DIRS=0 ; FILES=0
|
|
for file in `ls .` ; do
|
|
if [ -d ${file} ] ; then # if file is a directory
|
|
DIRS=`expr $DIRS + 1` # this means DIRS = DIRS + 1
|
|
elif [ -f ${file} ] ; then
|
|
FILES=`expr $FILES + 1`
|
|
fi
|
|
case ${file} in
|
|
*.gif|*jpg) echo "${file}: graphic file" ;;
|
|
*.txt|*.tex) echo "${file}: text file" ;;
|
|
*.c|*.f|*.for) echo "${file}: source file" ;;
|
|
*) echo "${file}: generic file" ;;
|
|
esac
|
|
done
|
|
echo "there are ${DIRS} directories and ${FILES} files"
|
|
ls | grep "ZxY--!!!WKW"
|
|
if [ $? != 0 ] ; then # exit code of last command
|
|
echo "ZxY--!!!WKW not found"
|
|
fi
|
|
echo "enough... type 'man bash' if you want more info."
|
|
|
|
</ProgramListing>
|
|
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2 id="C">
|
|
<Title>C </Title>
|
|
|
|
<Para>
|
|
Linux is an excellent environment to program in C. Taken for granted that
|
|
you know C, here are a couple of guidelines. To compile your standard
|
|
<Literal remap="tt">hello.c</Literal> you'll use the <Literal remap="tt">gcc</Literal> compiler, which comes as part of Linux
|
|
and has the same syntax as <Literal remap="tt">g77</Literal>:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ gcc -O2 -o hello hello.c
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
To link a library to a program, add the switch <Literal remap="tt">-l<libname></Literal>.
|
|
For example, to link the math library and optimize do
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ gcc -O2 -o mathprog mathprog.c -lm
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
(The <Literal remap="tt">-l<libname></Literal> switch forces <Literal remap="tt">gcc</Literal> to link the library
|
|
<Literal remap="tt">/usr/lib/lib<libname>.a</Literal>; so <Literal remap="tt">-lm</Literal> links
|
|
<Literal remap="tt">/usr/lib/libm.a</Literal>).
|
|
</Para>
|
|
|
|
<Para>
|
|
When your program is made of several source files, you'll need to use the
|
|
utility <Literal remap="tt">make</Literal> described above. Just use <Literal remap="tt">gcc</Literal> and C source files in
|
|
the makefile.
|
|
</Para>
|
|
|
|
<Para>
|
|
You can invoke some help about the C functions, that are covered by man
|
|
pages, section 3; for example,
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ man 3 printf
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
There are lots of libraries available out there; among the first you'll want
|
|
to use are <Literal remap="tt">ncurses</Literal>, to handle text mode effects, and <Literal remap="tt">svgalib</Literal>, to
|
|
do graphics.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1 id="Graphics">
|
|
<Title>Graphics </Title>
|
|
|
|
<Para>
|
|
Among the scores of graphic packages available, <Literal remap="tt">gnuplot</Literal> stands out
|
|
for its power and ease of use. Go to X and type <Literal remap="tt">gnuplot</Literal>, and have
|
|
two sample data files ready: <Literal remap="tt">2D-data.dat</Literal> (two data per line), and
|
|
<Literal remap="tt">3D-data.dat</Literal> (three data per line).
|
|
</Para>
|
|
|
|
<Para>
|
|
Examples of 2-D graphs:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
gnuplot> set title "my first graph"
|
|
gnuplot> plot '2D-data.dat'
|
|
gnuplot> plot '2D-data.dat' with linespoints
|
|
gnuplot> plot '2D-data.dat', sin(x)
|
|
gnuplot> plot [-5:10] '2D-data.dat'
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
Example of 3-D graphs (each `row' of X values is followed by a blank
|
|
line):
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
gnuplot> set parametric ; set hidden3d ; set contour
|
|
gnuplot> splot '3D-data.dat' using 1:2:3 with linespoints
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
A single-column datafile (e.g., a time series) can also be plotted as a 2-D
|
|
graph:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
gnuplot> plot [-5:15] '2D-data-1col.dat' with linespoints
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
or as a 3-D graph (blank lines in the datafile, as above):
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
gnuplot> set noparametric ; set hidden3d
|
|
gnuplot> splot '3D-data-1col.dat' using 1 with linespoints
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
To print a graph: if the command to print on your Postscript printer is
|
|
<Literal remap="tt">lpr -Pps file.ps</Literal>, issue:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
gnuplot> set term post
|
|
gnuplot> set out '| lpr -Pps'
|
|
gnuplot> replot
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
then type <Literal remap="tt">set term x11</Literal> to restore. Don't get confused---the last print
|
|
will come out only when you quit <Literal remap="tt">gnuplot</Literal>.
|
|
</Para>
|
|
|
|
<Para>
|
|
For more info, type <Literal remap="tt">help</Literal> or see the examples in directory
|
|
<Literal remap="tt">/usr/lib/gnuplot/demos/</Literal>, if you have it.
|
|
</Para>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1 id="Mail-and-Internet-Tools">
|
|
<Title>Mail and Internet Tools </Title>
|
|
|
|
<Para>
|
|
Since Internet was born on UNIX machines, you find plenty of nice and
|
|
easy-to-use applications under Linux. Here are just some:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<ItemizedList>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Mail</Emphasis>: use <Literal remap="tt">elm</Literal> or <Literal remap="tt">pine</Literal> to handle your email; both
|
|
programs have on-line help. For short messages, you could use <Literal remap="tt">mail</Literal>, as
|
|
in <Literal remap="tt">mail -s "hello mate" user@somewhere < msg.txt</Literal>. You may like programs
|
|
like <Literal remap="tt">xmail</Literal> or some such.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Newsgroups</Emphasis>: use <Literal remap="tt">tin</Literal> or <Literal remap="tt">slrn</Literal>, both very intuitive and
|
|
self-explanatory.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">ftp</Emphasis>: apart from the usual character-based <Literal remap="tt">ftp</Literal>, ask your
|
|
sysadm to install the full-screen <Literal remap="tt">ncftp</Literal> or a graphical ftp client like
|
|
<Literal remap="tt">xftp</Literal>.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">WWW</Emphasis>: the ubiquitous <Literal remap="tt">netscape</Literal>, or <Literal remap="tt">xmosaic</Literal>,
|
|
<Literal remap="tt">chimera</Literal>, and <Literal remap="tt">arena</Literal> are graphical web browsers; a character-based
|
|
one is <Literal remap="tt">lynx</Literal>, quick and effective.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
|
|
</Para>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1 id="Advanced-Topics">
|
|
<Title>Advanced Topics </Title>
|
|
|
|
<Para>
|
|
Here the game gets tough. Learn these features, then you'll be ready to say
|
|
that you `know something about Linux' ;-)
|
|
</Para>
|
|
|
|
<Sect2 id="Permissions">
|
|
<Title>Permissions and Ownership </Title>
|
|
|
|
<Para>
|
|
Files and directories have permissions (`protections') and ownership, just
|
|
like under VMS. If you can't run a program, or can't modify a file, or can't
|
|
access a directory, it's because you don't have the permission to do so,
|
|
and/or because the file doesn't belong to you. Let's have a look at the
|
|
following example:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ ls -l /bin/ls
|
|
-rwxr-xr-x 1 root bin 27281 Aug 15 1995 /bin/ls*
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
The first field shows the permissions of the file <Literal remap="tt">ls</Literal> (owner root,
|
|
group bin). There are three types of ownership: owner, group, and others
|
|
(similar to VMS owner, group, world), and three types of permissions:
|
|
read, write (and delete), and execute.
|
|
</Para>
|
|
|
|
<Para>
|
|
From left to right, <Literal remap="tt">-</Literal> is the file type (<Literal remap="tt">-</Literal> = ordinary file, <Literal remap="tt">d</Literal>
|
|
= directory, <Literal remap="tt">l</Literal> = link, etc); <Literal remap="tt">rwx</Literal> are the permissions for the file
|
|
owner (read, write, execute); <Literal remap="tt">r-x</Literal> are the permissions for the group of
|
|
the file owner (read, execute); <Literal remap="tt">r-x</Literal> are the permissions for all other
|
|
users (read, execute).
|
|
</Para>
|
|
|
|
<Para>
|
|
To change a file's permissions:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ chmod <whoXperm> <file>
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
where who is <Literal remap="tt">u</Literal> (user, that is owner), <Literal remap="tt">g</Literal> (group), <Literal remap="tt">o</Literal> (other),
|
|
X is either <Literal remap="tt">+</Literal> or <Literal remap="tt">-</Literal>, perm is <Literal remap="tt">r</Literal> (read), <Literal remap="tt">w</Literal> (write), or
|
|
<Literal remap="tt">x</Literal> (execute). Examples:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ chmod u+x file
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
this sets the execute permission for the file owner. Shortcut:
|
|
<Literal remap="tt">chmod +x file</Literal>.
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ chmod go-wx file
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
this removes write and execute permission for everyone except the owner.
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ chmod ugo+rwx file
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
this gives everyone read, write, and execute permission.
|
|
</Para>
|
|
|
|
<Para>
|
|
A shorter way to refer to permissions is with numbers: <Literal remap="tt">rwxr-xr-x</Literal> can be
|
|
expressed as 755 (every letter corresponds to a bit: <Literal remap="tt">---</Literal> is 0,
|
|
<Literal remap="tt">--x</Literal> is 1, <Literal remap="tt">-w-</Literal> is 2...).
|
|
</Para>
|
|
|
|
<Para>
|
|
For a directory, <Literal remap="tt">rx</Literal> means that you can <Literal remap="tt">cd</Literal> to that directory, and
|
|
<Literal remap="tt">w</Literal> means that you can delete a file in the directory (according to the
|
|
file's permissions, of course), or the directory itself. All this is only
|
|
part of the matter---RMP.
|
|
</Para>
|
|
|
|
<Para>
|
|
To change a file's owner:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ chown username file
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
To sum up, a table:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
VMS Linux Notes
|
|
------------------------------------------------------------------------------
|
|
|
|
SET PROT=(O:RW) file.txt $ chmod u+rw file.txt
|
|
$ chmod 600 file.txt
|
|
SET PROT=(O:RWED,W) file $ chmod u+rwx file
|
|
$ chmod 700 file
|
|
SET PROT=(O:RWED,W:RE) file $ chmod 755 file
|
|
SET PROT=(O:RW,G:RW,W) file $ chmod 660 file
|
|
SET FILE/OWNER_UIC=JOE file $ chown joe file
|
|
SET DIR/OWNER_UIC=JOE [.dir] $ chown joe dir/
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2 id="Multitasking">
|
|
<Title>Multitasking: Processes and Jobs </Title>
|
|
|
|
<Para>
|
|
More about running programs. There are no `batch queues' under Linux as
|
|
you're used to; multitasking is handled very differently. Again, this is
|
|
what the typical command line looks like:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ command -s1 -s2 ... -sn par1 par2 ... parn < input > output &
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
where <Literal remap="tt">-s1</Literal>, ..., <Literal remap="tt">-sn</Literal> are the program switches,
|
|
<Literal remap="tt">par1</Literal>, ..., <Literal remap="tt">parn</Literal> are the program parameters.
|
|
</Para>
|
|
|
|
<Para>
|
|
Now let's see how multitasking works. Programs, running in foreground or
|
|
background, are called `processes'.
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<ItemizedList>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
To launch a process in background:
|
|
|
|
<Screen>
|
|
$ progname [-switches] [parameters] [< input] [> output] &
|
|
[1] 234
|
|
</Screen>
|
|
|
|
the shell tells you what the `job number' (the first digit; see below) and
|
|
PID (Process IDentifier) of the process are. Each process is identified
|
|
by its PID.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
To see how many processes there are:
|
|
|
|
<Screen>
|
|
$ ps -ax
|
|
</Screen>
|
|
|
|
This will output a list of currently running processes.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
To kill a process:
|
|
|
|
<Screen>
|
|
$ kill <PID>
|
|
</Screen>
|
|
|
|
You may need to kill a process when you don't know how to quit it
|
|
the right way... ;-). Sometimes, a process will only be killed by
|
|
one of the following:
|
|
|
|
<Screen>
|
|
$ kill -15 <PID>
|
|
$ kill -9 <PID>
|
|
</Screen>
|
|
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
In addition to this, the shell allows you to stop or temporarily suspend a
|
|
process, send a process to background, and bring a process from background
|
|
to foreground. In this context, processes are called `jobs'.
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<ItemizedList>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
To see how many jobs there are:
|
|
|
|
<Screen>
|
|
$ jobs
|
|
</Screen>
|
|
|
|
jobs are identified by the numbers the shell gives them, not by their PID.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
To stop a process running in foreground:
|
|
|
|
<Screen>
|
|
$ CTRL-C
|
|
</Screen>
|
|
|
|
(it doesn't always work)
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
To suspend a process running in foreground:
|
|
|
|
<Screen>
|
|
$ CTRL-Z
|
|
</Screen>
|
|
|
|
(ditto)
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
To send a suspended process into background (it becomes a job):
|
|
|
|
<Screen>
|
|
$ bg <job>
|
|
</Screen>
|
|
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
To bring a job to foreground:
|
|
|
|
<Screen>
|
|
$ fg <job>
|
|
</Screen>
|
|
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
To kill a job:
|
|
|
|
<Screen>
|
|
$ kill <%job>
|
|
</Screen>
|
|
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2>
|
|
<Title>Files, Revisited</Title>
|
|
|
|
<Para>
|
|
More information about files.
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<ItemizedList>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">stdin, stdout, stderr</Emphasis>: under UNIX, every system component is
|
|
treated as if it were a file. Commands and programs get their input from a
|
|
`file' called <Literal remap="tt">stdin</Literal> (standard input; usually, the keyboard), put their
|
|
output on a `file' called <Literal remap="tt">stdout</Literal> (usually, the screen), and error
|
|
messages go to a `file' called <Literal remap="tt">stderr</Literal> (usually, the screen).
|
|
|
|
Using <Literal remap="tt"><</Literal> and <Literal remap="tt">></Literal> you redirect input and output to a different
|
|
file. Moreover, <Literal remap="tt">>></Literal> appends the output to a file instead of
|
|
overwriting it; <Literal remap="tt">2></Literal> redirects error messages (stderr); 2>&1
|
|
redirects stderr to stdout, while 1>&2 redirects stdout to stderr.
|
|
There's a `black hole' called <Literal remap="tt">/dev/null</Literal>: everything redirected to
|
|
it disappears;
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">wildcards</Emphasis>: '<Literal remap="tt">*</Literal>' is almost the same. Usage: * matches all
|
|
files except the hidden ones; .* matches all hidden files; *.* matches
|
|
only those that have a '.' in the middle, followed by other characters;
|
|
p*r matches both `peter' and `piper'; *c* matches both `picked' and `peck'.
|
|
'<Literal remap="tt">%</Literal>' becomes '<Literal remap="tt">?</Literal>'. There is another wildcard: the
|
|
<Literal remap="tt">[]</Literal>. Usage: <Literal remap="tt">[abc]*</Literal> matches files starting with a, b, c;
|
|
<Literal remap="tt">*[I-N,1,2,3]</Literal> matches files ending with I, J, K, L, M, N, 1, 2, 3;
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
<Literal remap="tt">mv</Literal> (<Literal remap="tt">RENAME</Literal>) doesn't work for multiple files; that is,
|
|
<Literal remap="tt">mv *.xxx *.yyy</Literal> won't work;
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
use <Literal remap="tt">cp -i</Literal> and <Literal remap="tt">mv -i</Literal> to be warned when a file is going to
|
|
be overwritten.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2 id="Print-Queues">
|
|
<Title>Print Queues </Title>
|
|
|
|
<Para>
|
|
Your prints are queued, like under VMS. When you issue a print command, you
|
|
may specify a printer name. Example:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ lpr file.txt # this goes to the standard printer
|
|
$ lpr -Plaser file.ps # this goes to the printer named 'laser'
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
To handle the print queues, you use the following commands:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
|
|
VMS Linux
|
|
------------------------------------------------------------------------------
|
|
|
|
$ PRINT file.ps $ lpr file.ps
|
|
$ PRINT/QUEUE=laser file.ps $ lpr -Plaser file.ps
|
|
$ SHOW QUEUE $ lpq
|
|
$ SHOW QUEUE/QUEUE=laser $ lpq -Plaser
|
|
$ STOP/QUEUE $ lprm <item>
|
|
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1 id="Configuring">
|
|
<Title>Configuring </Title>
|
|
|
|
<Para>
|
|
Your sysadm has already provided you with a number of configuration files
|
|
like <Literal remap="tt">.xinitrc</Literal>, <Literal remap="tt">.bash_profile</Literal>, <Literal remap="tt">.inputrc</Literal>, and many others. The
|
|
ones you may want to edit are:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<ItemizedList>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
<Literal remap="tt"> .bash_profile</Literal> or <Literal remap="tt">.profile</Literal>: read by the shell at login
|
|
time. It's like <Literal remap="tt">LOGIN.COM</Literal>;
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
<Literal remap="tt"> .bash_logout</Literal>: read by the shell at logout. It's like
|
|
<Literal remap="tt">LOGOUT.COM</Literal>;
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
<Literal remap="tt"> .bashrc</Literal>: read by non--login shells.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
<Literal remap="tt"> .inputrc</Literal>: this file customises the key bindings and the
|
|
behaviour of the shell.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
To give you an example, I'll include my <Literal remap="tt">.bash_profile</Literal> (abridged):
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<ProgramListing>
|
|
# $HOME/.bash_profile
|
|
|
|
# don't redefine the path if not necessary
|
|
echo $PATH | grep $LOGNAME > /dev/null
|
|
if [ $? != 0 ]
|
|
then
|
|
export PATH="$PATH:/home/$LOGNAME/bin" # add my dir to the PATH
|
|
fi
|
|
|
|
export PS1='LOGNAME:\w\$ '
|
|
export PS2='Continued...>'
|
|
|
|
# aliases
|
|
|
|
alias bin="cd ~/bin" ; alias cp="cp -i" ; alias d="dir"
|
|
alias del="delete" ; alias dir="/bin/ls $LS_OPTIONS --format=vertical"
|
|
alias ed="jed" ; alias mv='mv -i'
|
|
alias u="cd .." ; alias undel="undelete"
|
|
|
|
# A few useful functions
|
|
|
|
inst() # Install a .tar.gz archive in current directory.
|
|
{
|
|
gzip -dc $1 | tar xvf -
|
|
}
|
|
cz() # List the contents of a .zip archive.
|
|
{
|
|
unzip -l $*
|
|
}
|
|
ctgz() # List the contents of a .tar.gz archive.
|
|
{
|
|
for file in $* ; do
|
|
gzip -dc ${file} | tar tf -
|
|
done
|
|
}
|
|
tgz() # Create a .tgz archive a la zip.
|
|
{
|
|
name=$1 ; tar -cvf $1 ; shift
|
|
tar -rf ${name} $* ; gzip -S .tgz ${name}
|
|
}
|
|
</ProgramListing>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
And this is my <Literal remap="tt">.inputrc</Literal>:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<ProgramListing>
|
|
# $HOME/.inputrc
|
|
# Last modified: 16 January 1997.
|
|
#
|
|
# This file is read by bash and defines key bindings to be used by the shell;
|
|
# what follows fixes the keys END, HOME, and DELETE, plus accented letters.
|
|
# For more information, man readline.
|
|
|
|
"\e[1~": beginning-of-line
|
|
"\e[3~": delete-char
|
|
"\e[4~": end-of-line
|
|
|
|
set bell-style visible
|
|
set meta-flag On
|
|
set convert-meta Off
|
|
set output-meta On
|
|
set horizontal-scroll-mode On
|
|
set show-all-if-ambiguous On
|
|
|
|
# (F1 .. F5) are "\e[[A" ... "\e[[E"
|
|
|
|
"\e[[A": "info "
|
|
</ProgramListing>
|
|
|
|
</Para>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1 id="Useful-Programs">
|
|
<Title>Useful Programs </Title>
|
|
|
|
<Sect2>
|
|
<Title>Browsing Files: <Literal remap="tt">less</Literal></Title>
|
|
|
|
<Para>
|
|
You'll use this file browser every day, so I'll give you a couple of tips to
|
|
use it at best. First of all, ask your sysadm to configure <Literal remap="tt">less</Literal> so as
|
|
it can display not only plain text files, but also compressed files,
|
|
archives, and so on.
|
|
</Para>
|
|
|
|
<Para>
|
|
Like recent versions of <Literal remap="tt">TYPE</Literal>, <Literal remap="tt">less</Literal> lets you browse files
|
|
in both directions. It also accepts several commands that are issued
|
|
pressing a key. The most useful are:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<ItemizedList>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
first of all, press <Literal remap="tt">q</Literal> to leave the browser;
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
<Literal remap="tt">h</Literal> gives you extensive help;
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
<Literal remap="tt">g</Literal> to go to beginning of file, <Literal remap="tt">G</Literal> to the end, number+<Literal remap="tt">g</Literal>
|
|
to go to line `number' (e.g. <Literal remap="tt">125g</Literal>), number+<Literal remap="tt">%</Literal> to move to that
|
|
percentage of the file;
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
<Literal remap="tt">/pattern</Literal> searches forwards for `pattern'; <Literal remap="tt">n</Literal> searches
|
|
forwards for the next match; <Literal remap="tt">?pattern</Literal> and <Literal remap="tt">N</Literal> search backwards;
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
<Literal remap="tt">m</Literal>+letter marks current position (e.g. <Literal remap="tt">ma</Literal>); <Literal remap="tt">'</Literal>+letter go
|
|
to the marked position.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
<Literal remap="tt">:e</Literal> examines a new file;
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
<Literal remap="tt">!command</Literal> executes the shell command.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2 id="Numbered-Backups-Under-Linux">
|
|
<Title>Numbered Backups Under Linux </Title>
|
|
|
|
<Para>
|
|
Alas, Linux doesn't still support file version numbers, but you overcome
|
|
this limitation in two ways. The first is to use RCS, the Revision Control
|
|
System, which allows you to keep previous versions of a file. RCS is
|
|
covered in ``The RCS MINI-HOWTO'' (
|
|
<ULink URL="http://sunsite.unc.edu/mdw/HOWTO/mini/RCS.html">
|
|
http://sunsite.unc.edu/mdw/HOWTO/mini/RCS.html</ULink>).
|
|
</Para>
|
|
|
|
<Para>
|
|
The second way is to use an editor that knows how to deal with numbered
|
|
backups; <Literal remap="tt">emacs</Literal> and <Literal remap="tt">jed</Literal> are OK. In <Literal remap="tt">emacs</Literal>, add
|
|
these lines in your <Literal remap="tt">.emacs</Literal>:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
(setq version-control t)
|
|
(setq kept-new-versions 15) ;;; or any other value
|
|
(setq kept-old-versions 15)
|
|
(setq backup-by-copying-when-linked t)
|
|
(setq backup-by-copying-when-mismatch t)
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
In <Literal remap="tt">jed</Literal>, make sure you have version 0.98.7 or newer; the patch for
|
|
numbered backups is available on <Literal remap="tt">
|
|
<ULink
|
|
URL="http://ibogeo.df.unibo.it/guido/slang/backups.sl">http://ibogeo.df.unibo.it/guido/slang/backups.sl
|
|
</ULink>
|
|
</Literal>.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2>
|
|
<Title>Archiving: tar & gzip</Title>
|
|
|
|
<Para>
|
|
Under UNIX there are some widely used applications to archive and
|
|
compress files. <Literal remap="tt">tar</Literal> is used to make archives, that is collections of
|
|
files. To make a new archive:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ tar -cvf <archive_name.tar> <file> [file...]
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
To extract files from an archive:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ tar -xpvf <archive_name.tar> [file...]
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
To list the contents of an archive:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ tar -tf <archive_name.tar> | less
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
Files can be compressed to save disk space using <Literal remap="tt">compress</Literal>, which is
|
|
obsolete and shouldn't be used any more, or <Literal remap="tt">gzip</Literal>:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ compress <file>
|
|
$ gzip <file>
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
that creates a compressed file with extension .Z (<Literal remap="tt">compress</Literal>) or .gz
|
|
(<Literal remap="tt">gzip</Literal>). These programs don't make archives, but compress files
|
|
individually. To decompress, use:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ compress -d <file.Z>
|
|
$ gzip -d <file.gz>
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
RMP.
|
|
</Para>
|
|
|
|
<Para>
|
|
The <Literal remap="tt">unarj</Literal>, <Literal remap="tt">zip</Literal> and <Literal remap="tt">unzip</Literal> utilities are also available. Files
|
|
with extension <Literal remap="tt">.tar.gz</Literal> or <Literal remap="tt">.tgz</Literal> (archived with <Literal remap="tt">tar</Literal>, then
|
|
compressed with <Literal remap="tt">gzip</Literal>) are very common in the UNIX world. Here's how to
|
|
list the contents of a <Literal remap="tt">.tar.gz</Literal> archive:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ tar -ztf <file.tar.gz> | less
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
To extract the files from a <Literal remap="tt">.tar.gz</Literal> archive:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ tar -zxf <file.tar.gz>
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1 id="Examples">
|
|
<Title>Real Life Examples </Title>
|
|
|
|
<Para>
|
|
UNIX' core idea is that there are many simple commands that can linked
|
|
together via piping and redirection to accomplish even really complex tasks.
|
|
Have a look at the following examples. I'll only explain the most complex
|
|
ones; for the others, please study the above sections and the man pages.
|
|
</Para>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Problem</Emphasis>: <Literal remap="tt">ls</Literal> is too quick and the file names fly away.
|
|
</Para>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Solution</Emphasis>:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ ls | less
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Problem</Emphasis>: I have a file containing a list of words. I want to sort it
|
|
in reverse order and print it.
|
|
</Para>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Solution</Emphasis>:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ cat myfile.txt | sort -r | lpr
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Problem</Emphasis>: my data file has some repeated lines! How do I get rid of them?
|
|
</Para>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Solution</Emphasis>:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ sort datafile.dat | uniq > newfile.dat
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Problem</Emphasis>: I have a file called 'mypaper.txt' or 'mypaper.tex' or some
|
|
such somewhere, but I don't remember where I put it. How do I find it?
|
|
</Para>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Solution</Emphasis>:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ find ~ -name "mypaper*"
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
Explanation: <Literal remap="tt">find</Literal> is a very useful command that lists all the files
|
|
in a directory tree (starting from <Literal remap="tt">˜</Literal> in this case). Its output
|
|
can be filtered to meet several criteria, such as <Literal remap="tt">-name</Literal>.
|
|
</Para>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Problem</Emphasis>: I have a text file containing the word 'entropy' in this
|
|
directory, is there anything like <Literal remap="tt">SEARCH</Literal>?
|
|
</Para>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Solution</Emphasis>: yes, try
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ grep -l 'entropy' *
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Problem</Emphasis>: somewhere I have text files containing the word 'entropy', I'd
|
|
like to know which and where they are. Under VMS I'd use <Literal remap="tt">search entropy
|
|
[...]*.*;*</Literal>, but <Literal remap="tt">grep</Literal> can't recurse subdirectories. Now what?
|
|
</Para>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Solution</Emphasis>:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ find . -exec grep -l "entropy" {} \; 2> /dev/null
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
Explanation: <Literal remap="tt">find .</Literal> outputs all the file names starting from the
|
|
current directory, <Literal remap="tt">-exec grep -l "entropy"</Literal> is an action to be
|
|
performed on each file (represented by <Literal remap="tt">{}</Literal>), <Literal remap="tt">\</Literal>
|
|
terminates the command. If you think this syntax is awful, you're right.
|
|
</Para>
|
|
|
|
<Para>
|
|
In alternative, write the following script:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<ProgramListing>
|
|
#!/bin/sh
|
|
# rgrep: recursive grep
|
|
if [ $# != 3 ]
|
|
then
|
|
echo "Usage: rgrep --switches 'pattern' 'directory'"
|
|
exit 1
|
|
fi
|
|
find $3 -name "*" -exec grep $1 $2 {} \; 2> /dev/null
|
|
</ProgramListing>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
Explanation: <Literal remap="tt">grep</Literal> works like <Literal remap="tt">search</Literal>, and combining it with
|
|
<Literal remap="tt">find</Literal> we get the best of both worlds.
|
|
</Para>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Problem</Emphasis>: I have a data file that has two header lines, then every
|
|
line has 'n' data, not necessarily equally spaced. I want the 2nd and
|
|
5th data value of each line. Shall I write a Fortran program...?
|
|
</Para>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Solution</Emphasis>: nope. This is quicker:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ awk 'NL > 2 {print $2, "\t", $5}' datafile.dat > newfile.dat
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
Explanation: the command <Literal remap="tt">awk</Literal> is actually a programming language:
|
|
for each line starting from the third in <Literal remap="tt">datafile.dat</Literal>, print out
|
|
the second and fifth field, separated by a tab. Learn some <Literal remap="tt">awk</Literal>---it
|
|
saves a lot of time.
|
|
</Para>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Problem</Emphasis>: I've downloaded an FTP site's <Literal remap="tt">ls-lR.gz</Literal> to check its
|
|
contents. For each subdirectory, it contains a line that reads "total xxxx",
|
|
where xxxx is size in kbytes of the dir contents. I'd like to get the grand
|
|
total of all these xxxx values.
|
|
</Para>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Solution</Emphasis>:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
$ zcat ls-lR.gz | awk ' $1 == "total" { i += $2 } END {print i}'
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
Explanation: <Literal remap="tt">zcat</Literal> outputs the contents of the <Literal remap="tt">.gz</Literal> file and pipes
|
|
to <Literal remap="tt">awk</Literal>, whose man page you're kindly requested to read ;-)
|
|
</Para>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Problem</Emphasis>: I've written a Fortran program, <Literal remap="tt">myprog</Literal>, to calculate a
|
|
parameter from a data file. I'd like to run it on hundreds of data files
|
|
and have a list of the results, but it's a nuisance to ask each time for
|
|
the file name. Under VMS I'd write a lengthy command file, and under Linux?
|
|
</Para>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Solution</Emphasis>: a very short script. Make your program look for the data
|
|
file '<Literal remap="tt">mydata.dat</Literal>' and print the result on the screen (stdout), then
|
|
write the following script:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<ProgramListing>
|
|
#!/bin/sh
|
|
# myprog.sh: run the same command on many different files
|
|
# usage: myprog.sh *.dat
|
|
for file in $* # for all parameters (e.g. *.dat)
|
|
do
|
|
# append the file name to result.dat
|
|
echo -n "${file}: " >> results.dat
|
|
# copy current argument to mydata.dat, run myprog
|
|
# and append the output to results.dat
|
|
cp ${file} mydata.dat ; myprog >> results.dat
|
|
done
|
|
</ProgramListing>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Problem</Emphasis>: I want to replace `geology' with `geophysics' in all my
|
|
text files. Shall I edit them all manually?
|
|
</Para>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Solution</Emphasis>: nope. Write this shell script:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<ProgramListing>
|
|
#!/bin/sh
|
|
# replace $1 with $2 in $*
|
|
# usage: replace "old-pattern" "new-pattern" file [file...]
|
|
OLD=$1 # first parameter of the script
|
|
NEW=$2 # second parameter
|
|
shift ; shift # discard the first 2 parameters: the next are the file names
|
|
for file in $* # for all files given as parameters
|
|
do
|
|
# replace every occurrence of OLD with NEW, save on a temporary file
|
|
sed "s/$OLD/$NEW/g" ${file} > ${file}.new
|
|
# rename the temporary file as the original file
|
|
/bin/mv ${file}.new ${file}
|
|
done
|
|
</ProgramListing>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Problem</Emphasis>: I have some data files, I don't know their length and have to
|
|
remove their last but one and last but two lines. Er... manually?
|
|
</Para>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Solution</Emphasis>: no, of course. Write this script:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<ProgramListing>
|
|
#!/bin/sh
|
|
# prune.sh: removes n-1th and n-2th lines from files
|
|
# usage: prune.sh file [file...]
|
|
for file in $* # for every parameter
|
|
do
|
|
LINES=`wc -l $file | awk '{print $1}'` # number of lines in file
|
|
LINES=`expr $LINES - 3` # LINES = LINES - 3
|
|
head -n $LINES $file > $file.new # output first LINES lines
|
|
tail -n 1 $file >> $file.new # append last line
|
|
done
|
|
</ProgramListing>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
I hope these examples whetted your appetite...
|
|
</Para>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1>
|
|
<Title>Tips You Can't Do Without</Title>
|
|
|
|
<Para>
|
|
|
|
<ItemizedList>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Command completion</Emphasis>: pressing <TAB> when issuing a command
|
|
will complete the command line for you. Example: you have to type
|
|
<Literal remap="tt">less this_is_a_long_name</Literal>; typing in <Literal remap="tt">less thi<TAB></Literal>
|
|
will suffice. (If you have other files that start with the same
|
|
characters, supply enough characters to resolve any ambiguity.)
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Back-scrolling</Emphasis>: pressing SHIFT--PAG UP (the grey key) allows
|
|
you to backscroll a few pages, depending on your PC's video memory.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Resetting the screen</Emphasis>: if you happen to <Literal remap="tt">more</Literal> or <Literal remap="tt">cat</Literal>
|
|
a binary file, your screen may end up full of garbage. To fix things,
|
|
blind type <Literal remap="tt">reset</Literal> or this sequence of characters:
|
|
<Literal remap="tt">echo CTRL-V ESC c RETURN</Literal>.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Pasting text</Emphasis>: in console, see below; in X, click and drag to
|
|
select the text in an <Literal remap="tt">xterm</Literal> window, then click the middle button
|
|
(or the two buttons together if you have a two-button mouse) to paste.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
<Emphasis remap="bf">Using the mouse</Emphasis>: ask your sysadm to install <Literal remap="tt">gpm</Literal>, a mouse
|
|
driver for the console. Click and drag to select text, then right click
|
|
to paste the selected text. It works across different VCs.
|
|
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
|
|
</Para>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1>
|
|
<Title>Reading VMS tapes from Linux</Title>
|
|
|
|
<Para>
|
|
(This section was written by Mike Miller)
|
|
</Para>
|
|
|
|
<Sect2>
|
|
<Title>Introduction</Title>
|
|
|
|
<Para>
|
|
From time to time you may want to read tapes made on a VMS machine (or tapes
|
|
that are made to be readable by VMS and *nix systems). In general, this is
|
|
quite easy for DECFILES11A tapes.
|
|
</Para>
|
|
|
|
<Para>
|
|
Although you may be reading this as part of a Linux mini-HOWTO, I believe
|
|
that the information here is applicable to any *nix system - I've done this
|
|
on Linux, HP, Sun and DEC *nix systems. The main platform dependences that I
|
|
know are device names, which can differ on different systems, and the
|
|
options to mt for specifying the device name (for example, mt -f on Linux
|
|
and mt -t on HPUX 9).
|
|
</Para>
|
|
|
|
<Para>
|
|
Caveat - I've only tried this with Exabyte 8mm SCSI tape drives. If you've
|
|
read other formats (still got those 9-tracks lying around?) let me know and
|
|
I'll add a note here.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2>
|
|
<Title>The Basics</Title>
|
|
|
|
<Para>
|
|
When reading a tape that has been made with the VMS ``copy'' command (or has
|
|
at least been made to look like it was made with copy) all you need to know
|
|
is there will be three files on the tape for each actual data file - a
|
|
header, the data, and a trailer. The header and trailer are interesting in
|
|
that they contain info on the file as it existed under VMS. The data is,
|
|
well, the data. Each of these files can be extracted from the tape with the
|
|
dd command. The tape can be positioned by skipping around with the mt
|
|
command.
|
|
</Para>
|
|
|
|
<Para>
|
|
Example: I've got VMS tape with a series of files on it. The first two were
|
|
originally named ce66-2.evt and ce66-3.evt on a VMS system. The tape label
|
|
is c66a2.
|
|
</Para>
|
|
|
|
<Para>
|
|
If I execute these commands:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
> dd if=$TAPE bs=16k of=header1
|
|
> dd if=$TAPE bs=16k of=data1
|
|
> dd if=$TAPE bs=16k of=trailer1
|
|
> dd if=$TAPE bs=16k of=header2
|
|
> dd if=$TAPE bs=16k of=data2
|
|
> dd if=$TAPE bs=16k of=trailer2
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
I'm left with six files: header1, data1, trailer1, header2, data2 and
|
|
trailer2. The syntax here is if="input file", bs="block size" and
|
|
of="output file". TAPE is expected to be a variable containing the device
|
|
name of your tape drive - for example, /dev/nts0 if you are using the first
|
|
SCSI tape on Linux.
|
|
</Para>
|
|
|
|
<Para>
|
|
If you wanted to read the second file, but not the first, you didn't care
|
|
about the header, and you wanted to use the original file name, do this:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
> mt -f $TAPE fsf 4
|
|
> dd if=$TAPE bs=16k of=ce66-2.evt
|
|
> mt -f $TAPE fsf 1
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
Note the 4 - skip three files for the first file on the tape and one for the
|
|
next header. The second mt skips the second file's trailer and positions
|
|
the tape at the beginning of the next file - the third VMS header. You can
|
|
also use mt to skip backwards (bsf), rewind (rewind) and rewind and unload
|
|
the tape (offline, rewoffl).
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2>
|
|
<Title>Some details</Title>
|
|
|
|
<Para>
|
|
The header and trailer files contain uppercase ASCII data used by VMS to
|
|
store file information such as block size. They also contain the file name,
|
|
which can be handy if you want to build scripts that automate read files or
|
|
search for a particular file. The first header on a tape volume is slightly
|
|
different than subsequent headers.
|
|
</Para>
|
|
|
|
<Para>
|
|
For a file that is the first file on the tape, as in header1 of the above
|
|
example, the first four characters will be "VOL1" followed by the volume
|
|
name. In the example, header1 starts with "VOL1C66A2". This is followed by
|
|
a series of spaces terminated with a numeral. After that is the string
|
|
"HDR1" which indicates that this is a file header. The characters
|
|
immediately following the HDR1 string are the VMS file name. In the
|
|
example, this is "HDR1CE66-2.EVT". The next field is the volume name again.
|
|
</Para>
|
|
|
|
<Para>
|
|
For files that are not the first file on the tape, the initial VOL1 field is
|
|
not present. Other than that the header has the same structure as for the
|
|
initial file. Another useful field is the 7th field, which will end with
|
|
"DECFILES11A". This must be present on tapes that conform to the DEC
|
|
Files11A standard.
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<Screen>
|
|
field initial header subsequent headers
|
|
===== ============= ==================
|
|
1 VOL1 + volume name HDR1 + file name
|
|
2 3HDR1 + file name volume name
|
|
3 volume name
|
|
|
|
6 ...DECFILES11A
|
|
7 ...DECFILES11A
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
For full details on the header and trailer format, see the DEC FILES11A
|
|
documentation (on the orange/grey wall - ask your local VMS folks :-).
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2>
|
|
<Title>Comment on Block Size </Title>
|
|
|
|
<Para>
|
|
In the example, I used a block size of 16k. On a *nix system, there is no
|
|
block size associated with a file on disk while, under VMS, each file has a
|
|
specific block size. That means that block size doesn't matter too much on
|
|
the Linux end... unless it makes it hard to read the tape. If you have
|
|
difficulty figuring out the block size and reading a tape, you can try
|
|
setting the hardware block size on your tape drive using `mt -f $TAPE setblk
|
|
0'. The exact form of the setblk option (and its availability) may depend
|
|
on the version of mt, the tape drive hardware interface and on your
|
|
particular flavor of *nix.
|
|
</Para>
|
|
|
|
<Para>
|
|
(Thanks to Wojtek Skulski (<Email>skulski@nsrlc6.nsrl.rochester.edu</Email>)
|
|
for pointing out setblk.)
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1>
|
|
<Title>The End</Title>
|
|
|
|
<Sect2>
|
|
<Title>Copyright</Title>
|
|
|
|
<Para>
|
|
Unless otherwise stated, Linux HOWTO documents are copyrighted by their
|
|
respective authors. Linux HOWTO documents may be reproduced and distributed
|
|
in whole or in part, in any medium physical or electronic, as long as this
|
|
copyright notice is retained on all copies. Commercial redistribution is
|
|
allowed and encouraged; however, the author would like to be notified of any
|
|
such distributions.
|
|
</Para>
|
|
|
|
<Para>
|
|
All translations, derivative works, or aggregate works incorporating any
|
|
Linux HOWTO documents must be covered under this copyright notice. That is,
|
|
you may not produce a derivative work from a HOWTO and impose additional
|
|
restrictions on its distribution. Exceptions to these rules may be granted
|
|
under certain conditions; please contact the Linux HOWTO coordinator at the
|
|
address given below.
|
|
</Para>
|
|
|
|
<Para>
|
|
In short, we wish to promote dissemination of this information through as
|
|
many channels as possible. However, we do wish to retain copyright on the
|
|
HOWTO documents, and would like to be notified of any plans to redistribute
|
|
the HOWTOs.
|
|
</Para>
|
|
|
|
<Para>
|
|
If you have questions, please contact Tim Bynum, the Linux HOWTO
|
|
coordinator, at <Email>linux-howto@sunsite.unc.edu</Email>
|
|
via email.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2>
|
|
<Title>Disclaimer</Title>
|
|
|
|
<Para>
|
|
This work was written following the experience we had at the Settore di
|
|
Geofisica of the Universita' di Bologna (Italy), where a VAX 4000 has been
|
|
superseded and replaced by Linux-based Pentium PCs. Most of my colleagues
|
|
are VMS users, and some of them have switched to Linux.
|
|
</Para>
|
|
|
|
<Para>
|
|
``From VMS to Linux HOWTO'' was written by Guido Gonzato, <Email
|
|
>guido ``at'' ibogeo.df.unibo.it</Email> and Mike Miller,
|
|
<Email>miller5@uiuc.edu</Email>
|
|
who contributed the section on reading VMS tapes.
|
|
Many thanks to my colleagues and friends who helped me define the needs and
|
|
habits of the average VMS user, especially to Dr. Warner Marzocchi.
|
|
</Para>
|
|
|
|
<Para>
|
|
Please help me improve this HOWTO. I'm not a VMS expert and never will be,
|
|
so your suggestions and bug reports are more than welcome.
|
|
</Para>
|
|
|
|
<Para>
|
|
Enjoy,
|
|
</Para>
|
|
|
|
<Para>
|
|
Guido <Literal remap="tt">=8-)</Literal>
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
</Article>
|