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

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

Path: sparky!uunet!zaphod.mps.ohio-state.edu!malgudi.oar.net!news.ans.net!cmcl2!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:33:17 GMT
Sender: [e-mail]
Lines: 1721


 ----Mail status follows----
Have been unable to send your mail to <[e-mail]>
for one day, will keep trying for another seven days.
At that time your mail will be returned.

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

Return-Path: <[e-mail]>
Received: from SEM.BRL.MIL by milo.starlab.csc.com with SMTP ;
          Sun, 22 Nov 92 03:19:46 EST
Received: from SEM.BRL.MIL by SEM.BRL.MIL id ab25954; 21 Nov 92 8:04 EST
Received: from sem.brl.mil by SEM.BRL.MIL id aa25917; 21 Nov 92 7:53 EST
Date:       Sat, 21 Nov 92 07:52:51 EST
From:       The Moderator (Mike Muuss) <[e-mail]>
To:         [e-mail]
Reply-To:   [e-mail]
Subject:    UNIX-WIZARDS Digest  V17#004
Message-ID:  <[e-mail]>

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

Today's Topics:
                       Re: The Problem with UNIX
                 Re: Detecting if running under chroot
                 Re: HELP! problem with tar PC <-> SUN
                       Still x_cdplayer problems
                 Secondary Groups Failure Intermittent
                      Re: TLI and non-blocking I/O
                              Re: Thanks,
                  Re: Changing the owner of a process
              Programs to create and apply binary patches?
                Re: Solaris 2.0/2.1 Realtime programming
                         Re: system call write

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

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

In article <[e-mail]> [e-mail] (Ben Ketteridge) writes:
>For example, just to take the 'cat a b > b' problem, you are suggesting IMHO that
>the shell shouldn't check redirection of output against the input and warn the
>user in this case.

Suppose the command was
    prog >b
and "prog" was a shell script that said "cat a b"? Or a C, Lisp, or
Perl program?

How can the shell "know" that the output is also an input? It can't.


--
Bruce Barnett <[e-mail]> uunet!crdgw1!barnett

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

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

In article <[e-mail]> [e-mail] (Michael Lemke) writes:
>   No, I don't.  I am complaining that the options are a) parsed
>   inconsistently (`bla -lx a' might be valid and `bla -l x a' not but
>   `foo -l x a ' is ok and `foo -lx a' is not) and b) that -l means long
>   for ls -l but library for f77 -l.  I want ls -long and f77 -library and
>   be able to abbreviate both -long and -library because `long' and
>   `library' is what I mean and not -l.

>   >It sounds like most of your problem is due to the large number of UNIX
>   >utilities. How many does DOS have?

>   No idea.  I don't know DOS.

Well, what are you comparing Unix to? As I stated, I currently have
2033 commands available. When you consider the large number of
commands, along with the ease of creating new ones, it is no wonder
they are inconsistent. As Boyd says, VMS also has inconsistencies
(I personally don't know enought to comment). ANY system that has the
large number of commands is bought to have inconsistancies, unless the
creation of these programs are under tight control, and we can throw
out backwards compatability. Even so, people will want to deviate from
the strict guidelines because it makes the interface friendlier.

Consider your "-l" example. Unix is considerate of the person typing
all day.  I don't want to type dozens of extra characters for commands
I execute all of the time.

How can you allow variable length options and still allow terseness
when typing?

I don't want to type
    list -long -time  -reverse -all
or
    list -lo -ti  -r -a
or
    list -lo/ti/r/a
or even
    list -l/t/r/a
when I can type
    ls -ltra


Same thing with the -l option to cc/ld.

    -lm
is equivalent to the more logical

     -library=/usr/lib/libm.a
or even
     -library=libm.a
or     -l=libm.a

Unix is inconsistant and power user friendly.

You must also consider the possibility of adding new options (which is
very easy to do.) Consider a command that allowed
    -long
    -lon
    -lo
and
    -l

as valid. Suppose you add a "-low" option? Old scripts who uses "-l"
or "-lo" could break. This is a fatal flaw. You could add new options
that never conflict with previous options, but then this also has
problems because you are forces to select options whoes words that
might not make sense.

IMHO adding consistency to Unix would place an extra burden for the person
typing on the keyboard all day long.
--
Bruce Barnett <[e-mail]> uunet!crdgw1!barnett

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

From: Leslie Mikesell <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 16 Nov 92 18:38:43 GMT
To:       [e-mail]

In article <[e-mail]> [e-mail] (peter da silva) writes:

>No, I am of the opinion that if you want to send binary data you should use
>a program called "send", rather than overloading the semantics on mail. In
>principle you have no idea what the recipient will be able to deal with, and
>in the general case you have no way to know.

I realize that this may be what you *have* to do, but that goes along
with the topic of this thread.  I can't see why it should be that way
except for "historical" reasons which is kind of an anacronism in a
world where two-year old equipment is obsolete.

Besides, if you don't know what the recipient will be able to deal
with, why would you want to send a binary file?

>If your default mail program
>just arbitrarily makes assumptions (in the absence of explicit command line
>options or an interactive exchange) about the capabilities of the recipient
>and mail transfer tools (who knows, they could be on Fido, or Compuserve)
>then you WILL burn people.

This is true of virtually any form of data transfer.  Should tar and cpio
refuse to transfer arbitrary data too, on the assumption that someone
might try to retreive it on a machine where it couldn't be used?

>In the meantime, the following should be a 40 line shell script:

Shell script??? Now who's making assumptions?  Hardly anyone that I
would send a binary attachment to is on a machine that can run a
shell script.

Les Mikesell
  [e-mail]

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

From: The Man Behind The Curtain <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 16 Nov 92 19:57:33 GMT
To:       [e-mail]

Thus spake [e-mail] (Bryan S. So):
>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?
> [..]
>To start the discussion, consider the following problems:
>
>    cat a b > b

Or tail -10 .fingerees > .fingerees
Clearly what I would like to do is chop out all but the last ten
lines of .fingerees (This file contains a list of whoever has
fingered me.  It is now
     124 .fingerees  lines long.  Rather cumbersome.)  But
instead I must do

tail -10 .fingerees > result.txt; mv result.txt .fingerees

A much less elegant solution.  How can the shell know what is
going on however?  What if cat -> /usr/5bin/echo for instance?

So this would be my proposal.  Rather than requiring that the
shell know everything about any possible application it could
run and make it try to figure out all the possible ramifications
of its actions, could we try something like this...

The shell sees
tamsun ~> cat a b > b
First, it finds /usr/bin/cat.  Then it looks inside a file called,
let's say .cat.  The file contains a few lines of specifications
in some language know to the shell like this

% Cat specifications & limitations
% All files on the cmd line are read-only
% Write permission is not given for the current
% process for these files

$* files read-only

end

The shell makes a list of read only files for the current process
(a b) and then proceeds on, and tries open b.  Since permission
is not there, the operation fails and an error message is returned.
(The error msg could possibly be described in .cat)  Though some
shells will return an error msg already, it destroys your data
anyway.  This could avoid it, or allow the specification to tell
it how to deal with it.

For example, ask the user if they wish to concatenate a & b
and store the result in b.  If they answer yes, the shell does...
cat a b > uniq-name; mv uniq-name b
(Being careful about going over quotas, etc.)  And voila!  The
problem was handled with intelligence and grace.  Not to mention
that future programs can inform the shell what actions they are
doing w/o having to rewrite the shell each time to make it guess.

/usr/bin/.echo might be empty or not exist, thus telling the shell
that it doesn't have to worry about protecting/overwriting input
files.  (Of course, .echo must be in the real place of the actual
file...)

Note that this is just being sketched out in rough detail,
particularly when I say something like 'current process' but
I think it would provide a great level of intelligence and
friendliness to the Un*x shell and would be feasible.  What
do true Un*x advocates think?

BTW, the reason why many people are clamoring for a friendlier
Un*x shell is that while Un*x may be expert-friendly, it's lack
of user friendliness will definitely hinder its acceptance in
the larger world.  While some Un*x weenies may scoff at those
who choose other alternatives, doing so only hurts Un*x, for
by expanding and growing it can only improve.  Version numbers
on files, for instance, might be a better way to handle the
above problems for instance.

And Un*x is definitely not "user-friendly," at least not to
anyone I've talked to.  Only Un*x advocates and Un*x tutorials
claim such a thing.  I wonder what they are comparing it
to..  CP/M perhaps?  It is clearly time for Un*x to
reach out and COPY /B someone. + ,,

>Bryan So

--
Till next time,                \o/   \o/
                                V \o/ V     email:[e-mail]
<>  Sam  Inala  <>                 V

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

From: Daniel Smith <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 16 Nov 92 21:42:39 GMT
Followup-To: comp.unix.wizards
To:       [e-mail]

In <[e-mail]> [e-mail] (Michael Lemke) writes:

> In article <[e-mail]> [e-mail] (Ben Ketteridge) writes:
> >For example, just to take the 'cat a b > b' problem, you are suggesting IMHO
> >that
> >the shell shouldn't check redirection of output against the input and warn the
> >user in this case.

> Actually, I think this example should work!  It is a perfectly
> reasonable request.

    No it isn't, consider my "glasses of water" theorem:


         |         |          |           |
         |~~~~~~~~~|          |~~~~~~~~~~~|
         |         |          |           |
         |         |          |           |
         |    A    |          |    B      |
         |         |          |           |
          \_______/            \_________/


    Ok, B can get bigger (i.e. a goblet, or a pitcher) to accept water
from A, but what do you mean to do with B's original water?  I think
B's original water must go to:

         |      |_
         |~~~~~~| \
         |   C  | ||
         |      |_/
          \____/

    C, an arbitrary coffee cup in n-dimensional cupboard space, which
can expand to hold any amount of liquid found in A & B.  I think you're
suggesting throwing B's water up in the air while A's water goes to B,
and having B's water splash on top.  This violates most of the laws of kitchen
physics (see Child, Julia "Fractal Baking") and just makes a big mess.
The third container (Tupperware or otherwise) saves the day.  With
this example, you could pour all of the water from C back into B (mv)
and then put C in the dishwasher (rm).

                Daniel
--
     Daniel Smith, Autodesk, Sausalito, California, [phone] x 2580
          Disclaimer: written by a highly caffeinated mammal
        [e-mail]            [e-mail]

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

From: Greg Brail <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 16 Nov 92 21:59:11 GMT
Sender: [e-mail]
To:       [e-mail]

In article <[e-mail]> [e-mail] (Rich Kulawiec) writes:
>In article <[e-mail]> [e-mail] (Leslie Mikesell) writes:
>>These problems could be solved as easily under unix as anywhere else,
>>except for the fact that people who have spent years learning unix
>>have forgotten that there is a problem.

Bravo! Exactly.

>"Problem" is a matter of opinion; I consider the items you list "features",
>and find the occasional toasting that they give to a user who didn't RTFM
>a helpful educational tool.

Not too many years ago a bunch of Navy crewmen who hadn't read all the FMs
on the USS Vincennes blew up an airliner, killing hundreds of innocent people.
I realize this is an extreme example, but the stone-age attitude that
user interfaces must be cryptic to "teach the user a lesson" is alive and
well in UNIX.

UNIX is becoming more and more common in commercial environments, but this
attitude will drive people away. Fortunately, it's possible to give "Joe
User" a reasonable interface and save the command line for the hackers.

I consider myself a fairly knowledgable UNIX user, but I still type
"tar cvf file.tar ." from time to time and don't realize it until "file.tar"
recursively grows to 200MB and fills the filesystem. Feel free to laugh and
call me an idiot. I really couldn't care less. And I don't expect to
win this argument as long as it stays in comp.unix.wizards, where it
doesn't belong anyway.

> I happen to like the expert-friendly
>and relatively unforgiving nature of most Unix implmentations.  Those
>who feel otherwise are certainly free to implement whatever warm-fuzzy-
>hand-holding-protect-the-user-from-themselves features they wish.

That's why I have a Macintosh at home.

                greg
--
Greg Brail ------------------ Citibank -------------------- [e-mail]
lose (lOOz) v. 1. a. To be unable to find; mislay. b. To incur the
deprivation of, as by negligence or accident. 2. To be unable to maintain,
sustain, or keep. 3. The most commonly misspelled word on Usenet.

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

From: Kenneth Ng <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 17 Nov 92 01:19:06 GMT
To:       [e-mail]

In article <[e-mail]: [e-mail] (Peter Busser) writes:
:[e-mail] (Karl Anderson) writes:
:>Is there any reason why there can't be another stream for more
:>user-friendly messages?
:Yes! Feeping creaturism. I'm pro user friendly messages, but, IMHO, consistency
:and clarity are much more important than verboseness. Furthermore, it would
:require existing programs to be extended with the verbose message.
:A better approach would be, IMHO, to leave the messages what they are and make
:every program return a meaningful error number. A seperate program could
:figure out which verbose message belongs to that number.

I would like to see two things: one, have the program that generates the
error message put *ITS* *NAME* as the first part of the error message.
Second, print something meaningful like perror().  I do not know how many
times I've seen "can not open file" in a script that calls other scripts
that calls a few dozen routines.  So then I have to find out WHAT program
could not open WHAT file.

--
Kenneth Ng
Please reply to [e-mail] for now.
Apple and AT&T lawsuits: Just say NO!

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

From: [e-mail]
Subject: Re: The Problem with UNIX
Date: 17 Nov 92 02:15:38 GMT
To:       [e-mail]

In article <[e-mail]>, [e-mail] (Leslie Mikesell) writes:
> In article <[e-mail]> [e-mail] writes:

> >I disagree on this one.  I can't stand the SVr4 mail program's unwillingness
> >to display a file in which someone has accidentally put ONE backspace or
> >escape.  And of course there are nroff output files with
> >  _^hu_^hn_^hd_^he_^hr_^hl_^hi_^hn_^h_^he  in them.

> I meant the transport does the right thing in delivering the message as
> sent.  I didn't think anyone actually used SysV mail's user interface
> (or lack thereof).

> >This user says `Plugh!'

> Do yourself a favor and compile ELM.

This user says `bletch!'  I've got ELM.  It threw away a valuable piece of
mail on me because the mail included another mail header.  Right now I have
a non-elm mailbox with a message in it that ELM will present out of order.
ELM's handling of the cursor keys is just plain wrong. ... ... ...

What?  It's just fine for you and you haven't noticed any problems?

    Jack Sprat could eat no fat
    And his wife could eat no lean ...

My favorite way to deal with mail is to go into vi, create a mail command
with a here document filled with blank lines and ending in `x', and 1G!Gksh
the whole thing.  It subjects me to the fewest bogons of anything I've got.
(Oh, you don't like vi?  Fine with me.  I'll put emacs up for you ... but
don't pepper our source files with emacs directives or leave incomplete
lines.  Speaking of which, why does emacs display a line number for the
next line when you are at the end and there isn't any next line?  Bogus.)

And _that_, perhaps, is the grace of UNIX over VMS and OS/2 and Motif
and all those other highly-polished, highly developed straitjackets.

    There are four ways to do any task: the Right Way, the Wrong
    Way, the Navy Way, and My Way.  And this, gentlemen, is my ship.
--
 (This man's opinions are his own.)
 From mole-end                Mark Terribile

 [e-mail], Somewhere in Matawan, NJ

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

From: Valdis Kletnieks <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 17 Nov 92 02:23:12 GMT
Sender: [e-mail]
Followup-To: comp.unix.wizards
To:       [e-mail]

In article <[e-mail]> [e-mail] (Eric Eide) writes:
>
>It sounds as if you are proposing the invention of an application-independent
>command line parser that does more than just syntactic processing (as provided
>by getopt()).  This would definitely be interesting -- but is it really
>possible?  What would it look like?  What would the universal meaning of `-l'?

Didn't the opsys on the DEC-20 (twenex?) do this?  I think it even
allowed 'completion' of more than just filetypes - however, it *did*
involve firing up the binary of the program a bit earlier because
there was some incestuous relationship between the command's code
and the command line interpreter.  Essentially, the command had
a section of code that could be called by the interpreter to
"assist" parsing.

Twenex gurus feel free to correct me.

                Valdis Kletnieks
                Computer Systems Engineer
                Virginia Tech

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

From: Oleg Kibirev <oleg@gd>
Subject: Re: The Problem with UNIX
Date: 17 Nov 92 07:47:20 GMT
Nntp-Posting-Host: gd.cs.csufresno.edu
To:       [e-mail]

In article <[e-mail]> [e-mail] (Peter Busser) writes:
>[e-mail] (Karl Anderson) writes:
>
>>Is there any reason why there can't be another stream for more
>>user-friendly messages?
>
>Yes! Feeping creaturism. I'm pro user friendly messages, but, IMHO, consistency
>and clarity are much more important than verboseness. Furthermore, it would
>require existing programs to be extended with the verbose message.
>
>A better approach would be, IMHO, to leave the messages what they are and make
>every program return a meaningful error number. A seperate program could

This remindes me about real old Hewlett Packard BASIC interpeter...
???
RUN
ERROR 4578 IN LINE 8083

>figure out which verbose message belongs to that number. That saves several K's
>of text for each program and makes translation to foreign langauges much
>easier. The user who uses such a tool gradually learns to associate the terse

I suppose you have heard about shared libraries ;-).

Seriously, I would really appreciate a call like eprintf that accepts the same
arguments as printf but also has staff like %n for program name, %m for message,
%p for callers PID etc. This would encourage people to use more meaninfull diagnostics.

Oleg

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

From: Stephen Riehm <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 17 Nov 92 12:39:31 GMT
Sender: [e-mail]
To:       [e-mail]

oleg@gd. (Oleg Kibirev) writes:

> Seriously, I would really appreciate a call like eprintf that accepts
> the same arguments as printf but also has staff like %n for program
> name, %m for message, %p for callers PID etc. This would encourage people
> to use more meaningful diagnostics.

It already exists:
    fprintf(stderr,"%s[%d]: %s\n", argv[0], (int)getpid(), "message");

Of course there are the usual 50,000 different ways of formatting this
same line, but the code is there, the problem is that people don't use
it. The second problem is that there are guys out there who get
wonderful new schemes in their heads, and insist that everyone working
on their project use this wonderful new scheme (I do this sometimes,
but I am leveling out in my young age), there is no STANDARD way of
producing errors, printing to stderr is about as close as you get. I
really feel that it just takes a very small amount of clear thinking
combined with an even smaller amount of effort to do it RIGHT (but
according to whose definition of RIGHT?).

Of course if you really want to "sell the product", you should be
using NLS (or some equivalent), then your code is reduced when
printing errors, and you don't need to change the code to use it with
heaps of different languages.

while on the subject of international character sets, to read the name
of my city in my .sig below, you will need the ISO-8859-1 (latin1)
character set :-) (ASCII + 1 bit)

catchya

 -----------------------------------------------------------------
Stephen Riehm        Configuration Management       _-_|\
[e-mail]    Philips Kommunikations Industrie  /     \
Work: [phone]    N|rnberg, Germany          \_.-.!/
Fax:  [phone]    "I was there, now I am here!"           v
"My company speaks another language, I CAN'T speak on its' behalf"

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

From: der Mouse <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 17 Nov 92 13:03:41 GMT
To:       [e-mail]

In article <[e-mail]>, [e-mail] (Robert Hartman) writes:

[quoted stuff deleted - irrelevant]
> You know, I see merit in both of these approaches.  The command line
> parser should be a library routine in stdio.

(Why stdio?  It's got nothing to do with I/O.)

> The shell should use command and option completion prior to exec,

Where is it supposed to find the information it'll need to do that,
such as what options the program takes, which arguments are files and
which are strings, etc?

                    der Mouse

                [e-mail]

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

From: der Mouse <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 17 Nov 92 13:22:56 GMT
To:       [e-mail]

In article <[e-mail]>, [e-mail] (Peter Busser) writes:
> [e-mail] (der Mouse) writes:
>> files?  Consider instead "echo a b > b".[%]
> I did just that with bash and it didn't complain.  But yet, echo is
> often a built-in command.

Did you read my footnote?  It addresses exactly that.

>> Is "acceptance in the general microcomputer market place" something
>> we wish for UNIX?
> Acceptance in the general microcomputer market also means more
> software, lower prices, more support (every (S)VGA card ships with
> Windows drivers, but X11 support is harder to get),

Speaking purely personally....

More software?  The sort of software that popularity will bring will of
necessity be mass-market software, which is (a) extortware, (b) dumbed
down to suit the mass market, and (c) usually does something I'm not
the least bit interested in anyway.

Lower prices?  For what?  I will never pay for software, and there's no
reason I can't use mass-market hardware (like, say, a 486 box).

More support?  There's no way in hell I'm even going to be working at a
place that can afford to buy the level of support that just having the
source gives, never mind actually paying it myself.  (I once was on a
consulting job at an organization that had, to support the job in
question, bought support from the relevant vendor.  About all we ever
got out of them was "uh, that's a good question, let me get back to
you".  I can think of only one thing they ever told us that we hadn't
already found out for ourselves by UTSLing (they had, sensibly, also
obtained the source), and that thing was incidental rather than being
what we asked.)

> more UNIX related jobs (or do you prefer to use Windows at work? :),
> more UNIX everything.

Possibly a point, though there's still the danger that they'll not be
the-UNIX-I-love jobs and everything but UNIX-dumbed-down-for-the-masses
jobs and everything.

                    der Mouse

                [e-mail]

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

From: der Mouse <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 17 Nov 92 13:25:17 GMT
To:       [e-mail]

In article <[e-mail]>, [e-mail] (Peter Busser) writes:
> [e-mail] (Antony A. Courtney) writes:

>> and structural elegance of that other system once called UNIX.
> That's a good point!  For instance, instead of using the creat()
> system call, which creates a file with given permissions, they added
> a parameter open() to duplicate the functionality of creat().

That's a point.  They should have had the guts to dump creat() when
they folded it into open().  (Or are you saying they shouldn't have
extended open?  Would you prefer to have a separate syscall for each
permutation of flag bits in the second argument to current open()?)

                    der Mouse

                [e-mail]

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

From: Shobhana <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 17 Nov 92 13:36:05 GMT
To:       [e-mail]

In article <[e-mail]> [e-mail] (Peter Busser) writes:
>[e-mail] (der Mouse) writes:
>
>>    cat a b > b
>
>>files?  Consider instead "echo a b > b".[%]
>
>I did just that with bash and it didn't complain. But yet, echo is often a
>built-in command. It complained about 'cat a b >b' but didn't complain about
>'cat a b|cat>b' so it's not perfect.

I haven't followed this thread from the beginning, so if I am
saying something irrelevant let me know (oh, I'm sure you will ;-)

Anyway, cat's complaint about input and output file being the same
is produced by cat(1) and *not* by .*sh(1). So what *is* the problem?

I presume that there is a school of thought which says that *sh should
detect such problems and let you know about it. IMHO, the command
interpreter *cannot* and should not make such decisions. e.g the name
of a file means different things to cat(1) and echo(1)---sh(1) has *no*
way of knowing this and should not even attempt to guess.

Regards

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

From: Rich Kulawiec <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 17 Nov 92 13:56:28 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] (The Man Behind The Curtain) writes:
>While some Un*x weenies may scoff at those who choose other alternatives,
>doing so only hurts Un*x, for by expanding and growing it can only improve.

This is a fascinating assertion; I submit that the historical record
shows, in excruciating detail, that the expansion and growth of Unix
has all-but-destroyed its simple elegance.  The gentle reader is
invited to read a v6 or v7 manual (which will only take an afternoon)
and then compare it to SunOS 4.1.3, for instance, with a careful eye
to the functionality/overhead ratio in both systems.

---Rsk

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

From: Mike Bandy <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 17 Nov 92 17:32:11 GMT
To:       [e-mail]

[e-mail] (Mike Hollander) writes:

>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!

Run VMS!  The VMS command line interpretor does all these things flawlessly.
Being an AC/DC kind of guy (WRT operating systems, that is) I can say that
the one thing I really miss when I use Unix is the command editing using the
arrow keys.  The Ultrix system I used at grad school allowed the command
to be recalled with the up/down keys, cursor positioned at the point
that needed changing via left/right arrows, etc.  Admitedly, I'm not a real
power user, but I have never been able to remember how to recall/edit past the
previous using the "^" sequence.  And the fact that it does the edit, then
executes it, rather than waiting for a carriage return has always disturbed me.

I know I'm setting myself up to be flamed; bring it on.

>Mike Hollander | [e-mail]
--

    Mike Bandy
    [e-mail]
    Johns Hopkins University / Applied Physics Lab

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

From: Steve McDowell <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 17 Nov 92 19:35:12 GMT
To:       [e-mail]

In message <[e-mail]> [e-mail] (Mike Bandy) writes:
>
> Run VMS!  The VMS command line interpretor does all these things flawlessly.

People run UNIX for a reason. VMS isn't usually an alternative.

> The Ultrix system I used at grad school allowed the command
> to be recalled with the up/down keys, cursor positioned at the point
> that needed changing via left/right arrows, etc.  Admitedly, I'm not a real
> power user, but I have never been able to remember how to recall/edit past the
> previous using the "^" sequence.  And the fact that it does the edit, then
> executes it, rather than waiting for a carriage return has always disturbed me.

Then get a new shell. Ksh comes to mind. And it comes with most SysV systems. And
it runs on most BSD-derived systems. I think the point's been made before that
the user interface is *not* the operating system, and that (to me) is one of the
many joys of UNIX.

> I know I'm setting myself up to be flamed; bring it on.

No flames, just calm rational discussion. Whether "running VMS" is rational I'll
leave up to you.

--
Steve McDowell             . . . . o o o o o         Opinions are
Exlog, Inc.                      _____      o         mine, not my
[e-mail]      _____====  ]OO|_n_n__][.        employers..
               [_________]_|__|________)<

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

From: Pete Hardie <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 17 Nov 92 20:58:36 GMT
To:       [e-mail]

In article <[e-mail]> [e-mail] (Greg Brail) writes:
>Not too many years ago a bunch of Navy crewmen who hadn't read all the FMs
>on the USS Vincennes blew up an airliner, killing hundreds of innocent people.

Wasn't that airliner also using a transponder scavenged from a military jet,
giving it a military 'profile' on radar?

>UNIX is becoming more and more common in commercial environments, but this
>attitude will drive people away. Fortunately, it's possible to give "Joe
>User" a reasonable interface and save the command line for the hackers.

Sometimes a command line *is* the reasonable interface.

>That's why I have a Macintosh at home.

Try this:  list all the C code files in a given directory on your Mac, using
the iconinc interface.  Only files with '.c' suffix.


--
Pete Hardie:  phardie@nastar  (voice) [phone]
Digital Transmission Systems, Inc., Duluth GA
Member, DTS Dart Team           |  cat * | egrep -v "signature virus|infection"
Position:  Goalie               |

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

From: Robert Hartman <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 17 Nov 92 23:09:45 GMT
Sender: Usenet News <[e-mail]>
To:       [e-mail]

In article <[e-mail]> [e-mail] (der Mouse) writes:
>In article <[e-mail]>, [e-mail] (Robert Hartman) writes:
>
>[quoted stuff deleted - irrelevant]
>> You know, I see merit in both of these approaches.  The command line
>> parser should be a library routine in stdio.
>
>(Why stdio?  It's got nothing to do with I/O.)

I suppose you're right.  This is really extended processing of argv.

>> The shell should use command and option completion prior to exec,
>
>Where is it supposed to find the information it'll need to do that,
>such as what options the program takes, which arguments are files and
>which are strings, etc?

Well, at start-up, the shell could read a file with this information
and create a hash table.  I'm sure other people can think of other
ways to do it.

-r

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

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

In article <[e-mail]> [e-mail] (der Mouse) writes:
> Yes, it might.  So what?  Is "acceptance in the general microcomputer
> market place" something we wish for UNIX?

If we want to keep being able to buy nice cheap UNIX systems with decent
performance for the long-term, yes.

I would say that a friendly shell that does all the command parsing (like
DCL does) would be quite a nice touch.
--
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: Leslie Mikesell <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 17 Nov 92 23:48:05 GMT
To:       [e-mail]

In article <[e-mail]> [e-mail] (der Mouse) writes:

>That's a point.  They should have had the guts to dump creat() when
>they folded it into open().  (Or are you saying they shouldn't have
>extended open?  Would you prefer to have a separate syscall for each
>permutation of flag bits in the second argument to current open()?)

I'd prefer to have more arguments - for example to control locking the
file atomically with the open().  It just seems so inelegant to open
a file, possibly creating it, and then to have to fight with other
processes over who has control of it.  And the traditional unix solution
of using separate lockfiles has a worse problem: there's no way to
remove a stale one safely.

Les Mikesell
  [e-mail]

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

From: Leslie Mikesell <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 18 Nov 92 00:01:27 GMT
To:       [e-mail]

In article <[e-mail]> [e-mail] writes:
>> Do yourself a favor and compile ELM.
>
>This user says `bletch!'  I've got ELM.  It threw away a valuable piece of
>mail on me because the mail included another mail header.

This is fixed in 2.4 if you tell it your mailer uses the Content-Length:
headers.  It also won't blow up when the mail contains null characters
now.

>Right now I have
>a non-elm mailbox with a message in it that ELM will present out of order.

What is your sort order?  Set it to 'reverse mailbox' if you want the
stock mail order (and then it doesn't depend on the mailer getting the
date format right either).

>ELM's handling of the cursor keys is just plain wrong. ... ... ...
>What?  It's just fine for you and you haven't noticed any problems?

Odd maybe, but it works for me.  Up/down go by messages, left/right
go by screens.  I always use j & k anyway.  What happens for you?

>My favorite way to deal with mail is to go into vi, create a mail command
>with a here document filled with blank lines and ending in `x', and 1G!Gksh
>the whole thing.  It subjects me to the fewest bogons of anything I've got.
>(Oh, you don't like vi?  Fine with me.

Actually I like vi but I don't see the point of that exercise.  How about
cat /usr/mail/you?  Or more useful: less /usr/mail/you (pg if you don't
have less).

Les Mikesell
  [e-mail]

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

From: peter da silva <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 18 Nov 92 00:14:00 GMT
To:       [e-mail]

In article <[e-mail]> [e-mail] (Michael Lemke) writes:
> This would all be
> solved if there were *one* system function that is used by all programs
> instead of having every program duplicate more or less the same
> functionality with different success.

See Eric Allman's "Parseargs" utility. It's great.

I have it set up so the same program on UNIX accepts:

    foo -abc -d bar
or
    foo +apple +banana +carrot +diet bar

And on AmigaOS (with a different convention):

    foo apple banana carrot diet=bar
or
    foo a b c d=bar

And it's also been extended to VMS and DOS:

    foo/apple/banana/carrot/diet=bar
or
    foo/apple/banana/carrot bar/diet
or
    foo/a/b/c bar/d
--
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: 18 Nov 92 00:22:04 GMT
To:       [e-mail]

In article <-ml1H31![e-mail]> [e-mail] (David Barr) writes:
> >This would all be
> >solved if there were *one* system function that is used by all programs
> >instead of having every program duplicate more or less the same
> >functionality with different success.

> You mean like getopt(3)?

getopt is practically worthless. It doesn't do enough parsing to be worth
using, and doesn't provide any sort of useful diagnostics. With the example
in my last message, you'd say:

    foo -d
and get
    foo: required argument to -d (diet) missing.
    Usage: foo [-abc] [-d diet]

And by setting $VERBOSE it'd add

        -a    Eat an apple.
        -b    Eat a banana.
        -c    Eat a carrot.
        -d diet    Use diet plan in file <diet>

Let's try (this is a slightly older version of the library):

% //xds13/usr1/xds/src/docindex/docindex
docindex: MasterFile ('master' files) required for -m flag
docindex: IndexFile ('index' files) required for -i flag
docindex: HistoryFile ('history' files) required for -h flag
Usage: docindex -m <MasterFile>... -i <IndexFile>... -h <HistoryFile>... \
    [-p <MsgidPattern>] [-v] [-q]

With the source:

struct arglist *MasterFiles = NULL;
struct arglist *HistoryFiles = NULL;
struct arglist *IndexFiles = NULL;
char *msgid_pattern = "<doc.";
BOOL Verbose = 0;
BOOL Quiet = 0;

ARGDESC    Args[] =
{
'm', ARGREQ|ARGLIST,listStr, __ &MasterFiles,"MasterFile ('master' files)",
'i', ARGREQ|ARGLIST,listStr, __ &IndexFiles,"IndexFile ('index' files)",
'h', ARGREQ|ARGLIST,listStr, __ &HistoryFiles,"HistoryFile ('history' files)",
'p', ARGOPT, argStr, __&msgid_pattern, "MsgidPattern (magic string for msgid)",
'v', ARGOPT, argBool, __&Verbose, "Verbose (report database changes)",
'q', ARGOPT, argBool, __&Quiet, "Quiet (about missing data or index files)",
ENDOFARGS
};

main(argc, argv)
    int argc;
    char **argv;
{
    parseargs(argv, Args);
    ...
--
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: 18 Nov 92 00:31:24 GMT
To:       [e-mail]

In article <[e-mail]> [e-mail] (Ben Ketteridge) writes:
> For example, just to take the 'cat a b > b' problem, you are suggesting IMHO
> that the shell shouldn't check redirection of output against the input
> and warn the user in this case.

How does the shell know that the "b" argument to cat is the same as the "b"
output file? Because the file exists?

touch b a
cat a b > b
b: File exists.

What's your problem?
--
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: "Bryan S. So" <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 18 Nov 92 02:04:02 GMT
Sender: The News <[e-mail]>
To:       [e-mail]

In response to my suggestion that the shell should help the user
buffer "b" when it sees the command "cat a b > b",
[e-mail] (Marc Unangst) writes:

>There are also problems with buffering the input.  What if the "b" is
>a FIFO or a device, not a regular file?  In that case, "cat b > b" is
>perfectly valid and not at all abnormal.  What if "b" is a Unix-domain
>socket, and the program at the other end writes something and then
>waits for a response before closing the file?  Your program will never
>run, because Unix will be sitting there waiting to read the "rest" of
>the input file before giving the program control.

 If "b" is a FIFO, it may make "cat b > b" syntactically or even
 semantically valid.  But how would it make that psychologically
 valid?

 I suppose "cat a > a" or some variance of it is documented
 somewhere as "pitfalls" and users warned.  So, whoever thought
 up a FIFO "b", such that the proper usage is "cat b > b", is
 just absurd.  Can you give a practical application for such use?


Bryan

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

From: Peter Busser <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 18 Nov 92 02:21:27 GMT
To:       [e-mail]

oleg@gd. (Oleg Kibirev) writes:

>This remindes me about real old Hewlett Packard BASIC interpeter...
>???
>RUN
>ERROR 4578 IN LINE 8083

That's what IBM did for years (for instance the 5288) and still does (OS/2)!
But that's not what I meant. Now programs call exit() to return an error code
to the parent process. I meant to use THAT value. However, I realize that it
is not easy to get that error number and it doesn't have a standard meaning.

>>figure out which verbose message belongs to that number. That saves several K's
>>of text for each program and makes translation to foreign langauges much
>>easier. The user who uses such a tool gradually learns to associate the terse
>I suppose you have heard about shared libraries ;-).

Yes, but a text file is much easier to edit than a shared library...

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

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


Concerning whether "cat a b > b" should prepend or give warning or does
whatever it's now doing,

In article <[e-mail]> [e-mail] (Ben Ketteridge) writes:

]     Actually, I think this example should work!  It is a perfectly
]     reasonable request.

Another opinion says,

In article <[e-mail]> [e-mail] (Daniel Smith) writes:
)
)    No it isn't, consider my "glasses of water" theorem:
>
)
)         |         |          |           |
)         |~~~~~~~~~|          |~~~~~~~~~~~|
)         |         |          |           |
)         |         |          |           |
)         |    A    |          |    B      |
)         |         |          |           |
)          \_______/            \_________/
)
)
)    Ok, B can get bigger (i.e. a goblet, or a pitcher) to accept water
)from A, but what do you mean to do with B's original water?  I think
)B's original water must go to:
)
)         |      |_
)         |~~~~~~| \
)         |   C  | ||
)         |      |_/
)          \____/
)
)    C, an arbitrary coffee cup in n-dimensional cupboard space, which
)can expand to hold any amount of liquid found in A & B.  I think you're
)suggesting throwing B's water up in the air while A's water goes to B,
)and having B's water splash on top.  This violates most of the laws of kitchen
)physics (see Child, Julia "Fractal Baking") and just makes a big mess.
)The third container (Tupperware or otherwise) saves the day.  With
)this example, you could pour all of the water from C back into B (mv)
)and then put C in the dishwasher (rm).


I would think,

 This glasses of water theorem is biased in a sense that Cup C can
 expand to hold any amount of liquid while Cup A and Cup B cannot.

 My mental model interpret a file as "n-dimensional cupboard space,
 which can expand to hold any amount of liquid".  So, "cat a b > b"
 is reasonable.


Bryan

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

From: der Mouse <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 18 Nov 92 11:06:09 GMT
To:       [e-mail]

In article <[e-mail]>, oleg@gd. (Oleg Kibirev) writes:

> Seriously, I would really appreciate a call like eprintf that accepts
> the same arguments as printf but also has staff like %n for program
> name, %m for message, %p for callers PID etc.

All of these are available:

%s    argv[0],
%s    ((errno>0)&&(errno<sys_nerr))?sys_errlist[errno]:"Unknown error"
%d    getpid()

Given the ugliness (and incompleteness - it should include the error
number in the "unknown error" clause) of the second one, I hacked on
printf to add a %m spec, which takes an errno and generates the
corresponding message.  Makes printing error messages ever so much
easier to write...

    fprintf(stderr,"%s: can't open %s: %m\n",argvec[0],fn,errno);

Of course, this helps only when errno contains something useful.  Far
too many things don't do this - fopen, for example, does not have
anything to do with errno as any part of its contract....

                    der Mouse

                [e-mail]

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

From: Matthias Urlichs <[e-mail]>
Subject: Re: Detecting if running under chroot
Date: 16 Nov 92 17:23:47 GMT
NNTP-Posting-Host: 127.0.0.1
To:       [e-mail]

In comp.unix.wizards, article <[e-mail]>,
  [e-mail] (Paul Hite) writes:
>
> Well I've played around some public access bbs systems that thew me into a
> chroot env.  From a practical standpoint, I quickly noticed how little I could
> do.  It just had the "feel" of a chroot environment.  But I guess that you're
> looking for a more formal method.  I would examine the inode of the root.  I
> think something like "ls -id /" should do it.  But I still say that most
> chroot'd environments that I have seen don't really need much effort to
> detect.
>
Doesn't work if the chrooted environment resides on the root of another file
system.

I'd say that any way to detect a chrooted environment from first principles,
i.e. other than finding a local news server but no newsspool, is declared
a bug in the OS.

--
What if everything is an illusion and nothing exists?  In that case, I
definitely overpaid for my carpet.
        -- Woody Allen, "Without Feathers"
--
Matthias Urlichs  --  [e-mail] -- [e-mail]   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  [phone]     \o)/

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

From: Oleg Kibirev <oleg@gd>
Subject: Re: Detecting if running under chroot
Date: 17 Nov 92 07:17:03 GMT
Nntp-Posting-Host: gd.cs.csufresno.edu
To:       [e-mail]

In article <[e-mail]> [e-mail] (Matthias Urlichs) writes:
>In comp.unix.wizards, article <[e-mail]>,
>  [e-mail] (Paul Hite) writes:
>>
>> Well I've played around some public access bbs systems that thew me into a
>> chroot env.  From a practical standpoint, I quickly noticed how little I could
>> do.  It just had the "feel" of a chroot environment.  But I guess that you're
>> looking for a more formal method.  I would examine the inode of the root.  I
>> think something like "ls -id /" should do it.  But I still say that most
>> chroot'd environments that I have seen don't really need much effort to
>> detect.
>>
>Doesn't work if the chrooted environment resides on the root of another file
>system.
>
>I'd say that any way to detect a chrooted environment from first principles,
>i.e. other than finding a local news server but no newsspool, is declared
>a bug in the OS.
>
Yup. Consider chroot /.

Oleg

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

From: Mark Sienkiewicz <[e-mail]>
Subject: Re: HELP! problem with tar PC <-> SUN
Date: 16 Nov 92 19:01:46 GMT
Sender: [e-mail]
To:       [e-mail]

In article <[e-mail]> [e-mail] (Dave Eisen) writes:
>This probably still won't make him happy. He'll want to read tapes
>that were created with a blocking factor of 20 using a blocking
>factor of 20 and tapes that were created with a blocking factor of
>2 using a blocking factor of 2. In other words, he wants tar to

I agree the client is being unreasonable, but I can't remember _ever_
working for a client who was not unreasonable at least some of the time.

>be clairvoyent. If this is the case, all you can do is tell him that
>he wants something impossible and hope you don't lose the business.

On most systems I've used, you can detect the block size of a tape by
doing something like:

    char buffer[BIGGEST_POSSIBLE_RECORD_SIZE];

    n=read(fd,buffer,sizeof(buffer));
    printf("block size is %d bytes\n",n);

Mark S.

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

From: Doug Walker <[e-mail]>
Subject: Still x_cdplayer problems
Date: 16 Nov 92 21:01:46 GMT
Sender: USENET News System <[e-mail]>
To:       [e-mail]

Only got one response from my last post and that waas not the problem
but thank you anyway.

Here is my problem:

I am trying to get xcdplayer to work on a tatung compstation 25 running
sunos 4.1.2.  It is a Hitachi cdplayer.  When I run xcdplayer I get

superboy 1 > xcdplayer
ioctl(cdromreadtochdr): I/O error

I have gone back to the release cdrom and pulled the x_cdplayer that
came with 4.1.2.  If I run it after having already inserted the cd I get
the response:

I/O Error

If I run it with no cd in the player I get the application up but then
upon inserting the cd it does not recognize that there is a cd in there.

The message

sr0: logical unit not ready

appears in the console wheneveer I try to play the cd.

Help, please.

Thank you.

--
Doug

Ask not what your country can do for you, but what you can
do for your country.  - JFK

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

From: Andrew Luck <[e-mail]>
Subject: Secondary Groups Failure Intermittent
Date: 17 Nov 92 11:48:19 GMT
Sender: [e-mail]
Nntp-Posting-Host: 127.0.0.1
X-Mailer: PSILink (3.2)
To:       [e-mail]

Dear Friends,

I am having real difficulty with giving access to a variety of users
segemented into different groups to a number of partitions.

The general outline is:

SUN IPX running NFS/NIS and acting as server for PC/NFS
Users are having problems regardless of method of access
(PCNFS, telnet, direct), so PCNFS appears not to be relevant.

Partitioned into several areas for different groups
Partitions are:  /   /home  /usr    /struc   /trans    etc....
Some users (groups) need multi-partition access

Adding some users to secondary groups using the groups database works
Adding others to the groups database doesn't work
No particular pattern is apparent
We are getting desparate.

Can you please help out if you have run into this before?

A message from another system administrator follows:

 --------------------
Andrew:

I am totally stopped on this problem.  Everything IS right ( to my
knowledge). We may have to go to the 'net for help (since we don't
have a mainteance contract ;-) ). The particulars are:

Extract of passwd file:

mgaines:<removed>:2005:1001:Mark Gaines:/home/gru5/mgaines:/bin/csh
jwhisner:<removed>:2012:1001:Jim Whisner:/home/gru5/jwhisner:/bin/csh

Extract of group file:

tranengr:*:1001:transmgr
trangrap:*:1002:pnaranjo,wegan,ksaunder,mgaines,ebennett,jwhisner,transmgr,rlewis,jprather,jsmith,fstrmbrg,awebster,kwalsh
structur:*:1003:transmgr

Output from "groups" commands:

mgaines : trangrap tranengr
jwhisner : trangrap tranengr

Directory Access Listing:
drwxrws--- 32 transmgr trangrap      1024  Oct 29 09:11  /trans

Access Allowed for:
pnaranjo wegan ksaunder ebennett jwhisner transmgr kwalsh

Access Denied for:
mgaines rlewis jprather jsmith fstrmbrg awebster

I have NO CLUE !!!
 -------------------------

That's it.   Email or posts to this news group would be appreciated!

TIA  :)

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

From: Paul Greenspan <[e-mail]>
Subject: Re: TLI and non-blocking I/O
Date: 17 Nov 92 14:07:50 GMT
Followup-To: comp.protocols.tcp-ip
To:       [e-mail]

I just wanted to thank all of the people that helped with our problem
with non-blocking I/O, TLI and SVR4.

The problem has been determined to be a bug in SVR4 that shows up
when the same process uses both TCP and UDP and uses non-blocking
endpoints.

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

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

From: Brian Fitzgerald <[e-mail]>
Subject: Re: Thanks,
Date: 17 Nov 92 16:14:11 GMT
Followup-To: poster
Nntp-Posting-Host: mml0.meche.rpi.edu
To:       [e-mail]

Domenico De Vitto writes:
>need not prove it to you lot!
>
>I did think that this group (that I've been reading for 2 years) had settled
>down and didn't have any 'children' actively reading it, I was wrong (sadly).

That's a shame.

Fellow readers, please, no abusive posting or email, ok?

RTFNettiquette :-)

Thanks,

Brian

Followup to email or to comp.unix.wizards

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

From: der Mouse <[e-mail]>
Subject: Re: Thanks,
Date: 18 Nov 92 10:56:10 GMT
To:       [e-mail]

In article <[e-mail]>, [e-mail] (Domenico De Vitto) writes:

> Thanks to all who explained to me what RTFRFC means, most were highly
> abusive and couldn,t F*CKING well see that I'm not 'on' the internet,
> from my address,

I certainly can't.  [e-mail] doesn't tell me whether
you're on the Internet or not.  unix.brighton.ac.uk does not seem to
have an A record, which may or may not mean anything, and most
certainly doesn't mean that *you* don't have Internet access.

                    der Mouse

                [e-mail]

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

From: Tod McQuillin <[e-mail]>
Subject: Re: Changing the owner of a process
Date: 17 Nov 92 18:41:11 GMT
Followup-To: comp.unix.internals
To:       [e-mail]

[e-mail] (Ed Posnak) writes:
> What I was looking for was something along the lines of how to change the
> effective user id of a process who's source I may not be able to modify, by
> some other means, e.g. from another process.  Many suggested writing a device
> driver or system call to do this.  Here is one answer along those lines.
> ---
>
> I believe it could be done by writing a device driver. Open the device
> driver and write commands to it, and it does the dirty work. For
> instance, send it 8 bytes containing the process to change and the uid
> to change it to.
>
> The uid, in every version of Unix I've seen, is stored in the proc
> structure in the kernel. You should be able to fiddle with this at
> will in a device driver, and since it's in the proc structure and not
> the u area, it'll always be there even if the process is swapped out.
> It *should* be just a matter of searching for the entry and changing
> it.

Yeah, but you don't need a device driver to do that.  Just use
/dev/kmem, /vmunix, and nlist(3).

At least for 4.3bsd.

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

From: "E. Tye McQueen" <[e-mail]>
Subject: Programs to create and apply binary patches?
Date: 17 Nov 92 19:48:26 GMT
Followup-To: comp.unix.misc
To:       [e-mail]

[Follow-ups to comp.unix.misc]

Any great ideas on how to create a "patch" file of differences between
two versions of a very large *binary* file (executable) so the patch
file could be distributed (via modem) and applied to the many copies
of the old version of the file?

What I thinking of are two programs:
    A good differences program that is not line-oriented.
    A good batch editor that is not line-oriented.

Several of us here have seen such beasts before but none of us can
find a nice Unix solution.  Any help would be greatly appreciated.

I'm considering converting the binary file to be "line-oriented".  But
it is tricky to put the line breaks so that insertions and deletions of
code do not cause the difference engine to decide the entire remainder
of the files are different.

One scheme is to select a byte value that appears with some fairly
reqular frequency in the executable and transpose that value and
newline.  The hard part is finding an apporpriate value (if one even
exists).

But I suspect that there is Unix-capatible source code for non-line-
oriented differences and batch editing programs if I just knew where
to look.  I tried "archie" but that works best if you already know
the name of what you are looking for.  Checking for things containing
"dif" or "patch" doesn't seem to find anything but differences and
patches of other packages.

Thanks,
 [e-mail]                         Tye McQueen, E.
 ----------------------------------------------------------
 Nothing is obvious unless you are overlooking something.
 ----------------------------------------------------------

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

From: "Suresh .S" <[e-mail]>
Subject: Re: Solaris 2.0/2.1 Realtime programming
Date: 18 Nov 92 19:18:23 GMT
Sender: [e-mail]
Nntp-Posting-Host: thuban.cs.buffalo.edu
X-Newsreader: TIN [version 1.1 PL6]
To:       [e-mail]

Sinan Karasu ([e-mail]) wrote:
: 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:


One indirect way of timing with a fine control  is using select() call
with NULL descriptors set and appropriately setting the struct timeval.


By setting the struct timeval buf you can  get timings of the order of
microseconds !!.

--
Suresh Sivaprakasam
Department of Computer Science,    SUNY Buffalo,    Amherst,   NY - 14260-0001
Internet :[e-mail]               Bitnet : [e-mail]

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

From: "Suresh .S" <[e-mail]>
Subject: Re: system call write
Date: 18 Nov 92 19:34:01 GMT
Sender: [e-mail]
Nntp-Posting-Host: thuban.cs.buffalo.edu
X-Newsreader: TIN [version 1.1 PL6]
To:       [e-mail]

P S Narayan ([e-mail]) wrote:
: When I do a write (fd, buf, bytes), assuming that the file descriptor refers
: to an open block device say disk, is the kernel going to copy buf from user
: space to system buffer or is it going to flush it immediately onto disk ?
: System V literature says that it is copied onto buffer and then by LRU
: algorithm, it gets flushed when another process tries to access this buffer.
: In that case how can the user process without closing the files, ensure that
: his write system call flushes info onto disk ? Is there a way to do it ?
:
: My question is how can I get synchronous write ?

When you are opening the file, you can  set  the  O_SYNC option in the
flags, which will give you synchronous writes. Another way could be to
set the descriptor flags using fcntl()[cmd is F_SETFL].

I am not sure if that  is available in  others OS, it  is available in
SunOS4.1.1.

--
Suresh Sivaprakasam
Department of Computer Science,    SUNY Buffalo,    Amherst,   NY - 14260-0001
Internet :[e-mail]               Bitnet : [e-mail]

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


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