mirror of https://github.com/tLDP/LDP
1663 lines
54 KiB
Plaintext
1663 lines
54 KiB
Plaintext
<!doctype linuxdoc system>
|
|
|
|
<article>
|
|
|
|
<title>From VMS to Linux HOWTO
|
|
|
|
<author>By Guido Gonzato,
|
|
<url url="guido ``at'' ibogeo.df.unibo.it">,
|
|
and Mike Miller,
|
|
<url url="miller5@uiuc.edu">
|
|
|
|
<date>v1.1.3, 17 September 1999
|
|
|
|
<abstract>
|
|
|
|
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.
|
|
|
|
</abstract>
|
|
|
|
<toc>
|
|
|
|
<sect> Introduction <label id="Introduction">
|
|
|
|
<sect1> Why Linux?
|
|
|
|
<p>
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
I imagine you're a university researcher or a student, and that you use
|
|
VMS for the following everyday tasks:
|
|
|
|
<itemize>
|
|
|
|
<item> writing papers with TeX/LaTeX;
|
|
<item> programming in Fortran;
|
|
<item> doing some graphics;
|
|
<item> using Internet services;
|
|
<item> et cetera.
|
|
|
|
</itemize>
|
|
|
|
In the following sections I'm going to explain to you how to do these
|
|
tasks under Linux, exploiting your experience with VMS. Prerequisites:
|
|
|
|
<itemize>
|
|
|
|
<item> Linux and X Window System are properly installed;
|
|
|
|
<item> there's a system administrator to take care of the technical
|
|
details (please get help from them, not from me ;-) ;
|
|
|
|
<item> your shell---the equivalent of <tt/DCL/---is <tt/bash/ (ask your
|
|
sysadm).
|
|
|
|
</itemize>
|
|
|
|
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 <tt/bash/
|
|
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 <tt/HELP/.
|
|
|
|
The Linux Documentation Project documents, available on <url
|
|
url="ftp://sunsite.unc.edu:/pub/Linux/docs/LDP">, are an important source of
|
|
information. I suggest that you read Larry Greenfield's ``Linux User
|
|
Guide''---it's invaluable for the novice user.
|
|
|
|
And now, go ahead.
|
|
|
|
<sect1> Comparing Commands and Files
|
|
|
|
<p>
|
|
|
|
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.
|
|
|
|
<tscreen><verb>
|
|
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
|
|
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
|
|
|
|
</verb></tscreen>
|
|
|
|
But of course it's not only a matter of different command names. Read on.
|
|
|
|
|
|
<sect> Short Intro <label id="Short Intro">
|
|
|
|
<p>
|
|
|
|
This is what you absolutely need to know before logging in the first
|
|
time. Relax, it's not much.
|
|
|
|
<sect1> Files
|
|
|
|
<p>
|
|
|
|
<itemize>
|
|
|
|
<item> Under VMS filenames are in the form <tt/filename.extension;version/.
|
|
Under Linux, the version number doesn't exist (big limitation, but see
|
|
Section <ref id="Numbered Backups Under Linux"
|
|
name="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: <tt/This.is_a_FILEname.txt/.
|
|
|
|
<item> Linux distinguishes between upper case and lower case characters:
|
|
<tt/FILENAME.txt/ and <tt/filename.txt/ are two different files;
|
|
<tt/ls/ is a command, <tt/LS/ is not.
|
|
|
|
<item> 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 '<tt/&tilde/' represent backup files.
|
|
|
|
|
|
</itemize>
|
|
|
|
Now, a table to sum up how to translate commands from VMS to Linux:
|
|
|
|
<tscreen><verb>
|
|
|
|
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
|
|
</verb></tscreen>
|
|
|
|
For other examples involving directories, see below; for details about
|
|
protections, ownership, and advanced topics, see Section <ref id="Advanced
|
|
Topics" name="Advanced Topics">.
|
|
|
|
<sect1> Directories
|
|
|
|
<p>
|
|
|
|
<itemize>
|
|
|
|
<item> Within the same node and device, directories names under VMS are in
|
|
the form <tt/[top.dir.subdir]/; under Linux, <tt>/top/dir/subdir/</tt>. On
|
|
the top of the directory tree lies the so--called `root directory' called
|
|
<tt>/</tt>; underneath there are other directories like <tt>/bin</tt>,
|
|
<tt>/usr</tt>, <tt>/tmp</tt>, <tt>/etc</tt>, and others.
|
|
|
|
<item> The directory <tt>/home</tt> contains the so--called users' `home
|
|
directories': e.g. <tt>/home/guido</tt>, <tt>/home/warner</tt>, and so on.
|
|
When a user logs in, they start working in their home dir; it's the
|
|
equivalent of <tt/SYS$LOGIN/. There's a shortcut for the home
|
|
directory: the tilde '<tt/&tilde/'. So, <tt>cd ˜/tmp</tt> is the same
|
|
as, say, <tt>cd /home/guido/tmp</tt>.
|
|
|
|
<item> Directory names follow the same rules as file names. Furthermore,
|
|
each directory has two special entries: one is <tt/./ and refers to the
|
|
directory itself (like <tt/[]/), and <tt/../ that refers to the parent
|
|
directory (like <tt/[-]/).
|
|
|
|
</itemize>
|
|
|
|
And now for some other examples:
|
|
|
|
<tscreen><verb>
|
|
|
|
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
|
|
|
|
</verb></tscreen>
|
|
|
|
For protections, ownership, and advanced topics, see Section <ref
|
|
id="Advanced Topics" name="Advanced Topics">.
|
|
|
|
<sect1> Programs
|
|
|
|
<p>
|
|
|
|
<itemize>
|
|
|
|
<item> Commands, compiled programs, and shell scripts (VMS' `command
|
|
files') don't have sort of mandatory extensions like <tt/.EXE/ or <tt/.COM/
|
|
and can be called whatever you like. Executable files are marked by an
|
|
asterisk '<tt/*/' when you issue <tt/ls -F/.
|
|
|
|
<item> To run an executable file, just type its name (no <tt/RUN
|
|
PROGRAM.EXE/ or <tt/@COMMAND/). Caveat: it's essential that the file be
|
|
located in a directory included in the <em/path of executables/, which is a
|
|
list of directories. Typically, the path includes dirs like <tt>/bin</tt>,
|
|
<tt>/usr/bin</tt>, <tt>/usr/X11R6/bin</tt>, and others. If you write your
|
|
own programs, put them in a directory you have included in the path (see how
|
|
in Section <ref id="Configuring" name="Configuring">). As an alternative,
|
|
you may run a program specifying its complete path: e.g.,
|
|
<tt>/home/guido/data/myprog</tt>; or <tt>./myprog</tt>, if the current
|
|
directory isn't in the path.
|
|
|
|
<item> Command switches are obtained with <tt>/OPTION=</tt> under VMS, and
|
|
with <tt/-switch/ or <tt/--switch/ under Linux, where <tt/switch/ is a
|
|
letter, more letters combined, or a word. In particular, the switch <tt/-R/
|
|
(recursive) of many Linux commands performs the same action as <tt/[...]/
|
|
under VMS;
|
|
|
|
<item> You can issue several commands on the command line:
|
|
|
|
<tscreen><verb>
|
|
$ command1 ; command2 ; ... ; commandn
|
|
</verb></tscreen>
|
|
|
|
<item> 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 <tt>/OUTPUT=</tt> of many commands), or a fastidious process,
|
|
like:
|
|
|
|
<tscreen><verb>
|
|
$ DEFINE /USER SYS$OUTPUT OUT
|
|
$ DEFINE /USER SYS$INPUT IN
|
|
$ RUN PROG
|
|
</verb></tscreen>
|
|
|
|
which has the simple Linux (UNIX) equivalent:
|
|
|
|
<tscreen><verb>
|
|
$ prog < in > out
|
|
</verb></tscreen>
|
|
|
|
Piping is not readily available under VMS, but has a key role under UNIX. A
|
|
typical example:
|
|
|
|
<tscreen><verb>
|
|
$ myprog < datafile | filter_1 | filter_2 >> result.dat 2> errors.log &
|
|
</verb></tscreen>
|
|
|
|
which means: the program <tt/myprog/ gets its input from the file
|
|
<tt/datafile/ (via <tt/</), its output is piped (via <tt/|/) to
|
|
the program <tt/filter_1/ that takes it as input and processes it, the
|
|
resulting output is piped again to <tt/filter_2/ for further processing, the
|
|
final output is appended (via <tt/>>/) to the file <tt/result.dat/,
|
|
and error messages are redirected (via <tt/2>/) onto the file
|
|
<tt/errors.log/. All this in background (<tt/&/ at the end of the
|
|
command line). More about this in Section <ref id="Examples"
|
|
name="Examples">.
|
|
|
|
</itemize>
|
|
|
|
For multitasking, `queues', and the like, see Section <ref id="Advanced
|
|
Topics"name="Advanced Topics">.
|
|
|
|
<sect1> Quick Tour <label id="Quick Tour">
|
|
|
|
<p>
|
|
|
|
Now you are ready to try Linux out. Enter your login name and password
|
|
<em/exactly/ as they are. For example, if your login name and password are
|
|
<tt/john/ and <tt/My_PassWd/, <em/don't/ type <tt/John/ or <tt/my_passwd/.
|
|
Remember, UNIX distinguishes between capital and small letters.
|
|
|
|
Once you've logged in, you'll see a prompt; chances are it'll be something
|
|
like <tt/machinename:$/. If you want to change the prompt or make
|
|
some programs start automatically, you'll have to edit a `hidden' file
|
|
called <tt/.profile/ or <tt/.bash_profile/ (see example in Section <ref
|
|
id="Configuring" name="Configuring">). This is the equivalent of
|
|
<tt/LOGIN.COM/.
|
|
|
|
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.
|
|
|
|
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 <tt/startx/ and wait a few seconds; most likely
|
|
you'll see an open <tt/xterm/ 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.
|
|
|
|
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.
|
|
|
|
Type the following command to list your home dir contents, including the
|
|
hidden files:
|
|
|
|
<tscreen><verb>
|
|
$ ls -al
|
|
</verb></tscreen>
|
|
|
|
Press SHIFT--PAG UP to back-scroll. Now get help about the <tt/ls/ command
|
|
typing:
|
|
|
|
<tscreen><verb>
|
|
$ man ls
|
|
</verb></tscreen>
|
|
|
|
pressing 'q' to exit. To end the tour, type <tt/exit/ to quit your session.
|
|
If now you want to turn off your PC, press CTRL--ALT--DEL and wait a few
|
|
seconds (<em/never/ switch off the PC while in Linux! You could damage the
|
|
filesystem.)
|
|
|
|
If you think you're ready to work, go ahead, but if I were you I'd jump
|
|
to Section <ref id="Advanced Topics"name="Advanced Topics">.
|
|
|
|
|
|
<sect> Editing Files <label id="Editing Files">
|
|
|
|
<p>
|
|
|
|
Linux doesn't have <tt/EDT/, but there are scores of editors available. The
|
|
only one that's guaranteed to be included in every UNIX version is
|
|
<tt/vi/---forget it, your sysadm must have installed something better.
|
|
Probably the most popular editor is <tt/emacs/, which can emulate <tt/EDT/
|
|
to a certain degree; <tt/jed/ is another editor that provides <tt/EDT/
|
|
emulation.
|
|
|
|
These two editors are particularly useful for editing program sources, since
|
|
they have two features unknown to <tt/EDT/: syntax hilighting and automatic
|
|
indentation. Moreover, you can compile your programs from within the editor
|
|
(command <tt/ESC-X compile/); 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 <tt/EDT/ again.
|
|
|
|
If you have <tt/emacs/: start it, then type <tt/ESC-X edt-emulation-on/.
|
|
Pressing ALT--X or ESC-X is <tt/emacs/' way of issuing commands, like
|
|
<tt/EDT/'s CTRL--Z. From now on, <tt/emacs/ acts like <tt/EDT/ apart from a
|
|
few commands. Differences:
|
|
|
|
<itemize>
|
|
|
|
<item> <em/don't/ press CTRL--Z to issue commands (if you did, you stopped
|
|
<tt/emacs/. Type <tt/fg/ to resume it);
|
|
|
|
<item> there's an extensive on-line help. Press CTRL-H ?, or CTRL-H T to
|
|
start a tutorial;
|
|
|
|
<item> to save a file, press CTRL-X CTRL-S;
|
|
|
|
<item> to exit, press CTRL-X CTRL-C;
|
|
|
|
<item> to insert a new file in a buffer, press CTRL-X CTRL-F, then
|
|
CTRL-X B to switch among buffers.
|
|
|
|
</itemize>
|
|
|
|
If you have <tt/jed/: ask your sysadm to configure <tt/jed/ 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 <tt/emacs/'. In addition, there are some handy key bindings missing
|
|
in the original <tt/EDT/; key bindings can also be tailored to your own
|
|
taste. Ask your sysadm.
|
|
|
|
In alternative, you may use another editor with a completely different
|
|
interface. <tt/emacs/ in native mode is an obvious choice; another popular
|
|
editor is <tt/joe/, which can emulate other editors like <tt/emacs/ itself
|
|
(being even easier to use) or the DOS editor. Invoke the editor as
|
|
<tt/jmacs/ or <tt/jstar/ and press, respectively, CTRL-X H or CTRL-J to get
|
|
online help. <tt/emacs/ and <tt/jed/ are <em/much/ more powerful than good
|
|
ol' <tt/EDT/.
|
|
|
|
|
|
<sect> TeXing <label id="TeXing">
|
|
|
|
<p>
|
|
|
|
TeX and LaTeX are identical to their VMS counterparts---only quicker :-),
|
|
but the tools to handle the <tt/.dvi/ and <tt/.ps/ files are superior:
|
|
|
|
<itemize>
|
|
|
|
<item> to run a TeX file through TeX, do as usual: <tt/tex file.tex/;
|
|
|
|
<item> to turn a <tt/.dvi/ file into a <tt/.ps/ file, type
|
|
<tt/dvips -o filename.ps filename.dvi/;
|
|
|
|
<item> to visualize a <tt/.dvi/ file, type within an X session:
|
|
<tt/xdvi filename.dvi &/. Click on the page to magnify. This program
|
|
is smart: if you edit and run TeX producing newer versions of the <tt/.dvi/
|
|
file, <tt/xdvi/ will update it automatically;
|
|
|
|
<item> to visualize a <tt/.ps/ file, type within an X session: <tt/ghostview
|
|
filename.ps &/. Click on the page to magnify. The whole document or
|
|
selected pages can be printed. A newer and better program is <tt/gv/.
|
|
|
|
<item> to print the <tt/.ps/: usually the command <tt/lpr mypaper.ps/ will
|
|
do, but if the PostScript printer is called, say, `ps' (ask your
|
|
sysadm) you'll do: <tt/lpr -Pps mypaper.ps/. For more information
|
|
about print queues, go to Section <ref id="Print Queues"
|
|
name="Print Queues">.
|
|
|
|
</itemize>
|
|
|
|
|
|
<sect> Programming <label id="Programming">
|
|
|
|
<p>
|
|
|
|
Programming under Linux is <em/much/ 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 <tt/emacs/ or <tt/jed/, as seen above.
|
|
|
|
<sect1> Fortran
|
|
|
|
<p>
|
|
|
|
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 <tt>/usr/doc/g77/DOC</tt> or <tt>/usr/doc/f2c/f2c.ps</tt>
|
|
for details.
|
|
|
|
Your sysadm has installed a native compiler called <tt/g77/ (good but, as of
|
|
version 0.5.21, still not perfectly compatible with DEC Fortran) or possibly
|
|
the Fortran to C translator, <tt/f2c/, and one of the front-ends that make it
|
|
mimic a native compiler. In my experience, the package <tt/yaf77/ is the
|
|
one that provides best results.
|
|
|
|
To compile a Fortran program with <tt/g77/, edit the source, save it with
|
|
extension <tt/.f/, then do:
|
|
|
|
<tscreen><verb>
|
|
$ g77 myprog.f
|
|
</verb></tscreen>
|
|
|
|
which creates by default an executable called <tt/a.out/ (you don't have
|
|
to link anything). To give the executable a different name and do some
|
|
optimisation:
|
|
|
|
<tscreen><verb>
|
|
$ g77 -O2 -o myprog myprog.f
|
|
</verb></tscreen>
|
|
|
|
Beware of optimisations! Ask your sysadm to read the documentation that
|
|
comes with the compiler and tell you if there are any problems.
|
|
|
|
To compile a subroutine:
|
|
|
|
<tscreen><verb>
|
|
$ g77 -c mysub.f
|
|
</verb></tscreen>
|
|
|
|
This creates a file <tt/mysub.o/. To link this subroutine to a program,
|
|
you'll do
|
|
|
|
<tscreen><verb>
|
|
$ g77 -o myprog myprog.f mysub.o
|
|
</verb></tscreen>
|
|
|
|
If you have many external subroutines and you want to make a library, do the
|
|
following:
|
|
|
|
<tscreen><verb>
|
|
$ cd subroutines/
|
|
$ cat *f >mylib.f ; g77 -c mylib.f
|
|
</verb></tscreen>
|
|
|
|
This will create <tt/mylib.o/ that you can link to your programs.
|
|
|
|
Finally, to link an external library called, say, <tt/libdummy.so/:
|
|
|
|
<tscreen><verb>
|
|
$ g77 -o myprog myprog.f -ldummy
|
|
</verb></tscreen>
|
|
|
|
If you have <tt/f2c/, you only have to use <tt/f77/ or <tt/fort77/ instead
|
|
of <tt/g77/.
|
|
|
|
Another useful programming tool is <tt/make/, described below.
|
|
|
|
|
|
<sect1> Using <tt/make/
|
|
|
|
<p>
|
|
|
|
The utility <tt/make/ is a tool to handle the compilation of programs that
|
|
are split into several source files. The VMS counterparts are <tt>MMS</tt>
|
|
and <tt>MMK</tt>, which have a different syntax.
|
|
|
|
Let's suppose you have source files containing your routines, <tt/file_1.f,
|
|
file_2.f, file_3.f/, and a source file of the main program that uses the
|
|
routines, <tt/myprog.f/. 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.
|
|
|
|
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.
|
|
|
|
In our example, you'd write a makefile like this:
|
|
|
|
<code>
|
|
|
|
# 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.
|
|
</code>
|
|
|
|
Save this file as <tt/Makefile/ and type <tt/make/ to compile your program;
|
|
alternatively, save it as <tt/myprog.mak/ and type <tt/make -f myprog.mak/.
|
|
And of course, RMP.
|
|
|
|
|
|
<sect1> Shell Scripts
|
|
|
|
<p>
|
|
|
|
Shell scripts are the equivalent of VMS' command files, and allow for very
|
|
powerful constructs.
|
|
|
|
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 <tt/chmod +x <scriptfile>/. To execute it, type its name.
|
|
|
|
Writing scripts under <tt/bash/ 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.
|
|
|
|
EXAMPLE: sample.sh
|
|
|
|
<code>
|
|
#!/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."
|
|
|
|
</code>
|
|
|
|
<sect1> C <label id="C">
|
|
|
|
<p>
|
|
|
|
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
|
|
<tt/hello.c/ you'll use the <tt/gcc/ compiler, which comes as part of Linux
|
|
and has the same syntax as <tt/g77/:
|
|
|
|
<tscreen><verb>
|
|
$ gcc -O2 -o hello hello.c
|
|
</verb></tscreen>
|
|
|
|
To link a library to a program, add the switch <tt>-l<libname></tt>.
|
|
For example, to link the math library and optimize do
|
|
|
|
<tscreen><verb>
|
|
$ gcc -O2 -o mathprog mathprog.c -lm
|
|
</verb></tscreen>
|
|
|
|
(The <tt>-l<libname></tt> switch forces <tt/gcc/ to link the library
|
|
<tt>/usr/lib/lib<libname>.a</tt>; so <tt/-lm/ links
|
|
<tt>/usr/lib/libm.a</tt>).
|
|
|
|
When your program is made of several source files, you'll need to use the
|
|
utility <tt/make/ described above. Just use <tt/gcc/ and C source files in
|
|
the makefile.
|
|
|
|
You can invoke some help about the C functions, that are covered by man
|
|
pages, section 3; for example,
|
|
|
|
<tscreen><verb>
|
|
$ man 3 printf
|
|
</verb></tscreen>
|
|
|
|
There are lots of libraries available out there; among the first you'll want
|
|
to use are <tt/ncurses/, to handle text mode effects, and <tt/svgalib/, to
|
|
do graphics.
|
|
|
|
|
|
<sect> Graphics <label id="Graphics">
|
|
|
|
<p>
|
|
|
|
Among the scores of graphic packages available, <tt/gnuplot/ stands out
|
|
for its power and ease of use. Go to X and type <tt/gnuplot/, and have
|
|
two sample data files ready: <tt/2D-data.dat/ (two data per line), and
|
|
<tt/3D-data.dat/ (three data per line).
|
|
|
|
Examples of 2-D graphs:
|
|
|
|
<tscreen><verb>
|
|
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'
|
|
</verb></tscreen>
|
|
|
|
Example of 3-D graphs (each `row' of X values is followed by a blank
|
|
line):
|
|
|
|
<tscreen><verb>
|
|
gnuplot> set parametric ; set hidden3d ; set contour
|
|
gnuplot> splot '3D-data.dat' using 1:2:3 with linespoints
|
|
</verb></tscreen>
|
|
|
|
A single-column datafile (e.g., a time series) can also be plotted as a 2-D
|
|
graph:
|
|
|
|
<tscreen><verb>
|
|
gnuplot> plot [-5:15] '2D-data-1col.dat' with linespoints
|
|
</verb></tscreen>
|
|
|
|
or as a 3-D graph (blank lines in the datafile, as above):
|
|
|
|
<tscreen><verb>
|
|
gnuplot> set noparametric ; set hidden3d
|
|
gnuplot> splot '3D-data-1col.dat' using 1 with linespoints
|
|
</verb></tscreen>
|
|
|
|
To print a graph: if the command to print on your Postscript printer is
|
|
<tt/lpr -Pps file.ps/, issue:
|
|
|
|
<tscreen><verb>
|
|
gnuplot> set term post
|
|
gnuplot> set out '| lpr -Pps'
|
|
gnuplot> replot
|
|
</verb></tscreen>
|
|
|
|
then type <tt/set term x11/ to restore. Don't get confused---the last print
|
|
will come out only when you quit <tt/gnuplot/.
|
|
|
|
For more info, type <tt/help/ or see the examples in directory
|
|
<tt>/usr/lib/gnuplot/demos/</tt>, if you have it.
|
|
|
|
|
|
<sect> Mail and Internet Tools <label id="Mail and Internet Tools">
|
|
|
|
<p>
|
|
|
|
Since Internet was born on UNIX machines, you find plenty of nice and
|
|
easy-to-use applications under Linux. Here are just some:
|
|
|
|
<itemize>
|
|
|
|
<item> <bf/Mail/: use <tt/elm/ or <tt/pine/ to handle your email; both
|
|
programs have on-line help. For short messages, you could use <tt/mail/, as
|
|
in <tt/mail -s "hello mate" user@somewhere < msg.txt/. You may like programs
|
|
like <tt/xmail/ or some such.
|
|
|
|
<item> <bf/Newsgroups/: use <tt/tin/ or <tt/slrn/, both very intuitive and
|
|
self-explanatory.
|
|
|
|
<item> <bf/ftp/: apart from the usual character-based <tt/ftp/, ask your
|
|
sysadm to install the full-screen <tt/ncftp/ or a graphical ftp client like
|
|
<tt/xftp/.
|
|
|
|
<item> <bf/WWW/: the ubiquitous <tt/netscape/, or <tt/xmosaic/,
|
|
<tt/chimera/, and <tt/arena/ are graphical web browsers; a character-based
|
|
one is <tt/lynx/, quick and effective.
|
|
|
|
</itemize>
|
|
|
|
<sect> Advanced Topics <label id="Advanced Topics">
|
|
|
|
<p>
|
|
|
|
Here the game gets tough. Learn these features, then you'll be ready to say
|
|
that you `know something about Linux' ;-)
|
|
|
|
|
|
<sect1> Permissions and Ownership <label id="Permissions">
|
|
|
|
<p>
|
|
|
|
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:
|
|
|
|
<tscreen><verb>
|
|
$ ls -l /bin/ls
|
|
-rwxr-xr-x 1 root bin 27281 Aug 15 1995 /bin/ls*
|
|
</verb></tscreen>
|
|
|
|
The first field shows the permissions of the file <tt/ls/ (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.
|
|
|
|
From left to right, <tt/-/ is the file type (<tt/-/ = ordinary file, <tt/d/
|
|
= directory, <tt/l/ = link, etc); <tt/rwx/ are the permissions for the file
|
|
owner (read, write, execute); <tt/r-x/ are the permissions for the group of
|
|
the file owner (read, execute); <tt/r-x/ are the permissions for all other
|
|
users (read, execute).
|
|
|
|
To change a file's permissions:
|
|
|
|
<tscreen><verb>
|
|
$ chmod <whoXperm> <file>
|
|
</verb></tscreen>
|
|
|
|
where who is <tt/u/ (user, that is owner), <tt/g/ (group), <tt/o/ (other),
|
|
X is either <tt/+/ or <tt/-/, perm is <tt/r/ (read), <tt/w/ (write), or
|
|
<tt/x/ (execute). Examples:
|
|
|
|
<tscreen><verb>
|
|
$ chmod u+x file
|
|
</verb></tscreen>
|
|
|
|
this sets the execute permission for the file owner. Shortcut:
|
|
<tt/chmod +x file/.
|
|
|
|
<tscreen><verb>
|
|
$ chmod go-wx file
|
|
</verb></tscreen>
|
|
|
|
this removes write and execute permission for everyone except the owner.
|
|
|
|
<tscreen><verb>
|
|
$ chmod ugo+rwx file
|
|
</verb></tscreen>
|
|
|
|
this gives everyone read, write, and execute permission.
|
|
|
|
A shorter way to refer to permissions is with numbers: <tt/rwxr-xr-x/ can be
|
|
expressed as 755 (every letter corresponds to a bit: <tt/---/ is 0,
|
|
<tt/--x/ is 1, <tt/-w-/ is 2...).
|
|
|
|
For a directory, <tt/rx/ means that you can <tt/cd/ to that directory, and
|
|
<tt/w/ 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.
|
|
|
|
To change a file's owner:
|
|
|
|
<tscreen><verb>
|
|
$ chown username file
|
|
</verb></tscreen>
|
|
|
|
To sum up, a table:
|
|
|
|
<tscreen><verb>
|
|
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/
|
|
</verb></tscreen>
|
|
|
|
|
|
<sect1> Multitasking: Processes and Jobs <label id="Multitasking">
|
|
|
|
<p>
|
|
|
|
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:
|
|
|
|
<tscreen><verb>
|
|
$ command -s1 -s2 ... -sn par1 par2 ... parn < input > output &
|
|
</verb></tscreen>
|
|
|
|
where <tt>-s1</tt>, ..., <tt>-sn</tt> are the program switches,
|
|
<tt/par1/, ..., <tt/parn/ are the program parameters.
|
|
|
|
Now let's see how multitasking works. Programs, running in foreground or
|
|
background, are called `processes'.
|
|
|
|
<itemize>
|
|
|
|
<item> To launch a process in background:
|
|
<tscreen><verb>
|
|
$ progname [-switches] [parameters] [< input] [> output] &
|
|
[1] 234
|
|
</verb></tscreen>
|
|
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.
|
|
|
|
<item> To see how many processes there are:
|
|
<tscreen><verb>
|
|
$ ps -ax
|
|
</verb></tscreen>
|
|
This will output a list of currently running processes.
|
|
|
|
<item> To kill a process:
|
|
<tscreen><verb>
|
|
$ kill <PID>
|
|
</verb></tscreen>
|
|
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:
|
|
<tscreen><verb>
|
|
$ kill -15 <PID>
|
|
$ kill -9 <PID>
|
|
</verb></tscreen>
|
|
|
|
</itemize>
|
|
|
|
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'.
|
|
|
|
<itemize>
|
|
|
|
<item> To see how many jobs there are:
|
|
<tscreen><verb>
|
|
$ jobs
|
|
</verb></tscreen>
|
|
jobs are identified by the numbers the shell gives them, not by their PID.
|
|
|
|
<item> To stop a process running in foreground:
|
|
<tscreen><verb>
|
|
$ CTRL-C
|
|
</verb></tscreen>
|
|
(it doesn't always work)
|
|
|
|
<item> To suspend a process running in foreground:
|
|
<tscreen><verb>
|
|
$ CTRL-Z
|
|
</verb></tscreen>
|
|
(ditto)
|
|
|
|
<item> To send a suspended process into background (it becomes a job):
|
|
<tscreen><verb>
|
|
$ bg <job>
|
|
</verb></tscreen>
|
|
|
|
<item> To bring a job to foreground:
|
|
<tscreen><verb>
|
|
$ fg <job>
|
|
</verb></tscreen>
|
|
|
|
<item> To kill a job:
|
|
<tscreen><verb>
|
|
$ kill <%job>
|
|
</verb></tscreen>
|
|
|
|
</itemize>
|
|
|
|
<sect1> Files, Revisited
|
|
|
|
<p>
|
|
|
|
More information about files.
|
|
|
|
<itemize>
|
|
|
|
<item> <bf/stdin, stdout, stderr/: under UNIX, every system component is
|
|
treated as if it were a file. Commands and programs get their input from a
|
|
`file' called <tt/stdin/ (standard input; usually, the keyboard), put their
|
|
output on a `file' called <tt/stdout/ (usually, the screen), and error
|
|
messages go to a `file' called <tt/stderr/ (usually, the screen).
|
|
|
|
Using <tt/</ and <tt/>/ you redirect input and output to a different
|
|
file. Moreover, <tt/>>/ appends the output to a file instead of
|
|
overwriting it; <tt/2>/ redirects error messages (stderr); 2>&1
|
|
redirects stderr to stdout, while 1>&2 redirects stdout to stderr.
|
|
There's a `black hole' called <tt>/dev/null</tt>: everything redirected to
|
|
it disappears;
|
|
|
|
<item> <bf/wildcards/: '<tt/*/' 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'.
|
|
'<tt/%/' becomes '<tt/?/'. There is another wildcard: the
|
|
<tt/[]/. Usage: <tt/[abc]*/ matches files starting with a, b, c;
|
|
<tt/*[I-N,1,2,3]/ matches files ending with I, J, K, L, M, N, 1, 2, 3;
|
|
|
|
<item> <tt/mv/ (<tt/RENAME/) doesn't work for multiple files; that is,
|
|
<tt/mv *.xxx *.yyy/ won't work;
|
|
|
|
<item> use <tt/cp -i/ and <tt/mv -i/ to be warned when a file is going to
|
|
be overwritten.
|
|
|
|
</itemize>
|
|
|
|
|
|
<sect1> Print Queues <label id="Print Queues">
|
|
|
|
<p>
|
|
|
|
Your prints are queued, like under VMS. When you issue a print command, you
|
|
may specify a printer name. Example:
|
|
|
|
<tscreen><verb>
|
|
$ lpr file.txt # this goes to the standard printer
|
|
$ lpr -Plaser file.ps # this goes to the printer named 'laser'
|
|
</verb></tscreen>
|
|
|
|
To handle the print queues, you use the following commands:
|
|
|
|
<tscreen><verb>
|
|
|
|
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>
|
|
|
|
</verb></tscreen>
|
|
|
|
|
|
<sect> Configuring <label id="Configuring">
|
|
|
|
<p>
|
|
|
|
Your sysadm has already provided you with a number of configuration files
|
|
like <tt/.xinitrc/, <tt/.bash_profile/, <tt/.inputrc/, and many others. The
|
|
ones you may want to edit are:
|
|
|
|
<itemize>
|
|
|
|
<item> <tt/ .bash_profile/ or <tt/.profile/: read by the shell at login
|
|
time. It's like <tt/LOGIN.COM/;
|
|
|
|
<item> <tt/ .bash_logout/: read by the shell at logout. It's like
|
|
<tt/LOGOUT.COM/;
|
|
|
|
<item> <tt/ .bashrc/: read by non--login shells.
|
|
|
|
<item> <tt/ .inputrc/: this file customises the key bindings and the
|
|
behaviour of the shell.
|
|
|
|
</itemize>
|
|
|
|
To give you an example, I'll include my <tt/.bash_profile/ (abridged):
|
|
|
|
<code>
|
|
# $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}
|
|
}
|
|
</code>
|
|
|
|
And this is my <tt/.inputrc/:
|
|
|
|
<code>
|
|
# $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 "
|
|
</code>
|
|
|
|
|
|
<sect> Useful Programs <label id="Useful Programs">
|
|
|
|
<p>
|
|
|
|
<sect1> Browsing Files: <tt/less/
|
|
|
|
<p>
|
|
|
|
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 <tt/less/ so as
|
|
it can display not only plain text files, but also compressed files,
|
|
archives, and so on.
|
|
|
|
Like recent versions of <tt>TYPE</tt>, <tt/less/ lets you browse files
|
|
in both directions. It also accepts several commands that are issued
|
|
pressing a key. The most useful are:
|
|
|
|
<itemize>
|
|
|
|
<item> first of all, press <tt/q/ to leave the browser;
|
|
|
|
<item> <tt/h/ gives you extensive help;
|
|
|
|
<item> <tt/g/ to go to beginning of file, <tt/G/ to the end, number+<tt/g/
|
|
to go to line `number' (e.g. <tt/125g/), number+<tt/%/ to move to that
|
|
percentage of the file;
|
|
|
|
<item> <tt>/pattern</tt> searches forwards for `pattern'; <tt/n/ searches
|
|
forwards for the next match; <tt>?pattern</tt> and <tt/N/ search backwards;
|
|
|
|
<item> <tt/m/+letter marks current position (e.g. <tt/ma/); <tt/'/+letter go
|
|
to the marked position.
|
|
|
|
<item> <tt/:e/ examines a new file;
|
|
|
|
<item> <tt/!command/ executes the shell command.
|
|
|
|
</itemize>
|
|
|
|
|
|
<sect1> Numbered Backups Under Linux <label id="Numbered Backups Under Linux">
|
|
|
|
<p>
|
|
|
|
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'' (<url
|
|
url="http://sunsite.unc.edu/mdw/HOWTO/mini/RCS.html">).
|
|
|
|
The second way is to use an editor that knows how to deal with numbered
|
|
backups; <tt>emacs</tt> and <tt>jed</tt> are OK. In <tt>emacs</tt>, add
|
|
these lines in your <tt>.emacs</tt>:
|
|
|
|
<tscreen><verb>
|
|
(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)
|
|
</verb></tscreen>
|
|
|
|
In <tt>jed</tt>, make sure you have version 0.98.7 or newer; the patch for
|
|
numbered backups is available on <tt> <url
|
|
url="http://ibogeo.df.unibo.it/guido/slang/backups.sl"> </tt>.
|
|
|
|
|
|
<sect1> Archiving: tar & gzip
|
|
|
|
<p>
|
|
|
|
Under UNIX there are some widely used applications to archive and
|
|
compress files. <tt/tar/ is used to make archives, that is collections of
|
|
files. To make a new archive:
|
|
|
|
<tscreen><verb>
|
|
$ tar -cvf <archive_name.tar> <file> [file...]
|
|
</verb></tscreen>
|
|
|
|
To extract files from an archive:
|
|
|
|
<tscreen><verb>
|
|
$ tar -xpvf <archive_name.tar> [file...]
|
|
</verb></tscreen>
|
|
|
|
To list the contents of an archive:
|
|
|
|
<tscreen><verb>
|
|
$ tar -tf <archive_name.tar> | less
|
|
</verb></tscreen>
|
|
|
|
Files can be compressed to save disk space using <tt/compress/, which is
|
|
obsolete and shouldn't be used any more, or <tt/gzip/:
|
|
|
|
<tscreen><verb>
|
|
$ compress <file>
|
|
$ gzip <file>
|
|
</verb></tscreen>
|
|
|
|
that creates a compressed file with extension .Z (<tt/compress/) or .gz
|
|
(<tt/gzip/). These programs don't make archives, but compress files
|
|
individually. To decompress, use:
|
|
|
|
<tscreen><verb>
|
|
$ compress -d <file.Z>
|
|
$ gzip -d <file.gz>
|
|
</verb></tscreen>
|
|
|
|
RMP.
|
|
|
|
The <tt/unarj/, <tt/zip/ and <tt/unzip/ utilities are also available. Files
|
|
with extension <tt/.tar.gz/ or <tt/.tgz/ (archived with <tt/tar/, then
|
|
compressed with <tt/gzip/) are very common in the UNIX world. Here's how to
|
|
list the contents of a <tt/.tar.gz/ archive:
|
|
|
|
<tscreen><verb>
|
|
$ tar -ztf <file.tar.gz> | less
|
|
</verb></tscreen>
|
|
|
|
To extract the files from a <tt/.tar.gz/ archive:
|
|
|
|
<tscreen><verb>
|
|
$ tar -zxf <file.tar.gz>
|
|
</verb></tscreen>
|
|
|
|
|
|
<sect> Real Life Examples <label id="Examples">
|
|
|
|
<p>
|
|
|
|
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.
|
|
|
|
<bf/Problem/: <tt/ls/ is too quick and the file names fly away.
|
|
|
|
<bf/Solution/:
|
|
|
|
<tscreen><verb>
|
|
$ ls | less
|
|
</verb></tscreen>
|
|
|
|
<bf/Problem/: I have a file containing a list of words. I want to sort it
|
|
in reverse order and print it.
|
|
|
|
<bf/Solution/:
|
|
|
|
<tscreen><verb>
|
|
$ cat myfile.txt | sort -r | lpr
|
|
</verb></tscreen>
|
|
|
|
<bf/Problem/: my data file has some repeated lines! How do I get rid of them?
|
|
|
|
<bf/Solution/:
|
|
|
|
<tscreen><verb>
|
|
$ sort datafile.dat | uniq > newfile.dat
|
|
</verb></tscreen>
|
|
|
|
<bf/Problem/: 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?
|
|
|
|
<bf/Solution/:
|
|
|
|
<tscreen><verb>
|
|
$ find ~ -name "mypaper*"
|
|
</verb></tscreen>
|
|
|
|
Explanation: <tt/find/ is a very useful command that lists all the files
|
|
in a directory tree (starting from <tt/˜/ in this case). Its output
|
|
can be filtered to meet several criteria, such as <tt/-name/.
|
|
|
|
<bf/Problem/: I have a text file containing the word 'entropy' in this
|
|
directory, is there anything like <tt/SEARCH/?
|
|
|
|
<bf/Solution/: yes, try
|
|
|
|
<tscreen><verb>
|
|
$ grep -l 'entropy' *
|
|
</verb></tscreen>
|
|
|
|
<bf/Problem/: somewhere I have text files containing the word 'entropy', I'd
|
|
like to know which and where they are. Under VMS I'd use <tt/search entropy
|
|
[...]*.*;*/, but <tt/grep/ can't recurse subdirectories. Now what?
|
|
|
|
<bf/Solution/:
|
|
|
|
<tscreen><verb>
|
|
$ find . -exec grep -l "entropy" {} \; 2> /dev/null
|
|
</verb></tscreen>
|
|
|
|
Explanation: <tt/find ./ outputs all the file names starting from the
|
|
current directory, <tt/-exec grep -l "entropy"/ is an action to be
|
|
performed on each file (represented by <tt/{}/), <tt/\/
|
|
terminates the command. If you think this syntax is awful, you're right.
|
|
|
|
In alternative, write the following script:
|
|
|
|
<code>
|
|
#!/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
|
|
</code>
|
|
|
|
Explanation: <tt/grep/ works like <tt/search/, and combining it with
|
|
<tt/find/ we get the best of both worlds.
|
|
|
|
<bf/Problem/: 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...?
|
|
|
|
<bf/Solution/: nope. This is quicker:
|
|
|
|
<tscreen><verb>
|
|
$ awk 'NL > 2 {print $2, "\t", $5}' datafile.dat > newfile.dat
|
|
</verb></tscreen>
|
|
|
|
Explanation: the command <tt/awk/ is actually a programming language:
|
|
for each line starting from the third in <tt/datafile.dat/, print out
|
|
the second and fifth field, separated by a tab. Learn some <tt/awk/---it
|
|
saves a lot of time.
|
|
|
|
<bf/Problem/: I've downloaded an FTP site's <tt/ls-lR.gz/ 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.
|
|
|
|
<bf/Solution/:
|
|
|
|
<tscreen><verb>
|
|
$ zcat ls-lR.gz | awk ' $1 == "total" { i += $2 } END {print i}'
|
|
</verb></tscreen>
|
|
|
|
Explanation: <tt/zcat/ outputs the contents of the <tt/.gz/ file and pipes
|
|
to <tt/awk/, whose man page you're kindly requested to read ;-)
|
|
|
|
<bf/Problem/: I've written a Fortran program, <tt/myprog/, 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?
|
|
|
|
<bf/Solution/: a very short script. Make your program look for the data
|
|
file '<tt/mydata.dat/' and print the result on the screen (stdout), then
|
|
write the following script:
|
|
|
|
<code>
|
|
#!/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
|
|
</code>
|
|
|
|
<bf/Problem/: I want to replace `geology' with `geophysics' in all my
|
|
text files. Shall I edit them all manually?
|
|
|
|
<bf/Solution/: nope. Write this shell script:
|
|
|
|
<code>
|
|
#!/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
|
|
</code>
|
|
|
|
<bf/Problem/: 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?
|
|
|
|
<bf/Solution/: no, of course. Write this script:
|
|
|
|
<code>
|
|
#!/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
|
|
</code>
|
|
|
|
I hope these examples whetted your appetite...
|
|
|
|
|
|
<sect> Tips You Can't Do Without
|
|
|
|
<p>
|
|
|
|
<itemize>
|
|
|
|
<item> <bf/Command completion/: pressing <TAB> when issuing a command
|
|
will complete the command line for you. Example: you have to type
|
|
<tt>less this_is_a_long_name</tt>; typing in <tt>less thi<TAB></tt>
|
|
will suffice. (If you have other files that start with the same
|
|
characters, supply enough characters to resolve any ambiguity.)
|
|
|
|
<item> <bf/Back-scrolling/: pressing SHIFT--PAG UP (the grey key) allows
|
|
you to backscroll a few pages, depending on your PC's video memory.
|
|
|
|
<item> <bf/Resetting the screen/: if you happen to <tt/more/ or <tt/cat/
|
|
a binary file, your screen may end up full of garbage. To fix things,
|
|
blind type <tt/reset/ or this sequence of characters:
|
|
<tt/echo CTRL-V ESC c RETURN/.
|
|
|
|
<item> <bf/Pasting text/: in console, see below; in X, click and drag to
|
|
select the text in an <tt/xterm/ window, then click the middle button
|
|
(or the two buttons together if you have a two-button mouse) to paste.
|
|
|
|
<item> <bf/Using the mouse/: ask your sysadm to install <tt/gpm/, 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.
|
|
|
|
</itemize>
|
|
|
|
|
|
<sect> Reading VMS tapes from Linux
|
|
|
|
<p>
|
|
|
|
(This section was written by Mike Miller)
|
|
|
|
<sect1> Introduction
|
|
|
|
<p>
|
|
|
|
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.
|
|
|
|
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).
|
|
|
|
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.
|
|
|
|
|
|
<sect1> The Basics
|
|
|
|
<p>
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
If I execute these commands:
|
|
|
|
<tscreen><verb>
|
|
> 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
|
|
</verb></tscreen>
|
|
|
|
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.
|
|
|
|
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:
|
|
|
|
<tscreen><verb>
|
|
> mt -f $TAPE fsf 4
|
|
> dd if=$TAPE bs=16k of=ce66-2.evt
|
|
> mt -f $TAPE fsf 1
|
|
</verb></tscreen>
|
|
|
|
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).
|
|
|
|
|
|
<sect1> Some details
|
|
|
|
<p>
|
|
|
|
|
|
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.
|
|
|
|
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 in the
|
|
example, this is "HDR1CE66-2.EVT". The next field is the volume name again.
|
|
|
|
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.
|
|
|
|
<tscreen><verb>
|
|
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
|
|
</verb></tscreen>
|
|
|
|
For full details on the header and trailer format, see the DEC FILES11A
|
|
documentation (on the orange/grey wall - ask your local VMS folks :-).
|
|
|
|
|
|
<sect1> Comment on Block Size
|
|
|
|
<p>
|
|
|
|
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.
|
|
|
|
(Thanks to Wojtek Skulski (<url
|
|
url="skulski@nsrlc6.nsrl.rochester.edu">)
|
|
for pointing out setblk.)
|
|
|
|
|
|
<sect> The End
|
|
|
|
<p>
|
|
|
|
<sect1> Copyright
|
|
|
|
<p>
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
If you have questions, please contact Tim Bynum, the Linux HOWTO
|
|
coordinator, at <url url="linux-howto@sunsite.unc.edu"> via email.
|
|
|
|
|
|
<sect1> Disclaimer
|
|
|
|
<p>
|
|
|
|
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.
|
|
|
|
``From VMS to Linux HOWTO'' was written by Guido Gonzato, <url
|
|
url="guido ``at'' ibogeo.df.unibo.it">, and Mike Miller,
|
|
<url url="miller5@uiuc.edu"> 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.
|
|
|
|
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.
|
|
|
|
Enjoy,
|
|
|
|
Guido <tt/=8-)/
|
|
|
|
</article>
|