LDP
/
old-www
1
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity
old-www/LDP/LG/issue19/lg_tips19.html

813 lines
28 KiB
HTML
Raw Permalink Blame History

<!--startcut ==========================================================-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>More 2 Cent Tips & Tricks Issue 19</title>
</head>
<BODY BGCOLOR="#EEE1CC" TEXT="#000000" LINK="#0000FF" VLINK="#0020F0"
ALINK="#FF0000">
<!--endcut ============================================================-->
<H4>&quot;Linux Gazette...<I>making Linux just a little more fun!</I>
&quot;</H4>
<P> <hr> <P>
<!-- QUICK TIPS SECTION ================================================== -->
<center>
<H1><A NAME="tips"><IMG ALIGN=MIDDLE ALT="" SRC="../gx/twocent.gif">
More 2&#162; Tips!</A></H1> <BR>
Send Linux Tips and Tricks to <A HREF="mailto:gazette@ssc.com">
gazette@ssc.com
</A></center>
<p><hr><p>
<H3>Contents:</H3>
<ul>
<li><a HREF="./lg_tips19.html#rude">Rude Getty</a>
<li><a HREF="./lg_tips19.html#track">Keeping Track of File Size</a>
<li><a HREF="./lg_tips19.html#pack">What Packages Do I Need?</a>
<li><a HREF="./lg_tips19.html#sound">Sound Card Support</a>
<li><a HREF="./lg_tips19.html#install">InstallNTeX is Dangerous</a>
<li><a HREF="./lg_tips19.html#reply">Relpy to Dangerous InstallNTeX
Letter</a>
<li><a HREF="./lg_tips19.html#monitor">Monitoring An FTP Download</a>
<li><a HREF="./lg_tips19.html#ports">Programming Serial Ports</a>
<li><a HREF="./lg_tips19.html#grep">Grepping Files in a Directory Tree</a>
<li><a HREF="./lg_tips19.html#more">More Grepping Files</a>
<li><a HREF="./lg_tips19.html#still">Still More on Grepping Files</a>
<li><a HREF="./lg_tips19.html#files">More on Grepping Files in a Tree</a>
<li><a HREF="./lg_tips19.html#tree">Grepping</a>
<li><a HREF="./lg_tips19.html#zip">Untarring/Zip</a>
<li><a HREF="./lg_tips19.html#duplic">Hard Disk Duplication</a>
<li><a HREF="./lg_tips19.html#ncftp">Reply to ncftp</a>
<li><a HREF="./lg_tips19.html#pipes">Sockets and Pipes</a>
<li><a HREF="./lg_tips19.html#hex">Hex Dump</a>
<li><a HREF="./lg_tips19.html#hex2">More on Hex Dump</a>
<li><a HREF="./lg_tips19.html#zprotocol">Reply to Zprotocol</a>
</ul>
<P> <hr> <P>
<!--================================================================-->
<a name="rude"></a>
<H3><IMG ALIGN=BOTTOM ALT="" SRC="../gx/lil2cent.gif">
Rude Getty
</H3>
<P>
Date: Mon, 23 June 1997 21:12:23<br>
From: Heather Stern <a href="mailto:star@starshine.org">star@starshine.org</a><br>
<p>I have a fairly important UNIX box at work, and I have come across a good
trick to keep around.
<p>Set one of your console getty's to a nice value of very rude, -17 or worse.
That way if a disaster comes up and you have to use the console, it won't
take forever to respond to you (because of whatever went wrong).
<P> <hr> <P>
<!--================================================================-->
<a name="track"></a>
<H3><IMG ALIGN=BOTTOM ALT="" SRC="../gx/lil2cent.gif">
Keeping Track of File Size
</H3>
<P>
Date:Mon 16 June 1997 13:34:24<br>
From: Volker Hilsenstein <a href="mailto:vhilsens@aixterm1.urz.uni-heidelberg.de">vhilsens@aixterm1.urz.uni-heidelberg.de</a><br>
<p>Hello everyone,
I just read Bob Grabau's 2C-tip for keeping track of the size of
file. Since it is a bit inconvenient to type all these lines
each time you download something I wrote this little script:
<pre>
#!/bin/bash
# This script monitors the size of the files given
# on the command line.
while :
do
clear
for i in $@; do
echo File $i has the size `ls -l $i | tr -s " " | cut -f 5 -d " "` bytes;
done
sleep 1
done
</pre>
<p>Bye ... Volker
<P> <hr> <P>
<!--================================================================-->
<a name="pack"></a>
<H3><IMG ALIGN=BOTTOM ALT="" SRC="../gx/lil2cent.gif">
Reply to "What Packages do I Need?"
</H3>
<P>
Date: Tue 24 June 1997 11:15:56<br>
From: Michael Hammel, <a href="mailto:mjhammel@long.emass.com">mjhammel@long.emass.com</a>
<P>
You asked about what packages you could get rid of and mentioned that you
had AcceleratedX and that because of this you "can get rid of a lot off the
X stuff". Well, thats not really true. AcceleratedX provides the X
server, but you still need to hang onto the X applications
(/usr/X11R6/bin/*) and the libraries and include files (/usr/X11R6/lib and
/usr/X11R6/include) if you wish to compile X applications or run X binaries
that require shared libraries.
<p>Keep in mind that X is actually made up of three distinct parts: the
clients (the X programs you run like XEmacs or Netscape or xterm), the
server (the display driver that talks to your video adapter), and the
development tools (the libs, header files, imake, etc). General users
(non-developers) can forego installation of the development tools but need
to make sure to install the runtime libraries. Each Linux distribution
packages these differently, so just be careful about which ones you remove.
<p>One caveat: I used to work for Xi Graphics, but that was over a year and a
half ago. Although I keep in touch with them, I haven't really looked at
the product line lately. Its possible they ship the full X distributions
now, but I kind of doubt it. If they are shipping the full X distributions
(clients, server, development tools) then disregard what I've said.
<p>Hope this helps.<br>
--
Michael J. Hammel
<P> <hr> <P>
<!--================================================================-->
<a name="sound"></a>
<H3><IMG ALIGN=BOTTOM ALT="" SRC="../gx/lil2cent.gif">
Sound Card Support
</H3>
<P>
Date: Mon 24 June 1997: 11:16:34<br>
From: Michael Hammel, <a href="mailto:mjhammel@long.emass.com">mjhammel@long.emass.com</a>
<p>With regards to your question in the LG about support for the MAD16 Pro from
Shuttle Sound System under Linux, you might consider the OSS/Linux product
from 4Front-Techologies. The sound drivers they supply support a rather
wide range of adapters. The web paget http://www.4front-tech.com/osshw.html
gives a list of what is and isn't supported. The Shuttle Sound System 48 is
listed as being supported as well as generic support for the OPTi 82C929
chipset (which you listed as the chipset on this adapter).
<p>This is commercial software but its only $20. I've been thinking of
getting it myself. I have used its free predecessor, known at times as
OSS/Lite or OSS/Free, and found it rather easy to use. I just haven't
gotten around to ordering (mostly cuz I never seem to have time for doing
installation or any other kind of admin work). I will eventually.
<p>4Front's web site is at http://www.4front-tech.com.
<p>Hope this helps.
<p>
--
Michael J. Hammel
<P> <hr> <P>
<!--================================================================-->
<a name="install"></a>
<H3><IMG ALIGN=BOTTOM ALT="" SRC="../gx/lil2cent.gif">
InstallNTeX is Dangerous
</H3>
<P>
Date: Fri 06 June 1997 12:31:14<br>
From: Frank Langbein <a href="mailto:langbein@mathematik.uni-stuttgart.de">langbein@mathematik.uni-stuttgart.de</a><br>
<p>Dear James:<br>
<I>On Fri, 6 Jun 1997, James wrote:</I><br>
<p>You have still
<pre> make_dir " LOG" "$VARDIR/log" $DOU 1777
make_dir " TMP-FONTS" "$VARDIR/fonts" $DOU 1777</pre>
<p>If I hadn't (now) commented-out your
<pre>(cd "$2"; $RM -rf *)</pre>
then both my /var/log/* and /var/fonts/* files and directories would have
been deleted!
<p>Actually VARDIR should also be a directory reserved for NTeX only (something
like /var/lib/texmf). Deleting VARDIR/log is not really necessary unless
someone has some MakeTeX* logs in there which are not user writable. Any pk
or tfm files from older or non-NTeX installations could cause trouble later.
Sometimes the font metrics change and if there are some old metrics used with
a new bitmap or similar the resulting document might look rather strange.
Further log and fonts have to be world writable (there are ways to prevent
this, but I haven't implemented a wrapper for the MakeTeX* scripts yet), so
placing them directly under /var is not really a good idea. I am aware that
the documentation of the installation procedure is minimal which makes it
especially hard to select the directories freely.
<p>The real problem is that allowing to choose the directories freely. Selecting
the TDS or the Linux filesystem standard is rather save and at most any other
TeX files are deleted. The only real secure option would be to remove the free
choice and only offer the Linux filesystem standard, the one from web2c 7.0
which is also TDS conform and a TDS conform sturcutre in a special NTeX
directory. The free selection would not be accessible for a new user. I could
add some expert option which still allows to use a totally free selection.
Additional instead of deleting the directories they could be renamed.
<p>There are plans for a new installation procedure, also supporting such things
as read only volumes/AFS, better support for multiple platform installation,
etc. This new release will not be available before I managed to implement all
the things which were planed for 2.0. But that also means that there will
probably be no new release this year as I have to concentrate on my studies.
Nevertheless I will add a warning to the free selection in InstallNTeX. That's
currently the only thing I can do without risking to add further bugs to
InstallNTeX. Considering that my holiday starts next week I can't do more this
month.
<p>BTW, on another point, I had difficulty finding what directory was searched
for the packages to be installed. Only in the ntex-guide, seemingly buried,
is there:
<p>This is caused by different ways to look for the package in NTeX-install, the
text version of InstallNTeX and the Tcl/Tk version of InstallNTeX. Therefore
you get some warnings even if NTeX-install would be able to install the
packages. The minimal documentation is one of the real big drawbacks of NTeX.
I'm currently working on a complete specification for the next release which
will turn into a real documentation.
<p>Thanks for pointing out the problems with the free selection of that paths. So
far I concentrated on setting the installation paths to non-existing
directories.
<p>
Regards,<br>
Frank
<P> <hr> <P>
<!--================================================================-->
<a name="reply"></a>
<H3><IMG ALIGN=BOTTOM ALT="" SRC="../gx/lil2cent.gif">
Reply to Dangerous InstallNTeX Letter
</H3>
<P>
To: Frank Langbein, <a href="mailto:langbein@mathematik.uni-stuttgart.de">langbein@mathematik.uni-stuttgart.de</a><br>
Date: Sat, 07 Jun 1997 10:11:06 -0600<br>
From: James <a href="mailto:james@albion.glarp.com">james@albion.glarp.com</a>
<p>Dear Frank:<br>
The hidden application of the operation <pre>rm -rf *</pre> to the unpredictable and
unqualified input from a broad base of naive users is highly likely to
produce unexpected and undesired results for some of these users. This is
the kind or circumstance more usually associated with a "prank". If this is
_not_ your intent, then further modifications to the script "InstallNTeX"
are required.
<p>The script functions at issue include: mk_dirchain() ($RM -f $P), make_dir()
($RM -rf * and $RM -f "$2"), make_tds_ln() ($RM -f "$3"), and link_file()
($RM -rf "$2"). The impact of the operations when using unexpected
parameters, from misspellings or misinterpretations, for instance, should be
considered.
<p>You might simply replace these operations with an authorization dialog, or
you could create a dialog with several recovery options. (For the moment, I
have replaced them with `echo "&lt;some &lt;warning parm&gr;"'.)
<p>James G. Feeney
<P> <hr> <P>
<!--================================================================-->
<a name="monitor"></a>
<H3><IMG ALIGN=BOTTOM ALT="" SRC="../gx/lil2cent.gif">
Monitoring An FTP Download
</H3>
<P>
Date: Tue, 10 Jun 1997 19:54:25 +1000 (EST)<br>
From: Nathan Hand <a href="mailto:Nathan.Hand@anu.edu.au">Nathan.Hand@anu.edu.au</a><br>
<p>I saw the recent script someone posted in the 2c column to monitor
an ftp download using the clear ; <code>ls -l</code> ; sleep trick. I'd just like
to point out there's A Better Way.
<P>Some systems will have the "watch" command installed. This command
works pretty much like the script, except it uses curses and buffers
for lightning fast updates. You use it something like
<pre> watch -n 1 ls -l</pre>
<p>And it prints out the current time, the file listing, and it does
the refreshes so fast that you don't see the <code>ls -l</code> redraws. I think
it looks a lot slicker, but otherwise it's the same as the script.
<p>I don't know where the watch command comes from. I'm using a stock
standard Red Hat system (4.0) so hopefully people with similar setups
will also have a copy of this nifty little tool.
<P> <hr> <P>
<!--================================================================-->
<a name="ports"></a>
<H3><IMG ALIGN=BOTTOM ALT="" SRC="../gx/lil2cent.gif">
Programming Serial Ports
</H3>
<P>
Date: Wed 18 June 1997 14:15:23<br>
From: Tom Verbeure <a href="mailto:to_verbeure@mietec.be">to_verbeure@mietec.be</a>
<p>Hello,
A few days ago, I had to communicate using the serial port of a Sun workstation.
A lot of information can be found here:
<a href="http://www.stokely.com/stokely/unix.serial.port.resources">http://www.stokely.com/stokely/unix.serial.port.resources</a>
and here:
<a href="http://www.easysw.com/~mike/serial">http://www.easysw.com/~mike/serial</a>
<P>Reading chapters 3 and 4 of that last page, can do wonders. It took me about 30
minutes to communicate with the machine connected to the serial port. The code
should work on virtually any unix machine.
<P>Hope this helps,
Tom Verbeure
<P> <hr> <P>
<!--================================================================-->
<a name="grep"></a>
<H3><IMG ALIGN=BOTTOM ALT="" SRC="../gx/lil2cent.gif">
Another Way of Grepping Files in a Directory Tree
</H3>
<P>
Date: Thu 12 June 15:34:12<br>
From: Danny Yarbrough <a href="mailto:danny@interactive.visa.com">danny@interactive.visa.com</a>
<p>That's a good tip. To work around the command line length limitation,
you can use xargs(1):
<pre>
find . -name "\*.c" -print | xargs grep foo
</pre>
this builds a command line containing "grep foo" (in this case), plus as
many arguments (one argument for each line of its standard input) as it
can to make the largest (but not too long) command line it can. It then
executes the command. It continues to build command lines and executing
them until it reaches the end of file on standard input.
<p>(Internally, I suppose xargs doesn't build command lines, but an array
of arguments to pass to one of the exec*(2) family of system calls. The
concept, however is the same).
<p>xargs has a number of other useful options for inserting arguments into
the middle of a command string, running a command once for each line of
input, echoing each execution, etc. Check out the man page for more.
<p>Cheers!
Danny
<P> <hr> <P>
<!--================================================================-->
<a name="more"></a>
<H3><IMG ALIGN=BOTTOM ALT="" SRC="../gx/lil2cent.gif">
More Grepping Files
</H3>
<P>
Date: Mon 16 June 1997 08:45:56<br>
From: Alec Clews <a href="mailto:Alec@tca.co.uk">Alec@tca.co.uk</a>
<pre>grep foo `find . -name \*.c -print`</pre>
<p>The only caveat here is that UNIX is configured to limit max chars in a
command line and the "find" command may generate a list of files too
huge for shell to digest when it tries to run the grep portion as a
command line. Typically this limit is 1024 chars per command line.
<p>You can get around this with
<pre>find . -type f -name \*.c -exec grep foo {} /dev/null \;</pre>
<p>Notes:
The <code>-type f</code> skips directories (and soft links, use <code>-follow</code> if
needed) that end with a <code>c</code>
<p>The /dev/null is required to make grep display the name of the file
it's searching. grep only displays the file name *and* the search string
when there are multiple files to search, and /dev/null is a 0 length
file.
<p>Regards,<br>
Alec
<P> <hr> <P>
<!--================================================================-->
<a name="still"></a>
<H3><IMG ALIGN=BOTTOM ALT="" SRC="../gx/lil2cent.gif">
Still More On Grepping Files
</H3>
<P>
Date: Sat 14 June 1997 10:57:34<br>
From: Rick Bronson <a href="mailto:rick@efn.org">rick@efn.org</a>
<p>Here is similiar way to grep for files in a directory tree. This
method uses xargs and as such does not suffer from the max chars in
a command line limit.
<pre>sea ()
{
find . -name "$2" -print | xargs grep -i "$1"
}</pre>
<p>I've defined it as a function in my .bashrc file, you would use it
like:
<pre>sea "search this string" '*.[ch]'</pre>
<p>Rick
<P> <hr> <P>
<!--================================================================-->
<a name="tree"></a>
<H3><IMG ALIGN=BOTTOM ALT="" SRC="../gx/lil2cent.gif">
Grepping
</H3>
<P>
Date: Thu 19 June 1997 09:29:12<br>
From: David Kastrup <a href="mailto:dak@neuroinformatik.ruhr-uni-bochum.de">dak@neuroinformatic.ruhr-uni-buchum.de</a><BR>
<I>Reply to "Grepping Files in a Tree Directory"</I>
<p>Well right. That's why most solutions to this problem are given
using the xargs command which will construct command lines of
appropriate size.
<p>You'd write
<pre>find . -name \*.c -print|xargs grep foo</pre>
for this. This can be improved somewhat, however. If you suspect
that you have files containing newlines or otherwise strange
characters in them, try
<pre>find . -name \*.c -print0|xargs -0 grep foo --</pre>
This will use a special format for passing the file list from find to
xargs which can properly identify all valid filenames. The <tt>--</tt> tells
grep that even strange file names like "-s" are to be interpreted as
file names.
<p>Of course, we would want to have a corresponding file name listed even
if xargs calls a single grep in one of its invocation. We can manage
this with
<pre>find . -name \*.c -print0|xargs -0 grep foo -- /dev/null</pre>
This will have at least two file names for grep (/dev/null and one given by
xargs), so grep will print the file name for found matches.
<p>The <tt>--</tt> is a good thing to keep in mind when writing shell scripts.
Most of the shell scripts searching through directories you find
flying around get confused by file names like "-i" or
"xxx\
yyy"
and similar perversities.
<p>David Kastrup
<P> <hr> <P>
<!--================================================================-->
<a name="files"></a>
<H3><IMG ALIGN=BOTTOM ALT="" SRC="../gx/lil2cent.gif">
More on Grepping Files in a Tree
</H3>
<P>
Date: Mon 02 June 1997 15:34:23<br>
From: Chris Cox <a href="mailto:ccox@central.beasys.com">ccox@central.geasys.com</a>
<p>My favorite trick for look for a string (or strings - egrep) in
a tree:
<pre>$ find . -type f -print | xargs file | grep -i text |
cut -f1 -d: | xargs grep pattern</pre>
<p>This is a useful technique for other things...not just
grepping.
<P> <hr> <P>
<!--================================================================-->
<a name="zip"></a>
<H3><IMG ALIGN=BOTTOM ALT="" SRC="../gx/lil2cent.gif">
Untarring/Zip
</H3>
<P>
Date: Sun 22 June 1997 13:23:14<br>
From: Mark Moran <a href="mailto:mmoran@mmoran.com">mmoran@mmoran.com</a>
<p>I read the following 2-cent tip and was excited to think that I've
finally reached a point in my 'linux' expertise I COULD contribute a
2-cent tip! I typically run:<br>
<pre>tar xzf foo.tar.gz</pre><br>
to unzip and untar a program. But as Paul mentions the directory
structure isn't included in the archive and it dumps in your current
directory. Well before I do the above I run:<br>
<pre>tar tzf foo.tar.gz</pre><br>
<p>This will dump out to your console what going to be unarchived easily
allowing you to see if there's a directory structure!!!!
<p>
Mark
<P> <hr> <P>
<!--================================================================-->
<a name="duplic"></a>
<H3><IMG ALIGN=BOTTOM ALT="" SRC="../gx/lil2cent.gif">
An Addition to Hard Disk Duplication (LG #18)
</H3>
<P>
Date: Thu 12 June 1997 15:34:32<br>
From: Andreas Schiffler <a href="mailto:schiffler@zkm.de">schiffler@zkm.de</a><br>
<p>Not suprisingly, Linux can do that of course for free and - even from a
floppy bootimage for example (i.e. Slackware bootdisk console).
<p>For identical harddrives the following will do the job:
<pre>cat /dev/hda &gt;/dev/hdb</pre>
<p>For non-identical harddrives one has to repartition the target first:
<table>
<tr>
<td>fdisk /dev/hda</td> <td>record the partitions (size, type)</td>
</tr>
<tr>
<td>fdisk /dev/hdb</td> <td>create same partitions</td>
</tr>
<tr>
<td>cat /dev/hda1 &gt;/dev/hdb1</td> <td>copy partitions</td>
</tr>
<tr>
<td>cat /dev/hda2 &gt;/dev/hdb2</td>
</tr>
</table>
...
<p>To create image files, simply redirect the target device to a file.
<pre>cat /dev/hda &gt;image-file</pre>
<p>To reinstall the MBR and lilo, just boot with a floppy using parameters
that point to the root partition (as in LILO&gt; linux root=/dev/hda1) and
rerun lilo from within Linux.
<p>Have fun<br>
Andreas
<P> <hr> <P>
<!--================================================================-->
<a name="ncftp"></a>
<H3><IMG ALIGN=BOTTOM ALT="" SRC="../gx/lil2cent.gif">
Reply to ncftp (LG #18)
</H3>
<P>
Date: Fri 20 June 1997 14:23:12<br>
From: Andrew M. Dyer, <a href="mailto:adyer@mcs.com">adyer@mcs.com</a>
<p>To monitor an ftp session I like to use ncftp which puts up a nice
status bar. It comes in many linux distributions. When using the
standard ftp program you can also use the <pre>hash</pre> command which prints
a <pre>#</pre> every 1K bytes received. Some ftp clients also have the <pre>bell</pre>
command which will send a bell character to your console for every file
transferred.
<p>For grepping files in a directory tree I like to use the -exec
option to find. The syntax is cryptic, but there is no problem with
overflowing the shell argument list. A version of the command shown in
#18 whould be like this:
<pre>find . -name \*.c -exec grep foo {} /dev/null \;</pre>
(note the /dev/null forces grep to print the filename of the matched
file). Another way to do this is with the mightily cool xargs
program, which also solves the overflow problem and its a bit easier to
remember:
<pre>find . -name \*.c -print | xargs grep foo /dev/null</pre>
(this last one is stolen from "UNIX Power Tools" by Jerry Peek, Tim
O'Reilly and Mike Loukides - a whole big book of 2 cent tips.
<p>For disk duplication we sometimes use a linux box with a secondary
IDE controller, and use <pre>dd</pre> to copy the data over.
<pre>dd if=/dev/hdc of=/dev/hdd bs=1024k</pre>
this would copy the contents of /dev/hdc to /dev/hdd. The bs=1024k
tells linux to use a large block size to speed the transfer.
<P> <hr> <P>
<!--================================================================-->
<a name="pipes"></a>
<H3><IMG ALIGN=BOTTOM ALT="" SRC="../gx/lil2cent.gif">
Sockets and Pipes
</H3>
<P>
Date: Thu, 12 Jun 1997 23:22:38 +1000 (EST)
From: Waye-Ian Cheiw, <a href="mailto:itchy@jaguar.snafu.com">itchy@jaguar.snafu.com</a>
<p>Hello!
<p>Here's a tip!
<p>Ever tried to pipe things, then realised what you want to pipe to is on another
machine?
<pre>spiffy $ sort &lt; file
sh: sort: command not found
spiffy $ # no sort installed here! gahck!</pre>
<p>Try "socket", a simple utility that's included in the Debian distribution.
Socket is a tool which can treat a network connection as part of a pipe.
<pre>spiffy $ cat file
c
b
a
spiffy $ cat file | socket -s 7000 & # Make pipe available at port 7000.
spiffy $ rlogin taffy
taffy $ socket spiffy 7000 | sort # Continue pipe by connecting to spiffy.
a
b
c</pre>
<p>It's also very handy for transferring files and directories in a snap.
<pre>spiffy $ ls -F
mail/ project/
spiffy $ tar cf - mail project | gzip | socket -qs 6666 &
spiffy $ rlogin taffy
taffy $ socket spiffy 6666 | gunzip | tar xf -
taffy $ ls -F
mail/ project/</pre>
<p>The -q switch will close the connection on an end-of-file and conveniently
terminate the pipes on both sides after the transfer.
<p>It can also connect a shell command's input and output to a socket. There is
also a switch, -l, which restarts that command every time someone connects to
the socket.
<pre>spiffy $ socket -s 9999 -l -p "fortune" &
spiffy $ telnet localhost 9999
"Baseball is ninety percent mental. The other half is physical."
Connection closed by foreign host. </pre>
Will make a cute service on port 9999 that spits out fortunes.
<p>-- Ian!!
<P> <hr> <P>
<!--================================================================-->
<a name="hex"></a>
<H3><IMG ALIGN=BOTTOM ALT="" SRC="../gx/lil2cent.gif">
Hex Dump
</H3>
<P>
Date: Tue 24 June 1997 22:54:12<br>
From: Arne Wichmann <a href="mailto:aw@math.uni-sb.de">aw@math.uni-sb.de</a>
<p>Hi.
<p>One of my friends once wrote a small vi-compatible hex-editor. It can be
found (as source) under vieta.math.uni-sb.de:/pub/misc/hexer-0.1.4c.tar.gz
<P> <hr> <P>
<!--================================================================-->
<a name="hex2"></a>
<H3><IMG ALIGN=BOTTOM ALT="" SRC="../gx/lil2cent.gif">
More on Hex Dump
</H3>
<P>
Date: Wed, 18 Jun 1997 10:15:26 -0700<br>
From: James Gilb <a href="mailto:p27451@am371.geg.mot.com">p27451@am371.geg.mot.com</a>
<p>I liked your gawk solution to displaying hex data. Two things (which
people have probably already pointed out to you).
<ol>
<li>If you don't want similar lines to be replaced by * *, use the -v
option to hexdump. From the man page:
<p>-v The -v option causes hexdump to display all input data.
Without the -v option, any number of groups of output lines,
which would be identical to the immediately preceding group
of output lines (except for the input offsets), are replaced
with a line comprised of a single asterisk.
<li>In emacs, you can get a similar display using ESC-x hexl-mode. The
output looks something like this:
<pre>
00000000: 01df 0007 30c3 8680 0000 334e 0000 00ff ....0.....3N....
00000010: 0048 1002 010b 0001 0000 1a90 0000 07e4 .H..............
00000020: 0000 2724 0000 0758 0000 0200 0000 0000 ..'$...X........
00000030: 0000 0760 0004 0002 0004 0004 0007 0005 ...`............
00000040: 0003 0003 314c 0000 0000 0000 0000 0000 ....1L..........
00000050: 0000 0000 0000 0000 0000 0000 2e70 6164 .............pad
00000060: 0000 0000 0000 0000 0000 0000 0000 0014 ................
00000070: 0000 01ec 0000 0000 0000 0000 0000 0000 ................
00000080: 0000 0008 2e74 6578 7400 0000 0000 0200 .....text.......
00000090: 0000 0200 0000 1a90 0000 0200 0000 2a98 ..............*.
</pre>
(I don't suppose it is supprising that emacs does this, after all, emacs
is not just and editor, it is its own operating system.)
</ol>
<P> <hr> <P>
<!--================================================================-->
<a name="zprotocol"></a>
<H3><IMG ALIGN=BOTTOM ALT="" SRC="../gx/lil2cent.gif">
Reply to Z Protocol
</H3>
<P>
Date: Mon 09 June 1997 19:34:54<br>
From: Gregor Gerstmann <a href="mailto:gerstman@tfh-berlin.de">gerstman@tfh-berlin.de</a>
<p>In reply to my remarks regarding file transfer with the z protocol
in LinuxGazette issue17, April 1997, I received an e-mail that may
be interesting to others too:
<p>Hello!
<p>I noticed your article in the Linux Gazette about the sz command, and really
don't think you need to split up your downloads into smaller chunks.
<p>The sz command uses the ZMODEM protocol, which is built to handle transmission
errors. If sz reports a CRC error or a bad packet, it does not mean that the
file produced by the download will be tainted. sz automatically retransmits
bad packets.
<p>If you have an old serial UART chip ( 8250 ), then you might be getting
intermittent serial errors. If the link is unreliable, then sz may spend most
of its time tied up in retransmission loops.
<p>In this case, you should use a ZMODEM window to force the sending end to expect
an `OK' acknowledgement every few packets.
<pre> sz -w1024</pre>
Will specify a window of 1024 bytes.
<p>
-- Ian!!
<P> <hr> <P>
<!--================================================================-->
<center>Published in Linux Gazette Issue 19, July 1997</center>
<P> <hr> <P>
<!--================================================================-->
<A HREF="./index.html"><IMG SRC="../gx/indexnew.gif" ALT="[ TABLE OF
CONTENTS ]"></A> <A HREF="../index.html"><IMG SRC="../gx/homenew.gif"
ALT="[ FRONT PAGE ]"></A> <A HREF="./lg_mail19.html"><IMG SRC="../gx/back2.gif" ALT=" Back "></A>
<A HREF="./lg_bytes19.html"><IMG SRC="../gx/fwd.gif" ALT=" Next "></A>
<P> <hr> <P>
<h5>This page maintained by the Editor of <I>Linux Gazette</I>,
<A HREF="mailto: gazette@ssc.com">gazette@ssc.com</A><BR>
Copyright &copy; 1997 Specialized Systems Consultants, Inc. </H5>
<P>
<!--startcut ==========================================================-->
</body>
</html>
<!--endcut ============================================================-->
Reference in New Issue View Git Blame Copy Permalink