Subject: Linux-Development Digest #860
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date:     Sun, 26 Jun 94 17:13:06 EDT

Linux-Development Digest #860, Volume #1         Sun, 26 Jun 94 17:13:06 EDT

Contents:
  Re: cp truncate some dos files, why? (Bernd Laengerich)
  Re: DOSEMU and Novell (barryl)
  ??? curses ??? (atkkh@orion.alaska.edu)
  Anyone ported mxgdb (Motif GDB Interface) to linux ? (Ramiro Estrugo)
  Re: Xfree86 and WD cards (Jong-Min Park)
  Re: bad blocks (Rob Janssen)
  Re: Pathological program (Rob Janssen)
  Re: HD problems with 1.1.21 (Rob Janssen)
  Quirky idea: Remote Virtual Consoles (Byron A Jeff)
  Re: DOSEMU and Novell (H. Peter Anvin)
  proc/procps documentation? (David Fox)
  Re: Wine-940620 (Jeremy Bettis)
  Re: computer science (John Will)
  more breakage under 1.1.21 (rlogin xterms freeze up until being reset) (Jonathan King)
  TCP socket help (John F. Davis)

----------------------------------------------------------------------------

From: bernd_laengerich@p3.nightmare.sh.sub.de (Bernd Laengerich)
Subject: Re: cp truncate some dos files, why?
Date: 21 Jun 94 22:26:00 GMT

17.06.94 g609296  wrote:

g>>It seems that cp and other commands too will truncate some dos files
g>>such as msbackup.hlp (314236). When use cp to copy to another place,
g>>it changes to msbackup.hlp (248). So there are holes in the file that
g>>cp won't handle. Sorry if it sounds stupid as I am not a unix guru.
g>>Any work around for this. Someone can enlighten me on this.
g>
g>Me again :-)
g>
g>OK it seems the fault is conv=auto fstab. So someone can tell me what's
g>the problem for this case.

Maybe the reason is simple: conv=auto tries to determine the file type on  
the file extension, so .hlp should be considered to be an ascii text file.
Since the stupid dos convention says ascii text files have a CTRL-Z as end  
of file mark (as a relict to CP/M that has only fixed size of 128 byte  
blocks in the file size), maybe cp thinks it should stop copying when  
encountering a CTRL-Z and the file is considered ascii text.
In that case you could also have a problem an CR/LF conversion.

Its curious but dos' copy command handles this case correct, a disk to  
disk copy is done perfectly, only a copy to a character device (LPT1:)  
fails unless /b is stated in the command line.





Bye, Bernd

************************************************************************
**  Bernd_Laengerich@P3.Nightmare.sh.sub.org ||  Fido: 2:240/5329.3   **
************************************************************************

------------------------------

From: barryl@xs4all.hacktic.nl (barryl)
Crossposted-To: comp.os.linux.help
Subject: Re: DOSEMU and Novell
Date: 26 Jun 1994 15:33:18 +0200

Maybe a little off topic, but it is not necessary to use 2 ethernet cards 
: you can change the built-in node-address by changing the NET.CFG :

link driver NE2000
  NODE ADDRESS=123456789ABC

Barry.

------------------------------

From: atkkh@orion.alaska.edu
Subject: ??? curses ???
Date: Fri, 24 Jun 1994 02:08:38 GMT

curses and ncurses, what are they? how do I use them?
thanks

------------------------------

From: restrugo@netcom.com (Ramiro Estrugo)
Subject: Anyone ported mxgdb (Motif GDB Interface) to linux ?
Date: Sat, 25 Jun 1994 00:37:24 GMT


Hi,

  Has anyone ported mxgdb to Linux?  I treid some time ago and the
resulting binaries core-dumped as soon as executed...????

  Couldn't figure out what was going on ....

  Thanks for any info...

-Ramiro


 ##############################################################################
 #                               Ramiro Estrugo                               #
 #               Preferred Email       restrugo@netcom.com                    #
 #               Alternate Email       restrugo@scudc.scu.edu                 #
 ##############################################################################
-- 
 ##############################################################################
 #                               Ramiro Estrugo                               #
 #               Preferred Email       restrugo@netcom.com                    #
 #               Alternate Email       restrugo@scudc.scu.edu                 #
 ##############################################################################

------------------------------

From: jong-min@hprisc-71.cae.wisc.edu (Jong-Min Park)
Crossposted-To: comp.os.linux.admin,comp.os.linux.help
Subject: Re: Xfree86 and WD cards
Date: 23 Jun 1994 22:40:23 GMT

Marcin Krzysztof Porwit (mkporwit@tucson.Princeton.EDU) wrote:
> Hi,

> I have just looked at the WWW site at UNC to check if XFree v3.0
> supports my WD90C33 card, but the info they have there only refers to
> Xfree v2.1. Does anyone know if X now works with this graphics card,
> or if there is a patch out for it, or do I have to buy another
> graphics card?
> --
> In search of the eternal buzz... (and more caffeine)

Use X86_Mono for the time being. It works in Xfree 2.1 so there
should be no reason not to work in 3.0.

Now if only someone would give me good Xconfig timing numbers
for a Gateway 2000's monitor and Rocket video board... :-)
Currently the display looks bloated.

+-------- Jong-Min Park -=?B?EUC-KR?udrBvrnO?=-9ZA>9N-----------
| E-mail: jong-min@engr.wisc.edu
| Office: (608)-263-7784       266 ME Bldg
+-------- University of Wisconsin - Madison

------------------------------

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: bad blocks
Reply-To: pe1chl@rabo.nl
Date: Thu, 23 Jun 1994 16:24:01 GMT

In <2uaabh$327@dockmaster.phantom.com> rpritz@phantom.com (richard) writes:

>does linux test for bad disk sectors on installation or disk formating? 
>when i installed it (current version), it did not say it was marking bad 
>blocks.  freebsd and os/2 both find bad sectors on my harddrive.  linux 
>crashes, the other two don't, and i thought this may be the reason.

It depends.  You can pass the "-c" option to mkfs to have it check the
disk for defects while it builds the filesystem.  When you install your
system manually you can do this.  If you install using some prepared
shell script you are dependent on how this was setup in the script.
(or of course you could change the script)

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

------------------------------

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Pathological program
Reply-To: pe1chl@rabo.nl
Date: Thu, 23 Jun 1994 16:26:29 GMT

In <2ub9h3$bgc@darkstar.UCSC.EDU> haynes@cats.ucsc.edu (James H. Haynes) writes:


>I've got a C program which one of the profs wrote with some intentional
>mistakes in it - I guess as a test of the student's knowledge of C.
>When I fix enough of the mistakes to get it to compile with warnings only,
>and then run it,
>    If I run it under gdb I get a segment violation right away
>    If I run it "barefoot" (just run it, no gdb) it runs and runs and the
>machine (apparently) runs out of swap space and hangs up.
>There are no malloc()-s in the program, but it does have a mistake
>that lets it run forever.

>This is under Slackware 1.2 (Linux 1.0.8, libc.so.4.5.24) and also under
>Slackware 1.1.

>The nature of the mistake in the program is
>     scanf(%f %f v1, v2);
>where v1 and v2 are the variables themselves rather than the addresses
>of the variables as they should be for scanf.

>Seems to me the behavior of running out of swap space and hanging the
>system is wrong; is this a bug in the system? the C library?

You have to provide more detail...  Please post the entire program, if
not too large.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

------------------------------

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: HD problems with 1.1.21
Reply-To: pe1chl@rabo.nl
Date: Thu, 23 Jun 1994 16:31:55 GMT

In <2ubcbi$ini@msuinfo.cl.msu.edu> piper@logrus.cl.msu.edu (Gary Schrock) writes:

>Ok, I patched my kernel version 1.1.20 up to version 1.1.21 and all compiled
>well with no problems there that I noted.  When I went to reboot I got a
>message right after the partition check:

>hd.c: ST-506 interface disk with more than 16 heads detected, probably due to
>non-standard sector translation.  Giving up.
>(disk 1: cyl=100, sect=32, head=64)

>This message was repeated a second time, except the disk line was
>(disk 0: cyl=520, sect=32, head=64)    (undoubtably for the other hd)

>Linux continued to boot up fine, and seemed to work with no problems, although
>I switched back to 1.1.20 which was the last version that worked for me.

>System particulars:
>486dx33 w/ 8 Megs Ram
>Adaptec 1520 SCSI controller
>545 Meg Seagate drive (don't remember model number)
>105 Meg Quantam LPS-105 drive  (both are SCSI drives)

I think this is caused by a patch in 1.1.21 which was brought in to
enable detection of IDE drives on some systems that failed to detect
them before (IBM comes to mind)
Some additional code tells the system there is a drive, but later it
turns out to be bogus.  This is because you don't actually have IDE drives.
It is repeated twice because there can be 2 IDE drives.

I think the message can be safely ignored in this case, the system will
just not use the determined IDE disks and your SCSI disks are okay.

There is apparently room for improvement in this detection code.  It looks
like another case of "let's add this as it does not seem to break anything"
which is caught by the large base of different hardware installations :-)

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

------------------------------

From: byron@gemini.cc.gatech.edu (Byron A Jeff)
Subject: Quirky idea: Remote Virtual Consoles
Date: 26 Jun 1994 16:22:13 GMT

I've noticed that there are bunches of PC's that cannot run Linux.
Mostly 286's and early 386's with insufficient memory.

They don't have enough memory or horsepower to be used as remote X terminals.

However I find that having a remote console for a Linux box an interesting
idea.

This idea came to mind primarily because of DOSEMU. One might say "Well you
can just run DOS on the machine, or telnet to the Linux box". Well with the
first you don't have access to the Linux filesystems (except via the public
Domain NFS and/or Lanmanager clients) and you can't easily run multiple
instances of applications. See I run DOSEMU remotely much of the time. The
problem is that with terminals and X windows, key bindings prove to be
difficult. However I've found that things go rather well when the remote
terminal I use is the console of another Linux box. The Alt and function
keys work as expected and it should be possible to get the same console-like
display on a remote console as it is on the native one.


So I was thinking if it were possible to write a application that acts as
an additional virtual console for a Linux box that I could press the low
memory, low CPU machines I have access to into service. 

Any thoughts?

BAJ
-- 
---
Another random extraction from the mental bit stream of...
Byron A. Jeff - PhD student operating in parallel - And Using Linux!
Georgia Tech, Atlanta GA 30332   Internet: byron@cc.gatech.edu

------------------------------

Crossposted-To: comp.os.linux.help
From: hpa@solo.eecs.nwu.edu (H. Peter Anvin)
Subject: Re: DOSEMU and Novell
Reply-To: hpa@nwu.edu (H. Peter Anvin)
Date: Sun, 26 Jun 1994 15:42:06 GMT

Followup to:  <CrpE9H.n4H@aston.ac.uk>
By author:    evansmp@mb52112.aston.ac.uk (Mark Evans)
In newsgroup: comp.os.linux.help
> 
> : How do you do that from a NETX or VLM running in a DOS box? (dosemu)
> : You may use either packetdriver+PDETHER+IPXODI or the kernel IPX, at
> : your own option, as the IPX layer :-)
> 
> You need to rewrite the kernel code. Actually 2^47 possible machines
> is many more than you can actually have. You can simply make the "node"
> address the pid (32 bits), then you need a 32 bit "network" number, the
> IP address springs to mind.
> 

Actually the PID is 15 bits, not 32.  (Yes, that's 15, not 16.  Early
Linux kernels used a 16-bit PID, with PID's in the range 1 to 65535.
Contemporary ones use PID's in the range 1 to 32767, probably so that
pid_t can be "short" and fork() still return -1 as needed.)

        /hpa


-- 
INTERNET: hpa@nwu.edu               FINGER/TALK: hpa@ahab.eecs.nwu.edu
IBM MAIL: I0050052 at IBMMAIL       HAM RADIO:   N9ITP or SM4TKN
FIDONET:  1:115/511 or 1:115/512    STORMNET:    181:294/101
"Conserve energy"... like I have a choice!!  -- David Guidry

------------------------------

From: fox@graphics.cs.nyu.edu (David Fox)
Subject: proc/procps documentation?
Date: 25 Jun 1994 01:16:31 GMT

Many of the fields in /proc/*/stat, /proc/*/statm, /proc/*/maps,
and the link names in /proc/*/fd and /proc/*/mmap are not documented.
Similarly, the ps manual page that comes with procps does not
discuss what exactly the fields printed by ps -m mean and what
units they are expressed in.  Even some of the fields printed by
ps -l, ps -j, and ps -v are not mentioned.  I have looked at the
kernel source and there is no description there either; I could
probably guess given some hours of study, but if anyone has any
documentation of all this I would appreciate a copy.  Thanks,
--
David Fox                                               xoF divaD
NYU Media Research Lab                     baL hcraeseR aideM UYN

------------------------------

From: jbettis@cse.unl.edu (Jeremy Bettis)
Subject: Re: Wine-940620
Date: 23 Jun 1994 22:44:53 GMT

jrichard@cad1.uml.edu (John Richardson) writes:
>   Sorry should have said kernel is 1.1.21
>   Nick


>The 1.1.2x kernels break wine.  I'm not sure of the reason, perhaps
>if someone sees Bob they could ask him?  :)

>I noticed some changes in the singal handling and ldt changes as well
>in the 1.1.19 -> 1.1.20 patch.  

>Wine still works with 1.1.19.

1.1.12 started sending SIGBUS in certain situations.  Wine was expecting
SIGSEGV and has not had the handlers changed yet.  I am sure that the Wine
developers will figure out what is going on and repair it.  

I wonder how many programs that mught break, sending SIGBUS...  Espically
since SIGBUS is still defined as SIGUNUSED in /usr/include/linux/signals.h
--
Jeremy Bettis   -*- PGP Public key available -*-   University of Nebraska
INET: jbettis@cse.unl.edu               "Those who stand in the middle of the
UUCP: jerbo@tddi.UUCP,jeremy@hksys.com    road are often hit by passing cars."
Running Linux -- The Free Unix for i386/i486/Pentium machines. Ask me how.

------------------------------

Subject: Re: computer science
From: john.will@dscmail.com (John Will)
Date: Sun, 26 Jun 94 11:15:00 -0640

CR>For a programming job (entry level)  you need to know C++
CR>(in 1994.  By the time you get a degree everyone will be
CR>using something else:  Murphy's Law), and
CR>you need to be able to demonstrate your ability to handle 
CR>>30,000 line projects.  Many companies look for a diverse
CR>background, it's not enough to know C++ and UNIX, you should
CR>be proficient in at least three (at least one that the interviewer
CR>has never heard of, and two that he has) other operating systems
CR>(MS-DOS doesn't count unless you are looking for a loser job).

I am constantly amused by the carping about MS-DOS users in these
newsgroups, and the mis-information that is spread.  In point of fact,
you are so wrong as to be amusing.  If you are looking for a guaranteed
job, DOS/Windows is the place to look, there are far more opportunities
for work in that arena.  Would it be more fun to program in some other
environment?  Maybe, but it'll be harder to find employment...  I think
there are many operating environments that have a place in the world of
computing today, to dismiss the largest by far is ridiculous.  You should
really consider pulling your head out of the sand.  The first job you
take doesn't have to be for the rest of your life, the first order of
business is to hit the ground running.

CR>I know of a company that supports 20 different Operating systems,
CR>not to mention architectures, for their software.  They don't
CR>hire anyone unless they can C++ Up/down/across/sideways in a
CR>portable fashion.

And I'll bet that their major profits come from the MS-DOS/Windows 
products... :-)

------------------------------

From: king@cogsci.ucsd.edu (Jonathan King)
Subject: more breakage under 1.1.21 (rlogin xterms freeze up until being reset)
Date: 24 Jun 1994 01:13:02 GMT

The good news was that the new kernel 1.1.21 finally fixed our show-stopping
problem (linuxstations crashing under heavy network loads).  I don't know how
it happened, but we were really happy, until...

The bad news is that the new kernel has apparently introduced serious
problems with rlogins to other non-Linux boxes; after some random
number of keystrokes, these just freeze up solid until the connection
gets reset by the remote host.  This has happened to me at least 20
times yesterday and today (and our sys admin tells me it happened to
him, most notably through a terminal connection *through* a linux box
to a remote host; also, he did a "make clean" when he compiled
1.1.21).  It's possible that 1.1.20 also would have done this, but
that one crashed so much that we didn't get to find out.  (And we have
no networking stable kernel to back down to that I know of.)

Any ideas about what's wrong would be *very* much appreciated.  We
have been running Linux on three boxes in our lab for several weeks
now, hoping that the big bugs would soon be been shaken out, at which
point we were going to put it on at least 15 machines.  We were just
about to give up on Linux due to the network problems, and then those
got fixed (good news!).  But now this comes up; it's got to be really
simple.  So close, and yet...

jking


------------------------------

From: davis@clark.net (John F. Davis)
Subject: TCP socket help
Date: 26 Jun 1994 20:47:37 GMT

I've got a problem coordinating the closing of a socket.

I've got two programs, for the sake of discussion call them server and 
client.  The server program sets up a socket and does the listen.  The client
sets up his socket and does a connect.  Once, they are both connected both
processes fork.  So, I've got for processes.  In each case, the child 
processes write data to the socket, and the parent processes read data from
the socket.  This much of my code works.  What doesn't work is the closing
of the sockets.  I've tried close, shutdown, exit, and _exit.  None of them
do what I want.  I want each pair of processes to terminate when they are
through transfering data.  Instead, what I get, is the client terminates,
but the server doesn't.  I also, have a problem with the client getting
shutdown to soon.  (I think.)  The data that's supposed to be transffered
to the server is only partially there.  Any help will be appreciated.

Thanks.   John F. Davis

------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    sunsite.unc.edu				pub/Linux

End of Linux-Development Digest
******************************
