HDTenEightyP/NetNews huggingface dataset:
From: paul@prcrs.prc.com (Paul Hite)
Newsgroups: comp.unix.wizards
Subject: Re: Detecting if running under chroot
Date: 11 Nov 92 16:11:41 GMT
Organization: PRC Realty Systems, McLean, VA

In article <mark.721121538@coombs>, mark@coombs.anu.edu.au (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?

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.

Paul Hite   PRC Realty Systems  McLean,Va   paul@prcrs.prc.com    (703) 556-2243
    "We are trying to bring up an Air Traffic Control display on an X window 
      terminal and there seems to be some problems." -- from comp.windows.x
Newsgroups: comp.unix.wizards
From: howard@saathi.ncst.ernet.in (Howard D'Souza)
Subject: Re: Keyboard hit in C programs
Keywords: Keyboard hit, C programs, UNIX
Organization: National Centre for Software Technology, Bombay, India.
Date: Thu, 12 Nov 1992 11:34:31 GMT

In article <1992Nov10.155417@rbg.informatik.th-darmstadt.de> misar@rbg.informatik.th-darmstadt.de (walter misar) writes:
>In article <1dms9iINNa6m@agate.berkeley.edu>, 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, bernt@valois.berkeley.edu 
>>
>
>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: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: SUN NFS sync
Date: 5 Nov 92 23:24:13 GMT
Organization: Auspex Systems, Santa Clara

> (Note: I don't believe that [async writers on the server] is the default
> on any of these servers.  In any case, it *clearly* violates the NFS spec.)

Actually, I think it *is* the default on SGI servers.  (It's not the
default on Auspex servers.)  I think HP also offers an "async" option;
dunno if it's the default.
From: bmu@sbfdk.sbf.dk (Boerge Mueller)
Newsgroups: comp.unix.wizards
Subject: ksh argument interpreter
Keywords: ksh arguments
Date: 11 Nov 92 08:30:41 GMT
Organization: Great Belt ltd. Denmark

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  : +45 3393 5200 x 222       | I don't know what the          |
From: sanjay@berkeley.Berkeley.EDU (Sanjay Shrivastava)
Newsgroups: comp.unix.wizards
Subject: applications using p-threads!!
Date: 10 Nov 92 23:56:29 GMT
Reply-To: sanjay@berkeley.Berkeley.EDU (Sanjay Shrivastava)

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.
Xref: sparky comp.unix.wizards:4643 comp.unix.shell:4666 comp.unix.misc:4131
From: kanderso@reed.edu (Karl Anderson)
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
Subject: Re: The Problem with UNIX
Date: 12 Nov 92 20:47:10 GMT
Article-I.D.: reed.1992Nov12.204710.5808
Organization: Reed College, Portland, OR

In article <1992Nov11.194557.16258@yarc.uucp> scott@yarc.UUCP (Scott Beckstead) writes:
>
>  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

Is there any reason why there can't be another stream for more
user-friendly messages?  We have stdin and stderr, why can't there be
a standard verbose stream as well?  Experienced users could just
direct it to /dev/null , or, to save cpu time, could have a flag that
would disable it altogether.

k

>Reply to: scott@yarc.uucp 	|  
Newsgroups: comp.unix.wizards
From: bmk@box.ssd.loral.com (Bruce Krawetz)
Subject: RPCGEN
Organization: Space Systems/Loral, Palo Alto, CA  USA
Date: Mon, 9 Nov 1992 21:09:17 GMT

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?)

---
bmk@box.ssd.loral.com
We must learn from our mistakes, so that we may make bigger and better ones.
Newsgroups: comp.unix.wizards
From: dwex@cbnewsj.cb.att.com (david.e.wexelblat)
Subject: Re: The Problem with UNIX
Organization: AT&T
Date: Fri, 13 Nov 1992 17:48:47 GMT

In article <1992Nov12.231845.14014@cs.wisc.edu> so@brownie.cs.wisc.edu (Bryan S. So) writes:
> Concerning "cat a b > b", barnett@crdgw1.ge.com writes:
>  
> >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 <barnett@crd.ge.com> uunet!crdgw1!barnett
> 
> No, the above are not solutions.  
> 
> 1. We should assume some stubborn users cannot be educated.  I
>    claim without proof such users exist.
> 
> 2. set noclobber is not a solution because a solution should
>    prepend a to b.  
> 
> I propose a real solution to this problem.  Change the internal
> policy of UNIX, so that when any file is used as both input and
> output, like
> 
> 	cat a b > a
> or 	cat a b > b
> 
> UNIX should read and buffer all input before opening the output
> with "w".
> 
> 
> Bryan

Get real.  In your example, replace /bin/cat with /bin/echo:

	/bin/echo a b > b

What should "unix" do here?  You are confusing the OS, the shell, and
the program.  The various responsibilities are distributed.  Cripe - 
MS-DOG has redirection, and will do the same screwup for commands that
are not built into COMMAND.COM.  I doubt that JCL protects you either.

Or would you rather have no I/O redirection, and force all the programs
to do all the I/O themselves?  How would you handle pipelines?

As soon as you try to protect users from themselves, you destroy
the usefulness of the system.  Who ever said that Unix is supposed to
be the "One True OS" (other than USL :->)?  Don't destroy the usefulness
of my OS because people who shouldn't be using it are involved.

--
David Wexelblat <dwex@mtgzfs3.att.com>  (908) 957-5871
AT&T Bell Laboratories, 200 Laurel Ave - 4B-421, Middletown, NJ  07748

"The meaning of life?  That's simple.  Try to be happy, try not to hurt
 other people, and hope to fall in love."  -- Mallory Keaton
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
From: michael@chpc.utexas.edu (Michael Lemke)
Subject: Re: The Problem with UNIX
Organization: The University of Texas System - CHPC
Date: Fri, 13 Nov 92 21:31:07 GMT

In article <1992Nov13.094336.2341@aber.ac.uk> btk@aber.ac.uk (Ben Ketteridge) writes:
>From what you say about each of Bryan So cases of command-line problems, I take
>it to mean that you think that it is _entirely_ the users' responsibility to
>check that they don't type incorrect commands?
>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.  

-- 
Michael Lemke
Astronomy, UT Austin, Texas
(michael@io.as.utexas.edu or UTSPAN::UTADNX::IO::MICHAEL [SPAN])
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
From: eeide%asylum.cs.utah.edu@cs.utah.edu (Eric Eide)
Subject: Re: The Problem with UNIX
In-reply-to: jbotz@mtholyoke.edu's message of Fri, 13 Nov 1992 15:10:25 GMT
Organization: University of Utah Department of Computer Science
	<1992Nov11.194557.16258@yarc.uucp>
	<EEIDE.92Nov12120339@asylum.cs.utah.edu> <Bxnu5E.KoH@mtholyoke.edu>
Date: 13 Nov 92 14:32:14

I wrote:

Eric> I know of somebody who is doing research in this direction: me.  As part
Eric> of my Masters degree I am modifying the C shell to be more tolerant of
Eric> errors, both errors in syntax (e.g., typos) and semantics (e.g.,
Eric> inappropriate command line arguments).  My new shell keeps track of the
Eric> user's command history in order to make accurate corrections.

And Jurgen Botz (jbotz@mtholyoke.edu) wrote:

Jurgen> Without wanting to make a judgement about the viability of the basic
Jurgen> research underlying such a project, why are you starting with the C
Jurgen> shell?  If I wanted to create a user-interface that could deal with
Jurgen> errors and ambiguities introduced by the user I would first make sure
Jurgen> that the software itself isn't full of errors and ambiguities... i.e.,
Jurgen> I sure as hell wouldn't use the C shell.

Good point.  The reason that I chose the C shell is that within the Univeristy
of Utah's Department of CS, it is the most commonly interactively-used program
with a command-line interface.  This makes it easy to find lab rats... er,
guinea pigs... um, volunteers to test my improved interface.  And since the C
shell is so commonly used, it seemed that improvements to the C shell would be
most valuable.  That is, a "smart shell" would be more valuable than a "smart
ftp."

In many ways the C shell is a bad candidate for smarts.  Most of the shell's
"command set" is implemented by programs that have no real connection to the
shell.  This "command set" is inconsistent (e.g., different programs accept
different argument syntax).  And the shell itself has bugs and ambiguities.
But on the other hand, of all the programs available in UNIX, the C shell is
arguably the program in which intelligence would be most useful.

So I made my choice based on the potential value of the improvements.

--
-------------------------------------------------------------------------------
Eric Eide          |          University of Utah Department of Computer Science
eeide@cs.utah.edu  | Buddhist to hot dog vendor: "Make me one with everything."
Newsgroups: comp.unix.wizards
From: tannerrj@cnsvax.uwec.edu (Power = 486 + HST Dual Standard)
Subject: libg++2.2
Organization: University of Wisconsin Eau Claire - Power Users
Date: Wed, 11 Nov 1992 09:42:00 GMT
News-Software: VAX/VMS VNEWS 1.41    
X-Posted-From: cnsvax.uwec.edu
NNTP-Posting-Host: sol.ctr.columbia.edu

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.

Newsgroups: comp.unix.wizards
From: guenther@stolaf.edu (Philip Guenther)
Subject: Re: How to 'purge' a process?
Organization: Academic Computing Center, St. Olaf College
Date: 5 Nov 92 18:55:05

In article <TPAQUETTE.92Nov4092758@gumby.ita.lgc.com> tpaquette@ita.lgc.com (Trevor Paquette) writes:
    Ok here is one for all the wizards out there...

     I want to tell unix to kill/purge/delete/remove/maim a process id.
    I don't care what it is doing, or what it is waiting for. All I know
    is that I want it gone. 

      This must also work for zombied processes, and processes that are waiting
    for io (read: nfs timeouts, hardware timeouts etc..)

In all versions of un*x I know, this is impossible.  The zombie part
always is, as are any other times when the process is in the kernel on
a non-interruptible system call.  Note that a zombie process can be
thought of as a process in the kernel for the system call _exit, and
_exit is not an interruptible sys call.  If your nfs filesystem's are
not mounted intr then they can't be interrupted and if mounted hard
they'll sit there retrying forever.  I am *not* recommending mounting
everything soft,intr.  You want to mount root and swap (at least) and
other vital fs's hard and non-intr to prevent bad things.

     This started when we tried to kill a process waiting on a hung plotter.
    We could not kill -9 the process, it was still there. Is there a way to
    tell unix to remove a process no matter what?

No, there isn't.  Rest assured that the process will barely (or
possibly not at all) make it out of the kernel before your SIGKILL
will take effect.  Since it is just waiting inside the kernel and not
really doing any 'real' work,  you shouldn't worry excessively.  Just
fix the printer.

  Whoops!  There *is* a way to kill any process.  Reboot. :-)

Philip Guenther
--
guenther@stolaf.edu (Philip Guenther)       | The ACC might agree with me,
Student Sys Prog, Academic Computing Center | but with that bunch, (and me)
St Olaf College, Northfield, MN 55057-1001  | you never know... :-) :-| :-(
"Life makes sense?  LIFE MAKES SENSE!!?  Where do people get these ideas?"-me
Xref: sparky comp.unix.wizards:4545 comp.sys.sun.admin:7984 comp.unix.questions:12943
From: eposnak@dale.ksc.nasa.gov (Ed Posnak)
Newsgroups: comp.unix.wizards,comp.sys.sun.admin,comp.unix.questions
Subject: Re: Changing the owner of a process
Keywords: process owner
Date: 5 Nov 92 15:28:33 GMT
Article-I.D.: dale.1992Nov5.152833.27744
Organization: NASA

Is there an un-general way of changing the euid of a process from another 
process?  We have an unusal requirement on our project for a 'shift-change'
where a user logs in and 'inherits' ownership processes that were running under another euid.  Thanks in advance.
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
From: jbotz@mtholyoke.edu (Jurgen Botz)
Subject: Re: The Problem with UNIX
Organization: Mount Holyoke College
Date: Tue, 10 Nov 1992 21:49:55 GMT

In article <aldavi01.721333614@starbase.spd.louisville.edu> Arlie Davis <aldavi01@starbase.spd.louisville.edu> 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: JBotz@mtholyoke.edu
Academic Systems Consultant  |     Bitnet: JBotz@mhc.bitnet
Mount Holyoke College        |      Voice: (US) 413-538-2375 (daytime)
South Hadley, MA, USA        | Snail Mail: J. Botz, 01075-0629
From: clausb@hpbeo20.bbn.hp.com (Claus Brod)
Date: Wed, 11 Nov 1992 09:59:37 GMT
Subject: Re: The Problem with UNIX
Organization: HP Mechanical Design Division R&D, Boeblingen, Germany
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
X-Newsreader: TIN [version 1.1.4 PL6]

Rich Kulawiec (rsk@gynko.circ.upenn.edu) wrote:
: I'd suggest Rob Pike's 'cat -v considered harmful' as an excellent
: starting point.

Where can I find this document?

Tnx,

	Claus

-- 
--clausb@hpbeo79.bbn.hp.com----------------------------------------------
Claus Brod, MDD, HP Boeblingen   	Things. Take. Time. (Piet Hein)
--#include <std_disclaimer>----------------------------------------------
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
From: les@chinet.chi.il.us (Leslie Mikesell)
Subject: Re: The Problem with UNIX
Organization: Chinet - Public Access UNIX
Date: Wed, 11 Nov 1992 21:26:12 GMT

In article <id.NEVU.Z2J@ferranti.com> peter@ferranti.com (peter da silva) writes:
>>     Sending binary file should be uuencoded first.
>
>Nope. It should say "mail: Standard input contains NULL characters." And
>abort.

I disagree on this one.  It should just work unless you are of the opinion
that computers should not handle arbitrary binary data.  SysVr4 gets
this one right by checking the content before trying to display it but
not before delivering it to the right place.

Les Mikesell
  les@chinet.chi.il.us
Newsgroups: comp.unix.wizards
Subject: Re: Subscribe o.k.- unsubscribe ???
From: marcello@deis20.cineca.it (Marcello Dalpasso)
Date: 5 Nov 92 13:52:31 +0100
Distribution: world
Organization: Dept. of Electronics, Computer Science & Systems, Univ. of Bologna, Italy

Many others!!! :-(

-- 
	Marcello Dalpasso (e-mail: marcello@deis16.cineca.it)
	D.E.I.S. - Department of Electronics, Computer Science and Systems
	Viale Risorgimento 2, I-40136 Bologna, Italy			
	Phone: +39-51-644-3015 (fax: +39-51-644-3073)
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
From: boyd@prl.dec.com (Boyd Roberts)
Subject: Re: The Problem with UNIX
Organization: Digital Equipment Corporation - Paris Research Laboratory
Date: Mon, 9 Nov 1992 21:57:34 GMT

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

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


Boyd Roberts			boyd@prl.dec.com

``When the going gets wierd, the weird turn pro...''
Xref: sparky comp.unix.wizards:4578 comp.unix.shell:4611 comp.unix.misc:4074
From: dave@cs.arizona.edu (Dave Schaumann)
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
Subject: Re: The Problem with UNIX
Date: 9 Nov 92 21:53:07 GMT
Reply-To: dave@cs.arizona.edu (Dave Schaumann)
Followup-To: comp.unix.wizards
Organization: University of Arizona

In article <1992Nov9.172715.16367@cs.wisc.edu>, 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?
Xref: sparky comp.unix.wizards:4597 comp.unix.shell:4632 comp.unix.misc:4094