NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/unix/wizards/3834

Internet Message Format | 1992-09-08 | 17.7 KB

Path: sparky!uunet!haven.umd.edu!mimsy!afterlife!adm!news
From: [e-mail] (SMTP MAILER)
Newsgroups: comp.unix.wizards
Subject: Mail Delivery Problem
Message-ID: <[e-mail]>
Date: 7 Sep 92 21:30:57 GMT
Sender: [e-mail]
Lines: 471


 ----Reason for mail failure follows----
Sending mail to recipient(s) woodfordm :
  Couldn't make final delivery.

 ----Transcript of message follows----
Received: from gw1.hanscom.af.mil by vd1.hanscom.af.mil with SMTP ;
          Mon,  7 Sep 92 14:18:31 EST
Date: 6 Sep 92 02:12:00 EST
From: [e-mail]
Subject: UNIX-WIZARDS Digest  V15#139
To: "woodfordm" <[e-mail]>

Return-Path: <[e-mail]>
Received: from SEM.BRL.MIL by gw1.hanscom.af.mil with SMTP ;
          Sun,  6 Sep 92 02:10:42 EST
Received: by SEM.BRL.MIL id aa17470; 5 Sep 92 21:15 EDT
Received: from SEM.BRL.MIL by SEM.BRL.MIL id aa16025; 5 Sep 92 15:29 EDT
Received: from sem.brl.mil by SEM.BRL.MIL id aa15975; 5 Sep 92 15:15 EDT
Date:       Sat, 05 Sep 92 15:15:12 EST
From:       The Moderator (Mike Muuss) <[e-mail]>
To:         [e-mail]
Reply-To:   [e-mail]
Subject:    UNIX-WIZARDS Digest  V15#139
Message-ID:  <[e-mail]>

UNIX-WIZARDS Digest          Sat, 05 Sep 1992              V15#139

Today's Topics:
           Re: Implementation of Sys V. based message queues
                Re: uncompressing an incomplete tar file
                              nroff, troff
                           Re: Disk bad block
                         Unique Job Opportunity
                               fingering
       Re: SCO ODT 1.0 (1.0.0y):  UUCP hangup bugs; uugetty fix?
                        Re: cd'ing to a dir from
                       Re: correcton: restrictin

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

From: "W. Richard Stevens" <[e-mail]>
Subject: Re: Implementation of Sys V. based message queues
Date: 3 Sep 92 23:28:07 GMT
Sender: [e-mail]
Nntp-Posting-Host: gemini.tuc.noao.edu
To:       [e-mail]

>> I would like to be able to use select(2) to multiplex descriptor based
>> objects (sockets) as well as the message queue.
>
> I could be mistaken, but my experience with using Sys V IPC with select()
> is:  'aint no way...

Believe it or not, I just found out that AIX on the RS/6000 actually
provides a function named select() with a different interface that
actually lets you multiplex both descriptors and message queues.
When I saw their interface I almost barfed.

    Rich Stevens  ([e-mail])

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

From: Terry Lambert <[e-mail]>
Subject: Re: uncompressing an incomplete tar file
Date: 2 Sep 92 19:45:27 GMT
Sender: NetNews <[e-mail]>
Nntp-Posting-Host: thisbe.eng.sandy.novell.com
To:       [e-mail]

In article <[e-mail]> [e-mail] writes:
[ ... tar stuff on, but it doesn't tar off ... ]
>3) TARed it onto TK50 tapes (~150 Meg)

TK50 drives will only hold ~60 Meg.  Maybe you meant a TK70?  If not,
this could be your problem.


                    Terry Lambert
                    [e-mail]
                    [e-mail]

---
Disclaimer:  Any opinions in this posting are my own and not those of
my present or previous employers.

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

From: "Mr. Michael Grabenstein; ACS (GUEST" <[e-mail]>
MMDF-Warning:  Parse error in original version of preceding line at BRL.MIL
Subject: nroff, troff
Date: 1 Sep 92 21:26:08 GMT
Sender: News posting account <[e-mail]>
To:       [e-mail]


    I am tring to get nroff or troff to paginate a textfile.
I just need to center a few things, indent under the headings.
Simple stuff, I have looked into the macros me and ms, but have
not had any luck. The commands I am getting in the man don't seem
to do the same thing on the screen (or printer). I know O'Riely
makes a a book about this, but I did not want to have to buy it
(or read it). The man page I get on nroff says nothing about its
text commands, just its command line arguments. I am using a Sun
(SunOS 4.1.1) and printing to a DecScript laser printer. The Dec
5000 is also my print spooler. any suggestions anyone?
    Thanks!

Later,
    Mike
    [e-mail]
    or [e-mail]
}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{
The universe -- The ultimate fractal.
    --Personal theroy

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

From: Dave Olson <[e-mail]>
Subject: Re: Disk bad block
Date: 3 Sep 92 02:14:12 GMT
Sender: Net News <[e-mail]>
To:       [e-mail]

In <[e-mail]> [e-mail] (P S Narayan) writes:
| Could any one tell me how does the file manager in the Unix File System
| detect a bad block and keep a track of it so that it is never allocated
| to any file. What is badness in a block ?
| I imagine the bad block list  is kept in the zeroth block of the  filesystem.

You need to be far more specific, as to what unix version, and what
kind of disks you are referring to; there is tremendous variation.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   [e-mail]

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

From: MacKenzie Tuttle <[e-mail]>
Subject: Unique Job Opportunity
Date: 3 Sep 92 19:17:23 GMT
Sender: [e-mail]
Originator: tuttle@sun21
To:       [e-mail]

WANTED:

UNIX WIZARD TO HEAD OUR SUPERSTAR SYSTEMS TEAM


D. E. Shaw & Co. is a small, young, highly capitalized, extremely
successful Wall Street firm specializing in quantitative finance and
computational trading.  We are looking to hire Systems Programmers to
join a select team of software engineers involved in building
state-of-the-art computer systems that trade billions of dollars worth
of securities.

NOTE: We are _not_ a typical financial firm.  We are a group of
financial hackers out to beat the market.  We do not wear suits and
ties.

Potential six-figure salary for Head of Systems.  Extremely well
compensated junior positions are available as well.

The successful candidate will have strong knowledge of UNIX, C, and
various distributed and networked environments.  Four or more years
experience in systems programming or administration, and an
undergraduate or graduate degree in Computer Science or a related
field, is required.

Responsibilities, depending on the position, include building
distributed real-time applications and designing, supporting, and
enhancing our networked computing environment.  It is our practice to
compensate unusually gifted individuals at a level exceeding that of
the market. Applicants are encouraged to forward their resumes in
confidence to:

                  MacKenzie Tuttle
                  D. E. Shaw & Co.
                  Tower 45, 39th Floor
                  120 West 45th Street
                  New York, NY  10036

                  email: [e-mail]
                  Fax: [phone]

--
Mackenzie Tuttle        D. E. Shaw & Co., New York, NY
[e-mail]        [phone]

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

From: Benoit Robichaud <[e-mail]>
Subject: fingering
Date: 3 Sep 92 17:40:44 GMT
Sender: [e-mail]
To:       [e-mail]


May be those are FAQ but ....

    Is there a way to know if someone is :

    - "fingering" me ?
    - trying do do "more" on one of my files (permitted or not) ?

thanks
Benoit

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

From: A Wizard of Earth C <[e-mail]>
Subject: Re: SCO ODT 1.0 (1.0.0y):  UUCP hangup bugs; uugetty fix?
Keywords: uucp, uugetty, stty, hupcl, clocal
Date: 4 Sep 92 06:37:04 GMT
Sender: [e-mail]
To:       [e-mail]

In article <[e-mail]> uunet!duke.cs.duke.edu!wolves!tcsrtp!royc writes:
>
>1)  If I use the modem control device (sat tty1A) so that DCD
>  is listened to and causes hang up
>    a)  stty clocal fails to alter behavior of uugetty
>    b) uugetty fns inbound AOK but always talks even with '-r'
>    c)  which in turn creates a lock file and stops outbound usage
>    d)  I can't 'cu -l tty1A' until DCD is high ...
>       (using DSR for DCD fixes)

The modem control device is definitely the correct one.  The problem appears
to be that you have not set your modem so:

o    Respond to DTR
o    Verbose replies
o    Send Result codes
o    No character echo    <---
o    Autoanswer
o    Respond to DCD        <---
o    RJ11 single line
o    The modem should listen to commands

(Items marked with "<---" are probably incorrect).

The switch settings for a Hayes Smartmodem 300 or 1200 are:

    1    up
    2    up
    3    down
    4    down
    5    up
    6    up
    7    up
    8    down

An Avatek modem should have switched 6 and 7 down.  An additional switch
    (can't remember which one) needs to be down for autoanswer.
An NCR 1200 should have all switches but 1,2,6, and 9 up.
A MicroCom 2400 should have switches 1, 5, and 6 up (on the front) and
    switched 5 and 7 down (on the back)..
A Peachtree 1200 modem should all switches but 3, 4, and 6 down.
A US Robotics Courier or Microlink should have switches 3,4,8, and 9 down.
A US Robotics Password should have all switches up.
A "soft-programmed" modem should have the following commands typed at it:
    AT&C0
    AT&D1
    AT&W
You should reset to factory defaults before doing this.

>
>... all on a 9pin connector.
>

Also, for a 9 pin connector, the cable should force RTS high on the computer
side by tying it to DTR (since 9 pin connectors are 1 pin short of full
modem control, which requires 10 if chassis ground takes a pin).  Pins 4 and 5
should be tied together (in the connector hood!  No connection to the cable!)
on the modem side.

The PC's serial port is DTE.  A 9 pin DCE port (such as on an Altos) needs
the following cable:

    2 --- 3
    3 --- 2
    5 --- 7
    6 --- 8
    4 -+- 20
    8 -+

This indicates that 4 and 8 on the 9 pin computer side should be tied to pin
20 on the 25 pin modem side.

On 25 pin to 25 pin, 6 does not connect through -- instead, it connects to
pin 8 on the same side.  Pin 8 will connect to pin 20 on the other side
if 2&3 have to be crossed, or pin 8 on the other side if this is not the
case.  4&5 should be tied together on the computer and modem ends with no
connection in between (unless you have the device driver writer tell you
different, in which case, he's probably ignoring a lockup-on-line-loss
window or is unfamiliar with your modem).  Chassis ground should be connected
on one end only (the one with the best ground) it's purpose is to act as
a Faraday cage for wire noise (all loose wires in a cable should hook to
chassis ground on one end only) and connecting both ends may result in a
ground loop (ie: pin 1-1 is connected and pin 7-7 is connected and the
power supplies have different ideas of a 0 voltage reference).

If you are using a Bell 103-C DataSet, feel free to connect pins 4 & 5, as
this is one of the few modems that understands CTS/RTS and how to handle it
as UNIX perceives it with regards to DTR/DCD transitions.  (Built in
monopoly).

>    Basically, uugetty ought to keep its mouth shut
>    until a character whatever happens to the cvontrol
>    lines on a modem control port and 'clocal'/'-clocal'
>
>    should WORK RIGHT on tty lines ...

Basically, using tty1A instead of tty1a will make getty or uugetty keep
quiet until the modem asserts DCD.

Your *modem* should ignore data from the computer until DTR is asserted
and your *modem* should reset as if powered off-then-on-again on an
on-to-off transition of DTR by the computer.

Your *computer* should use a modem control port (requires a kernel or boot
monitor patch on Sun -- call Telebit) and have -CLOCAL and HUPCL set in the
/etc/gettydefs file.  Your *computer* should ignore RTS and assert CTS at
all times if DCD is not high to work with Hayes style modems, but doesn't
(hence the cable mods).


Oh, and *never* use an internal modem and expect it to work; there's no
way you can modify the cable, and the cheap ones won't have appropriate
pullup and pulldown resistors to assert/deassert the proper signals prior
to a connection being made (at which time the line is held active low or
active high, as appropriate.  If you are good at card surgery (like cutting
the IRQ 2/IRQ 9 vertical retrace interrupt line so your VGA card lets you
jumper your ethernet card to IRQ 2/IRQ 9), you may want to buy an internal
modem and solder your own pullup/pulldown resistors.

If you need any more help, buy a comm product (like TERM from Century
Software, 801-268-3088) and make the vendor support you.



                    Terry Lambert
                    [e-mail]
                    [e-mail]
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
 -------------------------------------------------------------------------------
                                                       [e-mail]
 "I have an 8 user poetic license" - me
 -------------------------------------------------------------------------------

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

From: "Dr. R. Chandra" <[e-mail]>
Subject: Re: cd'ing to a dir from
Date: 3 Sep 92 16:41:52 GMT
X-Maildoor: WaflineMail 1.00r
To:       [e-mail]

> [e-mail] (Kari E. Hurtta) writes:
>
> >In article <[e-mail]> [e-mail] (Mike Palmer)
> wrote:
> >> Can anyone suggest a way for a process to cd to a dir & stay there
> >> when the process exits.
>
> >So program must modify its parent's environment ...
> >That's magic.
>
> Yesterday I tried out Norton's ncd for Unix (please no more flame wars
> on
> this topic), and it works. But how? I didn't look whether ncd was suid
> root, but how else can the program mess around in the environment? Or
> is
> this on of the kernel changes Norton Utilities for Unix requires?

Hmmmm....can't tell you for sure.  But if you think about it, the
inheritance rules for exec(2) should work.  The shell that invokes ncd
by exec(2) instead of fork(2)/exec(2), and then ncd can exec(2) either
another program, or its invoking shell program, which ONLY BY CONVENTION
is in the environment variable SHELL (the invoking shell may or may not
choose to pass the environment it got from its parent program (I realize
this term is usually used for only processes...), usually login(1)).
Ergo, let's for a moment assume csh.  You can do

        alias ncd exec ncd

or make it a Bourne function (if sh), or whatever.

 * Q-Blue v0.7 [NR] *

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

From: "Dr. R. Chandra" <[e-mail]>
Subject: Re: correcton: restrictin
Date: 3 Sep 92 16:42:02 GMT
X-Maildoor: WaflineMail 1.00r
To:       [e-mail]

> In article <[e-mail]> [e-mail] (David
> Dymm) writes:
> >I would like to set up a restricted directory tree
> >on my Sun 4 system.  That is, certain users, when logging on,
> >would be placed into accounts that would be located in a
> >directory tree that would not have access to the rest of
> >the system directory structure. ...
>
> The way my college did this was to create the restricted users
> in the 'peon' group-id.
> >All restricted directories were owned by group peon but with NO
> permissions.
> Correction: no GROUP permissions

I like this application.  On a UNIX system which I am writing software
for, I need root access on occasion, but it's a pain to inform me when
the password changes (for doing su(1) for instance), so I have a little
suid binary that does setuid(2) and setgid(2) to the proper values and
exec(2)s a shell.  Since it has to be owned by root, and for me to
execute it, it has to be "world" executable, and giving everyone on the
system a root shell would be a very Bad Thing, it is tucked away in a
subdirectory of my home directory where owner (me) has all permissions
and every other field has no permissions (the key one being search, or
"x").  Therefore, I am the only one besides root who has perms to do
anything to it.  The only difference then is the utmp entry.

> That way, owner and all other have access but NOT peon.
> Although this is contradictory to the intent of permission GRANTING
> vs. permission denial, it works.
>
> ex: /bin2 had commands that were not for peon use (moved over from
> /bin)
> dr-x---r-x   2 bin      peon         1664 Aug 26 16:14 /bin2
[...]
> As already mentioned an other postings, using the restricted shell
> also helps.
> I'm not sure if it was fixed, but there was a bug in how the shell
> determined if it was restricted or not.
> The old code checked for an 'r' in argv[0].  Anywhere in argv[0].
> This bit me when a login for 'smart' (a teaching program) used
> a C program that used 'system' to do something.
> The subshell inherited the argv[0] of 'smart' and since it contained
> an 'r', it went into restricted shell mode.
> The workaround was to alter argv[0] to something without any 'r'.

Ick!  I didn't know about that one.  Thanks!  I'll watch out for it now.

> Set root is tricky becuase you need hard links for all things in /dev,
> /tmp and other things that are below the new root.

Oh, really?  Granted, it is convenient from a system management
viewpoint (should anything in the true /dev/ change), but what's wrong
with mknod(1) in the "new root?"  All's the system needs is the major
and minor numbers from the inode, regardless of where in the directory
tree it gleans this info from.  And there's nothing inherently special
about /tmp either...just that most schemes mount a large disk or disk
partition on it.  That has definite advantages in a system failure (who
cares if fsck can't fix it?  Just mkfs with it and it'll be just fine).
So therefore, if the operative word is "need," I think not.  Desirable,
probably.

 * Q-Blue v0.7 [NR] *

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


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