NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/unix/wizards/4865

Internet Message Format | 1992-11-24 | 62.0 KB

Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!lhc!adm!news
From: [e-mail] (SMTP MAILER)
Newsgroups: comp.unix.wizards
Subject: Mail not delivered yet, still trying
Message-ID: <[e-mail]>
Date: 23 Nov 92 22:15:07 GMT
Sender: [e-mail]
Lines: 1716


 ----Mail status follows----
Have been unable to send your mail to <[e-mail]>,
will keep trying for a total of eight days.
At that time your mail will be returned.

 ----Transcript of message follows----
Date: 22 Nov 92 09:14:00 EST
From: [e-mail]
Subject: UNIX-WIZARDS Digest  V17#001
To: "DGRAY" <[e-mail]>

Return-Path: <[e-mail]>
Received: from SEM.BRL.MIL by milo.starlab.csc.com with SMTP ;
          Sun, 22 Nov 92 09:13:04 EST
Received: from SEM.BRL.MIL by SEM.BRL.MIL id ab25264; 21 Nov 92 7:28 EST
Received: from sem.brl.mil by SEM.BRL.MIL id aa25212; 21 Nov 92 7:15 EST
Date:       Sat, 21 Nov 92 07:14:45 EST
From:       The Moderator (Mike Muuss) <[e-mail]>
To:         [e-mail]
Reply-To:   [e-mail]
Subject:    UNIX-WIZARDS Digest  V17#001
Message-ID:  <[e-mail]>

UNIX-WIZARDS Digest          Sat, 21 Nov 1992              V17#001

Today's Topics:
                        TLI and non-blocking I/O
                 Re: Detecting if running under chroot
              Broadcast detection from the socket layer ?
                         The Problem with UNIX
                       Re: The Problem with UNIX
      An FTP site to get the latest GCC Compiler for DOS - PLEASE!
                            Re: SUN NFS sync
                                 RPCGEN
                               Re: RPCGEN
                       Keyboard hit in C programs
                     Re: Keyboard hit in C programs
           Re: Process 'purge' revisited.. Unix missing this?
     Re: Q: Proper client/server protocol w.r.t. socket read/writes
                          Re: termcap/terminfo
         >>TAR file on tape distroyed, are files recoverable?<<
                     Need a raw ethernet interface
                     applications using p-threads!!
                   ISC 3.0 Terminfo database question
                   HELP! problem with tar PC <-> SUN
                        ksh argument interpreter
                               libg++2.2
                       Need help with "makefile"
                 Any TeX (compilation) Gurus out there?
                  Solaris 2.0/2.1 Realtime programming
                           Getty Source Code

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

From: Paul Greenspan <[e-mail]>
Subject: TLI and non-blocking I/O
Keywords: TLI, SVR4, non_blocking
Date: 7 Nov 92 17:19:03 GMT
Followup-To: comp.protocols.tcp-ip
To:       [e-mail]

Below is a description of a problem that we are having with some of
our network code.  I would appreciate any help that I could get.

Background:
 -----------
We have taken a rather complicated server that was developed with BSD
sockets and converted it to use TLI.  The server has to handle many
things at once (with threads) so it is important that we use non-blocking
endpoints.  So to avoid blocking on a t_listen() call waiting
for a connection request, we wait for poll() to tell us that
there is a connection request and then try to call t_listen().

Here is a description of the behavior of some of our TLI code, as
executed under SVR4.0.3:

[SERVER]
1. The server calls t_open(DEV_TCP, O_RDWR, 0).
2. The server calls ioctl(tfd, FIONBIO, &non_blocking)
   to set the TLI endpoint into non-blocking mode.
3. The server calls t_bind(tfd, &req, &ret) to offer
   a channel to clients. The bound address is selected
   by the transport provider (req.addr.len is 0) and
   gets recorded so clients can be told on what address
   to t_connect.
4. The server calls poll() to wait for connection requests.

            [CLIENT]
            5. A client initiates a connection request by first
               calling t_open(DEV_TCP, O_RDWR, 0).
            6. The client then calls t_bind(tfd, 0, 0)
            7. The client calls t_connect(tfd, connreq, 0), where
               connreq has been t_alloc'd, then set up with the
               correct address, no options, and no user data.

               NOTE: The client's t_connect will later appear to
               succeed. (Weird.)

[SERVER]
8. The server is notified of the connection request
   by poll(). t_look(tfd) returns T_LISTEN (1).
9. The server calls t_listen(tfd, callptr), where
   callptr has been t_alloc'd but otherwise left alone.
   This call fails, returning -1. t_errno is
   TNOTSUPPORT (18).

            [CLIENT]
            5.  A client initiates a connection request by first
                calling t_open(DEV_TCP, O_RDWR, 0).
            10. Here's the weird part. The client's t_connect
                call now returns and indicates all is well.
                So the client code keeps going.
            11. The client calls ioctl(tfd, I_POP, 0)
            12. The client calls ioctl(tfd, I_PUSH, "tirdwr")
            13. The client calls write(tfd, buf, sizeof(u_long)).
                This succeeds!
            14. The client calls read(tfd, buf, sizeof(u_long)).
                This is where the client finally sees something
                is wrong, as the read call returns 0.

--
Paul Greenspan              [e-mail]
Tivoli Systems              6034 West Courtyard, Suite 210
Austin, Texas  78730        [phone]  /  FAX [phone]

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

From: Lionel Cons <[e-mail]>
Subject: Re: Detecting if running under chroot
Date: 9 Nov 92 09:04:04 GMT
Sender: USENET News System <[e-mail]>
To:       [e-mail]

I know a way to see if I run under chroot on my OS (HP-UX) and I think
it should work on many different platforms: the inode number of / is
always 2, so 'ls -id' will tell me...
--

Lionel Cons

+------- CERN - European Laboratory for Particle Physics -------+
| E-mail: [e-mail]                                   |
| Earth-mail: CN/SW/WS, CERN, CH-1211 GENEVE 23, Switzerland    |
| Phone: [phone]              Fax: [phone]    |
+---------------------------------------------------------------+

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

From: Oleg Kibirev <[e-mail]>
Subject: Re: Detecting if running under chroot
Date: 9 Nov 92 09:57:47 GMT
Nntp-Posting-Host: gd.cs.csufresno.edu
To:       [e-mail]

In article <mark.721121538@coombs> [e-mail] (Mark) writes:
>
>I was reading some of the security texts on research.att.com and it mentioned
>that it was possible to detect if one was running under a chroot call.
>
>If the file system is duplicated etc how would you check? Make a massive file
>on the (apparent) root disk (/tmp for instance) and do a 'df' to make sure
>it's the root disk?

What about checking i-node number of / ? Just checked a few systems and it appears
to be the same:

gd:~> ls -di /
     2 //

Of course, this  can miserably fail with  NFS where root  is  actually
/export/root. What is actually checked is weather current root == root
of *some*  filesystem. Why would   program need to   check if  it runs
chrooted?

Oleg

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

From: Tim Barnett - programmer <[e-mail]>
Subject: Re: Detecting if running under chroot
Date: 10 Nov 92 18:15:28 GMT
Sender: Network News System <[e-mail]>
X-Mailer: Cardiff Computing Maths PP Mail Open News Gateway
To:       [e-mail]

In his article [e-mail] (Lionel Cons) writes:
| I know a way to see if I run under chroot on my OS (HP-UX) and I think
| it should work on many different platforms: the inode number of / is
| always 2, so 'ls -id' will tell me...

Close, but no cigar.  'ls -id /' giving inode of 2 just means that the
root directory is the head of a filesystem - not necessarily the head
of the 'true' root filesystem.

What you need is a handle on the real root filesystem.  Normally your
controlling terminal was opened on the root filesystem, and stdin is
normally a file descriptor pointing to it, so an fstat() of fileno(stdin)
will reveal an st_dev that should be equal to that of your current /'s
st_dev  (if you are on the 'true' root filesystem).
Now you can can check /'s st_ino to see if it is 2.  Something like:

void  main(void) {
    struct stat tty, slash;
    if (-1 != fstat(fileno(stdin),&tty)  &&  -1 != stat("/",&slash))
         if (tty.st_dev == slash.st_dev  &&  slash.st_ino == 2)
            exit(0);     /* Not chroot()ed */
         else exit(1);   /* Am chroot()ed  */
    else exit(127);      /* Error          */
}

Note that all bets are off if someone has redirected your stdin  (you should
probably at least check that  tty.st_mode  denotes a character device).

I guess this is closer, but there must be a cleaner way.
(Bet I slipped up somewhere - go on, flame me 8)
Tim

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

From: rjan Robertsen <[e-mail]>
Subject: Broadcast detection from the socket layer ?
Keywords: socket, broadcast
Date: 9 Nov 92 09:43:36 GMT
Sender: Orjan Robertsen <[e-mail]>
To:       [e-mail]

Hello, wizards

I have the following (hopfully not too simple) question(s) for you:

    Given access to the socket structure and accompanying information,
    is it possible to determine if a received packet (message) originally
    was sent as a broadcast message ? That is, where/when is the original
    to adress droped ?

    If it's not possible from the socket layer, how far "down" do I
    have to look to find this information, and will it be possible to
    forward this info to the socket layer in any way ?

Thanks in advance.
Have a nice day.
--
////      Xrjan W. Robertsen            |e-mail   : [e-mail]////
///Dept. of Computer Science, University|Home     : [phone]          ///
// of Tromsoe, N-9000 TROMSX, NORWAY    |Phone/Fax: [phone]    //

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

From: "Bryan S. So" <[e-mail]>
Subject: The Problem with UNIX
Date: 9 Nov 92 17:27:15 GMT
Sender: The News <[e-mail]>
To:       [e-mail]


I am doing research on UNIX command line interface problems.
I am sure everyone has his/her favorite UNIX troubles, would
you post or email me what's your favorites?  What should have
been done by UNIX to resolve that problem in general?

Does anybody know of excellent papers in this area?  I know
about Norman's "The Trouble with UNIX".

To start the discussion, consider the following problems:

    cat a b > b

    This is a general problem of trying to modify the input
    file.


    rm -filename_with_a_hyphen

    This is a general problem of name clash (clashing filename
    with command options.)


    mail somebody < a.out

    Sending binary file should be uuencoded first.  This is a
    general type conflict problem.


Bryan So

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

From: Arlie Davis <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 9 Nov 92 18:26:54 GMT
Sender: Netnews <[e-mail]>
Nntp-Posting-Host: terra.spd.louisville.edu
To:       [e-mail]

In comp.unix.misc you write:

> I am doing research on UNIX command line interface problems.
> I am sure everyone has his/her favorite UNIX troubles, would
> you post or email me what's your favorites?  What should have
> been done by UNIX to resolve that problem in general?

Are you sure you are researching the command line interface?  None of your
examples below seem to suggest so.

> Does anybody know of excellent papers in this area?  I know
> about Norman's "The Trouble with UNIX".

> To start the discussion, consider the following problems:

>     cat a b > b

>     This is a general problem of trying to modify the input
>     file.

This has nothing at all to do with the command line interface.  This is simply
an *error* in user semantics.  What should cat do?  Stick in a feedback loop?
No, this is definitely an error on the user's side.

>     rm -filename_with_a_hyphen

>     This is a general problem of name clash (clashing filename
>     with command options.)

True, but it is a trivial one.  *All* UNIX filenames can specified explicitly
with a full pathname (such as "rm /tmp/foo/bar/-filename_with_a_hyphen" or
"rm $PWD/-filename_with_a_hyphen"), or as a relative directory, starting with
the parent directory ".." or the current directory "." (such as
"rm ./-filename_with_a_hyphen").

Also, again, this has nothing at all to do with the command line interface,
the "shell".  How programs interpret their argument vector is entirely up
to them.  The shell only passes on what the user types.

>     mail somebody < a.out

>     Sending binary file should be uuencoded first.  This is a
>     general type conflict problem.

Again, this is an error on the *user's* side.  This has nothing to do with the
shell!  Yes, you could create a mail script wrapper that checked the magic cookie
of the file being sent (see file(1)), and uuencoded if necessary.  But this is
completely different from the shell.

> Bryan So
--
lrwx------   1 aldavi01 emacsstu       9 Jun  6 12:43 .signature -> /dev/null

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

From: Dave Schaumann <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 9 Nov 92 21:53:07 GMT
Sender: [e-mail]
Followup-To: comp.unix.wizards
To:       [e-mail]

In article <[e-mail]>, so@brownie (Bryan S. So) writes:
>I am doing research on UNIX command line interface problems.

How about the fact that it is default for mv to overwrite existing files?
It's way too easy to type something like

    mv <pattern>

where you don't put the destination directory, and pattern just happens
to match two files -- all of a sudden, one of them is wiped out!

>    rm -filename_with_a_hyphen

Eh.  This is a minor irritation, IMHO.  It's easy enough to avoid file names
that start with a hyphen, and if you know enough to look in the man pages,
it's easy enough to find what to do if you accidently make one.

>    mail somebody < a.out
>
>    Sending binary file should be uuencoded first.  This is a
>    general type conflict problem.

At best, this is a problem with mail.  At worst, this is trying to make
mail deal with a problem that uuencode already solves nicely.

The philosiphy of UNIX should be that utilities should be small and as
orthogonal and non-overlapping as possible.  This does present some
difficulties for the new user, but I think that OS designers need to think
beyond the needs of the new user if the OS is ever going to be useful for
seasoned users.

IMHO, that means if someone types "mail sombody < a.out", they are about to
have an opportunity for a learning experience.  :-)  If someone is in the
habit of mailing binary files a lot, and doesn't care to bother running
uuencode all the time, then they have the opportunity for another learning
experience to write a wrapper for mail that automatically uuencodes
stdin when it is redirected to a binary file.

--
What signature?

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

From: Boyd Roberts <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 9 Nov 92 21:57:34 GMT
Sender: USENET News System <[e-mail]>
Nntp-Posting-Host: prl313.prl.dec.com
To:       [e-mail]

The real problem, as Rob has so eloquently put it:

    ``Not only is UNIX dead, it's starting to smell really bad.''


Boyd Roberts            [e-mail]

``When the going gets wierd, the weird turn pro...''

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

From: Arlie Davis <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 9 Nov 92 23:20:00 GMT
Sender: Netnews <[e-mail]>
Nntp-Posting-Host: rigel.spd.louisville.edu
To:       [e-mail]

In <[e-mail]> [e-mail] (Dave Schaumann) writes:

> How about the fact that it is default for mv to overwrite existing files?
> It's way too easy to type something like

>     mv <pattern>

If you find this peevesome, do this: "alias mv='mv -i'".  It's in the fine
manual pages.

--
lrwx------   1 aldavi01 emacsstu       9 Jun  6 12:43 .signature -> /dev/null

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

From: Jawaid Bazyar <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 10 Nov 92 01:25:44 GMT
Sender: news <[e-mail]>
Nntp-Posting-Host: teal.csn.org
To:       [e-mail]

[e-mail] (Boyd Roberts) writes:

>The real problem, as Rob has so eloquently put it:

>    ``Not only is UNIX dead, it's starting to smell really bad.''

  Compared to what, oh great OS guru?  Surely not Windows/NT (vapor)
or OS/2 2.0 (IBM rubbish) or MSDOS (not even bones left).

  The _real_ problem is that the desktop metaphor has not caught on to
the modular approach that UNIX offers so well.  When I can put together
several simpler desktop type applications as easily as I can pipe
man into troff, then UNIX will be dead; or rather, UNIX will have
evolved to the next stage.  It will still be UNIX.

--
 Jawaid Bazyar              |   Ask me about the GNO Multitasking Environment
 Procyon, Inc.              |   for the Apple IIgs!
 [e-mail]         |   P.O Box 620334
 --Apple II Forever!--      |   Littleton, CO 80162-0334   [phone]

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

From: Pyung-Chul Kim <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 10 Nov 92 02:29:09 GMT
To:       [e-mail]

In article <[e-mail]> [e-mail] (Bryan S. So) writes:
>
>I am doing research on UNIX command line interface problems.
>I am sure everyone has his/her favorite UNIX troubles, would
>you post or email me what's your favorites?  What should have
>been done by UNIX to resolve that problem in general?
>

The FAQ of comp.unix.questions, comp.unix.shell might help you.

--
Pyung-Chul Kim        Internet: [e-mail]
Dept. of CS, Korea Advanced Inst. of Science and Technology (KAIST)
373-1 Kusong-dong, Yusong-gu Taejon 305-701, Korea
TEL: [phone]    FAX: [phone]

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

From: Boyd Roberts <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 10 Nov 92 09:44:08 GMT
Sender: USENET News System <[e-mail]>
Nntp-Posting-Host: prl313.prl.dec.com
To:       [e-mail]

In article <bazyar.721358744@teal>, [e-mail] (Jawaid Bazyar) writes:
>
>
>   Compared to what, oh great OS guru?

Compared to Plan 9.


Boyd Roberts            [e-mail]

``Not only is UNIX dead, it's starting to smell really bad.''  -- Rob Pike

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

From: Rich Kulawiec <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 10 Nov 92 14:18:06 GMT
Sender: [e-mail]
Followup-To: comp.unix.wizards
Nntp-Posting-Host: gynko.circ.upenn.edu
To:       [e-mail]

In article <[e-mail]> [e-mail] (Bryan S. So) writes:
>Does anybody know of excellent papers in this area?  I know
>about Norman's "The Trouble with UNIX".

Norman's paper is (a) a decade out-of-date and (b) extraordinarily
inaccurate, as it was when published.  In my opinion, it represents
the uninformed rantings of someone who is simply too lazy to read the
manuals and therefore should not be using a computer at all.

I'd suggest Rob Pike's 'cat -v considered harmful' as an excellent
starting point.

---Rsk

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

From: Mike Hollander <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 10 Nov 92 17:04:23 GMT
To:       [e-mail]

In article <[e-mail]> [e-mail] (Bryan S. So) writes:
>
>I am doing research on UNIX command line interface problems.
>I am sure everyone has his/her favorite UNIX troubles, would
>you post or email me what's your favorites?  What should have
>been done by UNIX to resolve that problem in general?
>

Things that bother me about the command line (I'm using Motorola
UNIX System V/68 Release 3.71 running a Korn shell using vi-type
command line editing on a VT420), in no particular order:

1) It is possible to backspace over the prompt.
2) Running over past the end of the line onto the next line does not
   allow you to backspace back to the previous line, and if you
   backspace at the last column of a line it is possible to miss
   a character and therefore not backspace over what you think
   you are backspacing over.
3) It doesn't seem possible to map the arrow keys on the keyboard
   to enable you to press up arrow to get the previous command, or
   to use left arrow to move backwards through the line.
4) It doesn't seem possible to store macros that could be run with
   a single keypress.
5) The function keys don't do anything and cannot be made to do
   anything on the command line.
6) The insert and remove keys cannot be made to place you in insert
   mode or remove characters.

That's a short list off the top off my head. If anyone has methods
to fix these complaints please feel free to respond!

Mike Hollander | [e-mail]

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

From: Mike Stefanik <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 10 Nov 92 17:17:19 GMT
Followup-To: comp.unix.wizards
To:       [e-mail]

In an article, [e-mail] (Boyd Roberts) writes:
>The real problem, as Rob has so eloquently put it:
>
>    ``Not only is UNIX dead, it's starting to smell really bad.''

I find it amazing that people, apparently in pursuit of some small amount of
enjoyment, spend their time proclaiming the death of UNIX. This sort of thing
is really beginning to take on the flavor of the apocalyptic doomsayers (you
know the type ... they run about the streets wearing dirty plaid suits bellowing
"Repent Now, For the End is Near!").

I have heard UNIX to be proclaimed dead and buried for years now. I have no
doubt that there are those who would *like* UNIX to be dead, but desire alone
does not make a thing so. Microsoft is a good case in point, I suppose.

So, Boyd, if UNIX really is dead, where is the funeral? I would so enjoy
paying my last respects ...

Oh, and by the way, I do assume then that you are using VMS, DOS, or perhaps a
beta version of Windows NT?  You wouldn't be caught *dead* using UNIX, am I
right? :-)

--
Mike Stefanik  [e-mail]  ...!uunet!pacsoft!mike  [phone]
Pacific Software Group, Riverside, CA

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

From: peter da silva <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 10 Nov 92 20:23:41 GMT
To:       [e-mail]

In article <[e-mail]> [e-mail] (Bryan S. So) writes:
> I am doing research on UNIX command line interface problems.
> I am sure everyone has his/her favorite UNIX troubles, would
> you post or email me what's your favorites?  What should have
> been done by UNIX to resolve that problem in general?

UNIX isn't an entity that can *do* anything. A better question would be
what could (Bell Labs, Thompson, Ritchie, ...) have done to make UNIX
easier to use? Well, Bell Labs could have bought all the UNIX people
dumb terminals instead of teletypes, even if that was hideously expensive,
so that they wouldn't have as much of an incentive to shorten command lines.
Have you ever worked on a genuine ASR33?

> To start the discussion, consider the following problems:

PIP FILE.=FILE.

PIP FILE.*;*/DE

PIP LP:=[1,54]PIP.COM

>     Sending binary file should be uuencoded first.

Nope. It should say "mail: Standard input contains NULL characters." And
abort.

>     This is a general type conflict problem.

No, it's an error-checking problem.

These aren't "UNIX" problems. These are general "Customer Engineering"
problems. UNIX is pretty good by the general standards of operating systems
of the time. The problem is that AT&T/USG/USL/Univel/whoever it is this week
has never sat down and done a thorough study of what is needed to "flatten"
the user interface. It's 1992, not 1972.

The most important problem, in my opinion, you never even mentioned:

    cat: cannot open /blog/crottled/greeps

What does this mean? /blog doesn't exist? Permissions are wrong? Some
system is down? What?

    /blog/crottled/greeps: Network I/O error.
    cat: Can't open input file.

Just (a) fixing all applications so they call perror on failure, and (b)
cutting down on the overloading of error messages, would do wonders.
--
Peter da Silva / 77487-5012 USA / [phone]
true(<<VV$@\\$'&O 9$O%'$LT$&$"V6"$&$<4$?'&$ #I&&?$=$<<@)24 24 scale 3 21 moveto
{dup 36 eq{pop not}{dup 7 and 4 sub exch 56 and 8 div 4 sub 2 index{rlineto}{
rmoveto}ifelse}ifelse}forall stroke pop showpage % Har du kramat din varg idag?

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

From: peter da silva <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 10 Nov 92 20:28:38 GMT
To:       [e-mail]

Boyd Roberts sigged:
> ``Not only is UNIX dead, it's starting to smell really bad.''  -- Rob Pike

Jawaid Bazyar asked:
> >   Compared to what, oh great OS guru?

Boyd Roberts response:
> Compared to Plan 9.

Plan 9 is currently still in the preemie ward. When I can go out and buy a
copy of Plan 9 with all the installation tools I get with System V, then
I'll be able to take a look at it. But today, even if I could get a copy of
Plan 9 it wouldn't run on anything I have access to. And the installation,
based on the Plan 9 docs I've got, is a real pain.

I'd love to try it, though...
--
Peter da Silva / 77487-5012 USA / [phone]
true(<<VV$@\\$'&O 9$O%'$LT$&$"V6"$&$<4$?'&$ #I&&?$=$<<@)24 24 scale 3 21 moveto
{dup 36 eq{pop not}{dup 7 and 4 sub exch 56 and 8 div 4 sub 2 index{rlineto}{
rmoveto}ifelse}ifelse}forall stroke pop showpage % Har du kramat din varg idag?

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

From: Lyndon Nerenberg <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 10 Nov 92 21:22:20 GMT
Followup-To: comp.unix.shell
To:       [e-mail]

[e-mail] (Boyd Roberts) writes:
> >   Compared to what, oh great OS guru?

> Compared to Plan 9.

I'm not very familiar with Plan 9. How does rc address the problems the
original poster detailed?

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

From: Jurgen Botz <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 10 Nov 92 21:49:55 GMT
Sender: USENET News System <[e-mail]>
To:       [e-mail]

In article <[e-mail]> Arlie Davis <[e-mail]> writes:
>This has nothing at all to do with the command line interface.  This is simply
>an *error* in user semantics.  What should cat do?  Stick in a feedback loop?
>No, this is definitely an error on the user's side.
>[...]
>Also, again, this has nothing at all to do with the command line interface,
>the "shell".  How programs interpret their argument vector is entirely up
>to them.  The shell only passes on what the user types.
>[...]
>Again, this is an error on the *user's* side.  This has nothing to do with the
>shell!  Yes, you could create a mail script wrapper that checked the magic cookie
>of the file being sent (see file(1)), and uuencoded if necessary.  But this is
>completely different from the shell.

But the original poster said nothing about the shell!  He asked for
comments on "problems with the Unix command line interface".  IMHO
"the Unix command line interface" includes the shell /as well as/
the command line semantics of all programs written for use under
Unix.  Just as user interface problems with the Macintosh are not
limited to the "Finder", but include problems with the user interfaces
for individual applications, so "problems with the Unix command line
interface" include problems with the way the user interacts with
Unix commands, independent of the particular shell.  In other words,
if you wanted to change the command line user interface to Unix it
would not be enough to replace the shell -- you'd also have to
rewrite all the utilities (just as you have to rewrite utilities to
make the take advantage of a GUI.)

To the original poster:  you should have cross-posted this thread
to comp.human-factors.

--
Jurgen Botz                  |   Internet: [e-mail]
Academic Systems Consultant  |     Bitnet: [e-mail]
Mount Holyoke College        |      Voice: (US) 413-538-2375 (daytime)
South Hadley, MA, USA        | Snail Mail: J. Botz, 01075-0629

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

From: Claus Brod <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 11 Nov 92 09:59:37 GMT
X-Newsreader: TIN [version 1.1.4 PL6]
To:       [e-mail]

Rich Kulawiec ([e-mail]) wrote:
: I'd suggest Rob Pike's 'cat -v considered harmful' as an excellent
: starting point.

Where can I find this document?

Tnx,

    Claus

--
[e-mail]----------------------------------------------
Claus Brod, MDD, HP Boeblingen       Things. Take. Time. (Piet Hein)
--#include <std_disclaimer>----------------------------------------------

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

From: Mark Evans <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 11 Nov 92 10:25:55 GMT
Sender: Usenet administrator <[e-mail]>
Nntp-Posting-Host: uhura
To:       [e-mail]

[e-mail] (Mike Stefanik) writes:

: So, Boyd, if UNIX really is dead, where is the funeral? I would so enjoy
: paying my last respects ...
:
: Oh, and by the way, I do assume then that you are using VMS, DOS, or perhaps a
: beta version of Windows NT?  You wouldn't be caught *dead* using UNIX, am I
: right? :-)

They might be using OS/2 or a mac possibly as other options.
--
 -------------------------------------------------------------------------
Mark Evans                                   |[e-mail]
+(44) 21 565 1979 (Home)                     |[e-mail]
+(44) 21 359 6531 x4039 (Office)             |

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

From: Boyd Roberts <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 11 Nov 92 15:08:28 GMT
Sender: USENET News System <[e-mail]>
Nntp-Posting-Host: prl313.prl.dec.com
To:       [e-mail]

In article <[e-mail]>, [e-mail] (Mike Stefanik) writes:
>
> Oh, and by the way, I do assume then that you are using VMS, DOS, or perhaps a
> beta version of Windows NT?  You wouldn't be caught *dead* using UNIX, am I
> right? :-)
>

Well I'm doing my best to avoid it.  I'm using Byron's rc and the Plan 9
editor sam (and have done so for more than a year).  Lately we have short
term Plan 9 style backups:

    prl313 dump; cd 9211/10/udir/boyd/work/ftpnfs
    prl313 ftpnfs; ls -ltr
    total 16
    -rw-r--r--  1 boyd          766 Nov  9 14:01 README
    -rw-r--r--  1 boyd         1940 Nov  9 19:31 Makefile
    -rw-rw-r--  1 boyd         7190 Nov  9 23:51 ftpnfs.1
    drwxrwxr-x  3 boyd          512 Nov 10 03:49 src
    drwxrwxr-x  2 boyd          512 Nov 10 03:49 doc
    drwxrwxr-x  2 boyd          512 Nov 10 03:49 test
    drwxrwxr-x  2 boyd          512 Nov 10 03:54 mips
    drwxrwxr-x  2 boyd          512 Nov 10 03:54 vax

So there's (some) of the work I did a day or so ago.

Hell, I've even been hacking VMS:

    $ start/queue/on=prlvms:: eve


Boyd Roberts            [e-mail]

``Not only is UNIX dead, it's starting to smell really bad.''  -- Rob Pike

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

From: Scott Beckstead <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 11 Nov 92 19:45:57 GMT
To:       [e-mail]

In article <[e-mail]> Arlie Davis <[e-mail]> writes:
>In comp.unix.misc you write:
>
>> I am doing research on UNIX command line interface problems.
>> I am sure everyone has his/her favorite UNIX troubles, would
>> you post or email me what's your favorites?  What should have
>> been done by UNIX to resolve that problem in general?
>
>Are you sure you are researching the command line interface?  None of your
>examples below seem to suggest so.
>
>> Does anybody know of excellent papers in this area?  I know
>> about Norman's "The Trouble with UNIX".
>
>> To start the discussion, consider the following problems:
>
>>     cat a b > b
>
>>     This is a general problem of trying to modify the input
>>     file.
>
>This has nothing at all to do with the command line interface.  This is simply
>an *error* in user semantics.  What should cat do?  Stick in a feedback loop?
>No, this is definitely an error on the user's side.
>
>>     rm -filename_with_a_hyphen
>
>>     This is a general problem of name clash (clashing filename
>>     with command options.)
>
>True, but it is a trivial one.  *All* UNIX filenames can specified explicitly
>with a full pathname (such as "rm /tmp/foo/bar/-filename_with_a_hyphen" or
>"rm $PWD/-filename_with_a_hyphen"), or as a relative directory, starting with
>the parent directory ".." or the current directory "." (such as
>"rm ./-filename_with_a_hyphen").
>
>Also, again, this has nothing at all to do with the command line interface,
>the "shell".  How programs interpret their argument vector is entirely up
>to them.  The shell only passes on what the user types.
>
>>     mail somebody < a.out
>
>>     Sending binary file should be uuencoded first.  This is a
>>     general type conflict problem.
>
>Again, this is an error on the *user's* side.  This has nothing to do with the
>shell!  Yes, you could create a mail script wrapper that checked the magic cookie
>of the file being sent (see file(1)), and uuencoded if necessary.  But this is
>completely different from the shell.
>
>> Bryan So
>--
>lrwx------   1 aldavi01 emacsstu       9 Jun  6 12:43 .signature -> /dev/null

  I think this is kinda what he is trying to determine.  Typicaly UNIX
imposes far more structure on the user than is desired.  I agree an
experienced user should be able to recognize and avoid the problems
above.  What's wrong with the shell catching such obvious errors and
either reporting them or taking other appropriate action (ie correcting
them).  I realize that this will get me screamed at by all you guru
types that advocate that all shell users be rocket scientists or why
bother using a computer anyway.  However I see no reason NOT to research
the subject.  If UNIX could be made more user friendly by modifying the
shell it might gain more acceptance in the general microcomputer market
place, GUIs not withstanding.
Scott


--
Reply to: [e-mail]     |
                |    Spin my nipple nuts and send me to
  Smoke me a kipper, I'll be    |     Alaska.
   back for breakfast         |

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

From: "Bryan S. So" <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 11 Nov 92 21:07:29 GMT
Sender: The News <[e-mail]>
To:       [e-mail]

Concerning Don Norman's paper "The Trouble With UNIX", Datamation 27,
[e-mail] (Rich Kulawiec) writes:

>Norman's paper is (a) a decade out-of-date and (b) extraordinarily
>inaccurate, as it was when published.  In my opinion, it represents
>the uninformed rantings of someone who is simply too lazy to read the
>manuals and therefore should not be using a computer at all.

I agree it's a decade old but can you indicate why it's inaccurate?

To me, some problems like "cat a b > b" are obviously undesirable
designs and still unsolved after more than a decade.


Bryan

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

From: Bruce Barnett <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 12 Nov 92 14:20:45 GMT
Sender: Required for NNTP <[e-mail]>
Nntp-Posting-Host: grymoire.crd.ge.com
To:       [e-mail]

In article <[e-mail]> [e-mail] (Bryan S. So) writes:
>   To me, some problems like "cat a b > b" are obviously undesirable
>   designs and still unsolved after more than a decade.

It has been solved. There are at least two solutions:
    1) Educate the user. After all the system did exactly what
        the user told it to do.
    2) in csh/tcsh, do "set noclobber"

grymoire% set noclobber
grymoire% touch a b
grymoire% cat a b >b
b: File exists.
--
Bruce Barnett <[e-mail]> uunet!crdgw1!barnett

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

From: [e-mail]
Subject: An FTP site to get the latest GCC Compiler for DOS - PLEASE!
Date: 9 Nov 92 17:47:58 GMT
Sender: jsmolnar@descartes
To:       [e-mail]

Could someone please privately email me the location of the latest
GCC C Compiler for DOS.  This is required as quickly as possible, so if you
read this, please respond right now ... It is for an urgent project.  I am
looking for the ftp location ... thanks a lot.

(Please do it private since, I don't have time to read news.)

jsmolnar

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

From: Mohan Srinivasan <[e-mail]>
Subject: Re: SUN NFS sync
Keywords: sync
Date: 9 Nov 92 18:43:17 GMT
Sender: [e-mail]
Nntp-Posting-Host: osiris.auspex.com
To:       [e-mail]

In article <[e-mail]> [e-mail] (Network Appliance) writes:
>In article <[e-mail]> [e-mail] (Guy Harris) writes:
>>Umm, I don't think it was even the case in 3.x - or 2.x, for that matter
>>- that NFS writes were synchronous on the client side.
>
>Last time I checked, NFS writes were handled very differently in the
>SunOS client code as compared with the client code that Sun distributes
>to other UNIX vendors who buy NFS from Sun.
>
>In SunOS, the write(2) system call just dirties buffers in memory, and
>expects biod's to do the writes when they are able.  In the
>distributed NFS, the write(2) system call tries to schedule a biod to
>immediately send the write, and if no biod is available, then the
>process doing the write(2) does the send itself.
>

Actually, even in SunOS (both 4.X and 5.X), if the write rounds up to a
8K chunk, the write is scheduled to the biod's immediately (ie. if there is
a biod available, the write'ing process hands over the write to it.
Otherwise, if there's no free biod available, the write is done
by the writing process itself - this is 4.x behavior, in 5.x an async
write is always queued up to be picked up by the biod threads).

Scheduling the write is done by the function in the segmap driver code
that releases the mapped (segkmap) segment. It calls VOP_PUTPAGE() with
the flags that were passed to itself. (So, it handles cases like ASYNC,
INVAL, DONTNEED etc).

However, you're right in that if the write is < 8k, then it just dirties
the page(s).

--
===============================================================================
Ram Mohan Srinivasan
[e-mail]
===============================================================================

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

From: Bruce Krawetz <[e-mail]>
Subject: RPCGEN
Date: 9 Nov 92 21:09:17 GMT
Sender: [e-mail]
To:       [e-mail]

I asked this question in comp.unix.questions, and got no response.
So now I'm trying here:

Has anybody heard of an rpcgen program that generates
pascal source code? (and if so, where can I get it?)

---
[e-mail]
We must learn from our mistakes, so that we may make bigger and better ones.

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

From: Mike Leibensperger <[e-mail]>
Subject: Re: RPCGEN
Date: 10 Nov 92 18:20:40 GMT
Sender: Netnews <[e-mail]>
To:       [e-mail]

In article <[e-mail]> [e-mail]
(Bruce Krawetz) writes:
>
>   Has anybody heard of an rpcgen program that generates
>   pascal source code? (and if so, where can I get it?)

HP/Apollo's Network Interface Definition Language (NIDL) used to
generate either Pascal or C language stubs.  It has since been
transmogrified into just plain IDL, the RPC interface language for
OSF's DCE RPC.  I'm not sure if it still generates Pascal stubs or
not.

> ---
> [e-mail]
> We must learn from our mistakes, so that we may make bigger and better ones.

    mjl
--
Michael J. Leibensperger      "Rats and roaches live by competition under the
Locus Computing/Boston         laws of supply and demand; it is the privilege
25 Mall Road; Burlington MA         of human beings to live under the laws of
01803 [phone] [e-mail]       justice and mercy."  -- Wendell Berry
Member of the League for Programming Freedom --- write [e-mail]

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

From: Bernt Skottun <bernt@valois>
Subject: Keyboard hit in C programs
Keywords: Keyboard hit, C programs, UNIX
Date: 9 Nov 92 23:29:54 GMT
NNTP-Posting-Host: 128.32.157.154
To:       [e-mail]


I am in the process of adapting a C program from the PC for
the UNIX environment (for SUN 3 running SUNOS 4.1.1).
In this program it is essential that
the user be able to stop certain parts of the program
(e.g. an inner loop) by hitting the keyboard (any key
is fine) while as long as the keyboard is not touched the execution
of the program will continue un-interupted (thus a procedure
which requires, or expects, the user to type in a key stroke at certain
intervals will not do). In the DOS environment
I have been able to do this with the "kbhit()" function.
My question is: what is the equivalent function in the UNIX
environment? or how does one go about creating such a function?
Any suggestions will be very welcome. Thanks a lot.
Bernt Skottun, [e-mail]


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

From: Marc Unangst <[e-mail]>
Subject: Re: Keyboard hit in C programs
Keywords: Keyboard hit, C programs, UNIX
Date: 10 Nov 92 07:57:22 GMT
To:       [e-mail]

In article <[e-mail]> bernt@valois (Bernt Skottun) writes:
>intervals will not do). In the DOS environment
>I have been able to do this with the "kbhit()" function.
>My question is: what is the equivalent function in the UNIX
>environment? or how does one go about creating such a function?

Your question is answered in Part 4 of the comp.unix.questions FAQ
list.  In the future, please check to see if your question is answered
in one of the FAQ postings before posting it to the net.

4.1)  How do I read characters from a terminal without requiring the user
      to hit RETURN?

      Check out cbreak mode in BSD, ~ICANON mode in SysV.

      If you don't want to tackle setting the terminal parameters
      yourself (using the "ioctl(2)" system call) you can let the stty
      program do the work - but this is slow and inefficient, and you
      should change the code to do it right some time:

      #include <stdio.h>
      main()
      {
        int c;

        printf("Hit any character to continue\n");
        /*
         * ioctl() would be better here; only lazy
         * programmers do it this way:
         */
        system("/bin/stty cbreak");        /* or "stty raw" */
        c = getchar();
        system("/bin/stty -cbreak");
        printf("Thank you for typing %c.\n", c);

        exit(0);
      }

      You might like to check out the documentation for the "curses"
      library of portable screen functions.  Often if you're interested
      in single-character I/O like this, you're also interested in
      doing some sort of screen display control, and the curses library
      provides various portable routines for both functions.

4.2)  How do I check to see if there are characters to be read without
      actually reading?

      Certain versions of UNIX provide ways to check whether characters
      are currently available to be read from a file descriptor.  In
      BSD, you can use select(2).  You can also use the FIONREAD ioctl
      (see tty(4)), which returns the number of characters waiting to
      be read, but only works on terminals, pipes and sockets.  In
      System V Release 3, you can use poll(2), but that only works on
      streams.  In Xenix - and therefore Unix SysV r3.2 and later - the
      rdchk() system call reports whether a read() call on a given file
      descriptor will block.

      There is no way to check whether characters are available to be
      read from a FILE pointer.  (You could poke around inside stdio
      data structures to see if the input buffer is nonempty, but that
      wouldn't work since you'd have no way of knowing what will happen
      the next time you try to fill the buffer.)

      Sometimes people ask this question with the intention of writing
        if (characters available from fd)
            read(fd, buf, sizeof buf);
      in order to get the effect of a nonblocking read.  This is not
      the best way to do this, because it is possible that characters
      will be available when you test for availability, but will no
      longer be available when you call read.  Instead, set the
      O_NDELAY flag (which is also called FNDELAY under BSD) using the
      F_SETFL option of fcntl(2).  Older systems (Version 7, 4.1 BSD)
      don't have O_NDELAY; on these systems the closest you can get to
      a nonblocking read is to use alarm(2) to time out the read.

--
Marc Unangst, N8VRH         | "There are two ways to solve this problem:
[e-mail]   | the hard way, and the easy way.  Let's start
                            | with the hard way."
                            |   - W. Scheider, from a Physics lecture

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

From: Howard D'Souza <[e-mail]>
Subject: Re: Keyboard hit in C programs
Keywords: Keyboard hit, C programs, UNIX
Date: 12 Nov 92 11:34:31 GMT
Sender: News account <[e-mail]>
To:       [e-mail]

In article <[e-mail]> [e-mail] (walter misar) writes:
>In article <[e-mail]>, bernt@valois (Bernt Skottun) writes:
>>
>> I am in the process of adapting a C program from the PC for
>> the UNIX environment (for SUN 3 running SUNOS 4.1.1).
>> In this program it is essential that
>> the user be able to stop certain parts of the program
>> (e.g. an inner loop) by hitting the keyboard (any key
>> is fine) while as long as the keyboard is not touched the execution
>> of the program will continue un-interupted (thus a procedure
>> which requires, or expects, the user to type in a key stroke at certain
>> intervals will not do). In the DOS environment
>> I have been able to do this with the "kbhit()" function.
>> My question is: what is the equivalent function in the UNIX
>> environment? or how does one go about creating such a function?
>> Any suggestions will be very welcome. Thanks a lot.
>> Bernt Skottun, [e-mail]
>>
>
>Ok, since ^C is an 'any key' you only have to catch the SIGINT you
>get if ^C is hit.
>

Obviously, by "any key" Bernt Skottun means any key that the user wishes to
hit and not one that the program wants him to.  For this kind of thing, the
CBREAK mode for the tty immediately suggests itself. (Check out the sg_flags
field of the sgttyb structure for ioctl(2) called with TIOCSETP). If the
program does not wish to wait till the user hits the key, select(2) could be
used (if available) or the terminal could be put in non-blocking mode ( by
setting the O_NDELAY status flag for the tty's descriptor using fcntl(2).


>In function() ( prototyped as void function(void) ) the first call should
>be signal(SIGINT,function) because the behavior of SIGINT is reset to default
>by the signal-handler.

What version of UNIX are you using, may I ask? And isn't it time you treated
yourself to an update? :)

Howard






Howard M. D'Souza
National Centre For Software Technology, Graphics Division

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

From: Valdis Kletnieks <[e-mail]>
Subject: Re: Process 'purge' revisited.. Unix missing this?
Date: 10 Nov 92 09:52:55 GMT
Sender: [e-mail]
To:       [e-mail]

In article <[e-mail]> [e-mail] (Trevor Paquette) writes:
> All the responses I have recieved have all said exactly what I thought.
>It is impossible to 'purge' a process witing on a hung device.
>
> Is this a deficency in Unix? Should it be added? Will I ever win the
>lottery?

No, it's a deficiency in operating systems in general.

Now let's look at what happens:

You have a "process"/"task"/whatever you want to call it that initiates
an I/O transfer to a device.  Said device mysteriously flames out
before the transfer completes.  You're sitting there with a process
that has some buffers locked in memory as a target for the I/O.

What should you do?

You can't just kill the process and free the buffers - that device might
wake up and complete the I/O over where the buffers USED to be.
Unless you're willing to bet the system that you have managed to FOR SURE
abort an in-progress transfer, you have to keep enough state around
so that if it DOES complete, you won't get torched.

SImply pretending the I/O is gone loses too - the process may get
confused, and if the I/O *does* complete, you're torched.

Killing the process and not freeing the buffers gets interesting, as
you have to then find some way of dealing with the buffers - most
operating systems kind of make an assumption that allocated real
memory *belongs* to somebody - so a "kill the process and free all but
these 960 bytes" gets interesting.

And of course all sorts of OTHER warts arise in the real world.. ;)

Feel free to propose what you think it should do - and remember in
your design to address all the failure modes (Heck, we only *get*
into this situation if something has failed already)....

                Valdis Kletnieks
                Computer Systems Engineer
                Virginia Tech

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

From: Arne Ludwig <[e-mail]>
Subject: Re: Process 'purge' revisited.. Unix missing this?
Date: 10 Nov 92 17:00:08 GMT
Sender: "Mr. News" <[e-mail]>
To:       [e-mail]

[e-mail] (Trevor Paquette) writes:
>It is impossible to 'purge' a process witing on a hung device.

An unkillable process waiting on a hung device is just a sign of a broken
device driver.

> Is this a deficency in Unix? Should it be added? Will I ever win the
>lottery?

No. No. Perhaps.
--
Arne Ludwig
[e-mail]            [e-mail]

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

From: Arne Ludwig <[e-mail]>
Subject: Re: Q: Proper client/server protocol w.r.t. socket read/writes
Date: 10 Nov 92 17:03:19 GMT
Sender: "Mr. News" <[e-mail]>
To:       [e-mail]

[e-mail] (Ron Cecchini) writes:
>every time she does a
>write, she immediately does a read to acknowledge that the info got to
>the other side

>She says that when she didn't do this,
>her application crashed because of some kind of "imbalance".

You don't supply enough information, but this suggests to me that she
might be using a stream socket and variable length messages.

If she's not acknowledging the individual packets, this may, and almost
always does, mean that some messages get mixed up with previous ones,
because streams are not "packetized".

You may think of avoiding this problem by using datagram sockets, but
unfortunately most Unices don't give you reliable, sequenced delivery
on datagrams sockets, so you would need the acknowledge after all.

A very simple solution is to use fixed packet lengths, or transmitting
length information with each packet.
--
Arne Ludwig
[e-mail]            [e-mail]

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

From: j warsa <[e-mail]>
Subject: Re: termcap/terminfo
Date: 10 Nov 92 18:21:38 GMT
To:       [e-mail]


I posted a request asking for a termcap entry for AIX hft/aixterm (for which
only sysV terminfo entries are available).

I lost my mbox before I could reply to whoever it was that sent
me the AIX hft termcap entry. Thanks, it works very well for both aixterm
and hft.


--
jim warsa
albuquerque

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

From: Troy Frericks <[e-mail]>
Subject: >>TAR file on tape distroyed, are files recoverable?<<
Date: 10 Nov 92 18:43:20 GMT
Sender: [e-mail]
Nntp-Posting-Host: marx
To:       [e-mail]

I have a tape that contained a large 'tar' file.  The data is not
replaceable.  The data that is needed is at the end of the tar
file, but it is inaccessable because the wrong parameter was
passed to tar when attempting to retrieve it.  The 'c' for
create, rather than 'x' for eXtract was passed, which caused
tar to write a tiny tar file over the beginning of the
larger one.

Any hints on how to retrieve files from a large tar file once
the beginning of the tar file has been distroyed?

-
Troy Frericks                      Internet: [e-mail]
Microware Systems Corporation          UUCP: uunet!mcrware!troyf
1900 NW 114th St                      Phone: [phone]
Des Moines, IA 50325-7077               Fax: [phone]

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

From: Jim Harkins <[e-mail]>
Subject: Need a raw ethernet interface
Date: 10 Nov 92 19:06:05 GMT
Sender: Jim Harkins <[e-mail]>
To:       [e-mail]

I'm trying to write an ethernet driver and it appears as though standard
Sun tools like etherfind won't show packets with errors.  So does anyone
know of a package, or tool that will work like etherfind only display errored
packets as well as 'good' ones?  By errors I mean all levels of errors, from
CRC to UDP protocol errors.  I have access to a Sun ELC I can configure to
do this, I could also plug a PC into that wire if I wanted to.

What I really need is a sniffer but my boss won't spring for one....

Thanks.

jim

--
So many women, so little charisma.
 --------------------------------------------------------------
Jim Harkins                         [ucsd|uunet]!pacdata!jim
Pacific Data Products               [e-mail]
 --------------------------------------------------------------

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

From: Sanjay Shrivastava <[e-mail]>
Subject: applications using p-threads!!
Date: 10 Nov 92 23:56:29 GMT
Sender: [e-mail]
To:       [e-mail]

could someone please let me know of applications on the public domain
that use p_threads!! as there are no
manuals on programming in threads (I havent found any!!!) I, a beginner
in programming using threads, am
having lots of problems.

Thanks in advance.....

Sanjay.

Sanjay Shrivastava
Research Assistant
Concurrent Engineering Research Center
West Virginia University
Morgantown, WV-26506.

Ph#:(304)-293-7535 extn:242.

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

From: Jean-Yves Patry <[e-mail]>
Subject: ISC 3.0 Terminfo database question
Date: 11 Nov 92 01:32:23 GMT
Sender: [e-mail]
To:       [e-mail]


Does anybody have the Terminfo database entry for an HP laserjet
II/III printer for ISC 3.0 ? I want to be able to query the Terminfo
database with the standard interface program for things such as
line-per-inch character-per-inch, character sets, etc.

I've tried to use the existing Terminfo database entry for HP printers
with no success.

Thanks


--
 -------------------------------------------------------------------------------
Jean-Yves Patry          [e-mail]          [phone] x4992
 -------------------------------------------------------------------------------

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

From: Francisco X DeJesus <[e-mail]>
Subject: HELP! problem with tar PC <-> SUN
Date: 11 Nov 92 03:16:09 GMT
Sender: NWC News Admin <[e-mail]>
To:       [e-mail]

Hello. I am posting this question regarding a problem a friend of mine is
having in hopes someone out there may be able to help. Here's the situation:

There is a Sun Sparc 2 (SunOS 4.1.2) and a PC running Unix, and we have to
be able to use "tar" to transfer files on a tape (Exabyte 8mm 8200) from
one machine to the other and back. The "PC running Unix" refers to trying
this with SCO Unix, Interactive Unix, and Intel Unix.

Here's the problem: there appears to be a 10x differential in the blocking
factor used by the Sun and the PC's. If a tape is written on the Sun with
a blocking fator of 2, the PC reads it as a blocking factor of 20. Both
"say" they are writing with block size=512 and blocking factor=20 by
default, but the evidence shows this to be wrong. The Sun at least is smart
enough to recognize the different blocking factor when reading the tape
and has no trouble. The PC, however, has to be told, and this is where the
*REAL* problem comes in:

The client specifies that the "tar" command *HAS* to be used _WITHOUT_
telling it a specific blocking factor on either end (tar xb [blocksize] is
not allowed). I know, I know... it's retarded, but those are the client's
specs. We wouldn't have a problem using the blocking factor command-line
argument, they would. ARGH!

Both SCO and Interactive Unix have an optional file, /etc/defaulttar (sp?),
which is *supposed* to be able to allow default command-line arguments to
tar to be specified there. If this worked, it would have been great... but
no luck. Anyone know how to make this work?

So... any ideas? Please, we are wide open to suggestions. ANY possibilities
will be explored... a different tape driver, another PC Unix version,
rebuilding tar on the PC (if we can get the sources)... anything goes.

Please respond to me via email (I do not read all these newsgroups regularly).
I'll forward the responses to my friend, and will gladly summarize any
responses I receive to anyone who's interested.

Thanks very, very much in advance.

--
Francisco X DeJesus  ----- S A I C -----  [e-mail]
disclaimer: "Opinions expressed here are mine. Typos and errors are all yours."

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

From: Boerge Mueller <[e-mail]>
Subject: ksh argument interpreter
Keywords: ksh arguments
Date: 11 Nov 92 08:30:41 GMT
To:       [e-mail]

Hi

I'm not yet fully educated in UNIX, and have this problem:

I wont to make a command which can handle binary files and ascii files
in a seperate way in one task, I could imaging a syntax like this:

$ command_name -u "user" -a [ascii file(s)] -b [binary file(s)]

If I write :

$ command_name -u elliot -a a* -b b*   ; then ksh will interpret

like:

$ command_name -u elliot -a a1 a2 a3 a4 -b b1 b2 b3 b4

then I need a shell script do deal which those multi argument, I imaging
some kind of "case" syntax, but I cant find any solution but where
"kludge" kind of programming. (please do not suggest awk or pearl, without
a shell solution also, I'm not yet ready to do pearl or awk).

Thanks in advance

--
From:
Boerge Mueller  (Project manager CAD & Technical information systems)
Great Belt Ltd.                    |--------------------------------|
Phone  : [phone] x 222       | I don't know what the          |

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

From: Power = 486 + HST Dual Standard <[e-mail]>
Subject: libg++2.2
Date: 11 Nov 92 09:42:00 GMT
Sender: [e-mail]
News-Software: VAX/VMS VNEWS 1.41
X-Posted-From: cnsvax.uwec.edu
NNTP-Posting-Host: sol.ctr.columbia.edu
To:       [e-mail]

I am trying to compile libg++2.2 under gcc 2.3.1, but I
always get the following error:

    a make fatal error

nothing more specific then that. I am running Esix 4.0.3
and I did the configure i386-sysv4. If anyone can help me
I would appreciate it. Thanks.

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

From: Frank Pinto <[e-mail]>
Subject: Need help with "makefile"
Date: 11 Nov 92 20:26:47 GMT
Sender: USENET News System <[e-mail]>
To:       [e-mail]

Hello all

I'm new at this, so go slow.
Recently I ftp'd some files from DIGITAL
after uncompressing, unarchiving them, I've
found out to compile the program I have to
know somthing about "makefile"
I have about 20 files in the particular
program.
What is, and how do I use makefile

Frank Pinto

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

From: Eric Parson <[e-mail]>
Subject: Any TeX (compilation) Gurus out there?
Keywords: TeX, make
Date: 11 Nov 92 20:28:46 GMT
Sender: USENET News <[e-mail]>
To:       [e-mail]

I'm running out of thoughts of where to send up distress flares.  Hopefully
there's a hopeful hint or five out there somewhere.

I'm in the process of installing the complete TeX distribution on my
SPARC 2 station.  To make a long story short, after a couple of failures
along the 'make' path, I've run up against one that I can't seem to overcome.
I've managed to get to the point where MetaFont is creating the 'plain'
fonts, and the 'make' bogs down.  After some false starts, I manage to
get MF to process the plain.mf file, but in the 'Makefile' command file,
it displays the line:
    inimf plain; input modes; dump
Well, it gets through the inimf, but fails the input.  Now there aren't that
many copies of files with the name 'modes' in them (two to be precise, and
one is amsmodes.mf), thus I thought that moving a copy of modes.mf from the
input directory would solve my problem.  It didn't.  Now I don't know what
else to do.
    I would greatly appreciate any input someone out there could/would
provide about even how to attack the problem, I would greatly appreciate
it.  (Cannonization is probable if you can actually help me nuke this prob.
:-)  )  Thanks in advance for any help you can provide.

            Eric T. Parson
                [e-mail]

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

From: Sinan Karasu <[e-mail]>
Subject: Solaris 2.0/2.1 Realtime programming
Date: 11 Nov 92 20:35:32 GMT
To:       [e-mail]

Hi wizards,
I am porting an application that requires very fine
timing control to Solaris 2.0/2.1. I need to be able to schedule
my program at given time increments. The time increment can be
anywhere from 1 millisecond to 50 milliseconds. I gave played
with setitimer and SIGALRM , they do work fine except I can not
get better than 10 millisecond granularity. So I decided
to try something more hardware oriented and noticed that there are
2 timer/counters in the MMU chip.
Questions:

1) Does the OS use either or both of these counters?
2) Are there other timers available on the Sparc platform?
3) Does the equation change if I use a VME based SparcEngine?
4) Does/Has anybody done/? any work in this area and give me some
   pointers?
5) Are there other calls in Solaris 2.0 and derivatives that would
   allow me to what I am trying to do ????



Thanx for any and all answers/pointers/criticism/etc...
Sinan Karasu

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

From: Mike Mstowski <[e-mail]>
Subject: Getty Source Code
Keywords: GETTY SOURCE CODE
Date: 12 Nov 92 11:57:43 GMT
Sender: [e-mail]
To:       [e-mail]

I have to write a getty program for SCO UNIX and possibly for other unix
systems at a later time.  Does anyone have any source code to do this that
I might look at.  The time savings would be great.
Any help is greatly appreciated!
Thanks in advance!
[e-mail]


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


End of UNIX-WIZARDS Digest
**************************