HDTenEightyP/NetNews huggingface dataset:
From: ahn@ac.wfunet.wfu.edu (Dave Ahn)
Newsgroups: comp.unix.shell
Subject: Re: [TCSH] IF's in .login
Date: 24 Aug 92 04:09:09 GMT
Organization: Columbia University Center for Telecommunications Research
X-Posted-From: ac.wfunet.wfu.edu
X-Posted-Through: sol.ctr.columbia.edu

singh@r-node.gts.org (Rajendra Singh) writes:

>I have the following line in my ".login" file, I get the error:  if:
>Expression sytax:

>if (cmp -s filea fileb) then
>   echo "something"
>else
>   echo "something else"
>endif

......
Do you have a "#/bin/sh" in your .login? If not, try putting the code
in .tcshrc or .cshrc. The problem is that your .login is being executed
in /bin/sh. Try replacing "endif" with "fi" to test this theory.
-dka
-- 
Dave Ahn
ahn@wfunet.wfu.edu
Newsgroups: comp.unix.shell
From: singh@r-node.gts.org (Rajendra Singh)
Subject: [TCSH]  IF's in .login
Organization: Public Access UNIX Information System
Date: Sun, 23 Aug 1992 23:40:43 GMT

Hello:

I've noticed something strange, and can't figure out why it happens.  If
I have the following line in my ".login" file, I get the error:  if:
Expression sytax:

if (cmp -s filea fileb) then
   echo "something"
else
   echo "something else"
endif

However, if I have the exact same lines in a separate file it works.  For
example, if I put the above lines in a file called "compare", then in my
".login" I have a line with "compare" on it, then it works fine.  Any
suggestions?

Thanks in advance.
-- 
Raj (singh@r-node.pci.on.ca)
E-Mail:  tcomsing@bluffs.scar.utoronto.ca (University of Toronto)
Newsgroups: comp.unix.shell
From: ash@ulysses.mr.ams.com (Alan Harder)
Subject: Re: Help with directories!
Organization: American Math. Society
	<ASH.92Aug25094554@ulysses.mr.ams.com>
	<1992Aug25.151807.5561@prl.dec.com>
Date: Tue, 25 Aug 1992 17:55:14 GMT

In article <1992Aug25.151807.5561@prl.dec.com> boyd@prl.dec.com (Boyd Roberts) writes:


   >> This seems like a legitimate question for comp.unix.shell.  If the
   >> question bothers you, don't answer it.

   >What bothers me is that _this very thread_ has been done to death
   >over the past few weeks in _this very newsgroup_:

    .
    .  (news headers deleted)
    .

   >If the orignal poster had bother to read the traffic he'd know the answer.
   >Not reading the FAQ is bad, but _ignoring the traffic_ -- give me a break.

But the problem is that a question-poster may not have access to the
old traffic.  On our system, for example, we can only keep two days
worth of news, due to disk space considerations.  We don't all work
for DEC, you know.  Some of us have limits on our resources.  You
didn't even know if the poster had access to that news.  Give HIM a
break.  If you have that thread on disk, send the old posts to him in
email.  That is a helpful thing to do.  Responding with sarcasm isn't.
Xref: sparky comp.unix.shell:3741 comp.unix.questions:10617
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.unix.shell,comp.unix.questions
Subject: Re: Some Unix qs
Date: 1 Sep 1992 20:06:31 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

Please use more descriptive Subject lines.  Nearly everything in
comp.unix.questions is "Some Unix qs", so using that as your subject is not
very useful.  See my revised Subject line for an example.

In article <1992Sep1.145646.1663@cc.gatech.edu> sougata@cc.gatech.edu (Sougata Mukherjea) writes:
>	I have a file say X which contains some records. These records are 
>fixed-format, single line ( each record ends with a NEWLINE character) and the
>record length extends upto 1600 characters.
...
>	The problem I run into while applying the same technique to this
>file X is, that  when I apply the "comm" command to the sorted data files X1 and
>X2, each record breaks up (WHY ??) into multiple records (each of length 256
>characters).

Many Unix programs have arbitrary limits like this.  The particular
behavior of breaking long lines into multiple lines often comes from the
following programming practice:

#define BUFSIZ 256

char line[BUFSIZ];

...

while (1) {
    result = fgets(line, BUFSIZ, stdin);
    if (result == 0) break;
    ...
}

fgets() will read up to BUFSIZ-1 characters, a newline, or EOF, whichever
comes first.  In the case of a line longer than BUFSIZ-1, the next
iteration will begin with the file pointer in the middle of the line.

Be thankful that it simply treats the long line as multiple lines.  Less
careful programs use gets() instead of fgets(), and it doesn't take a
buffer size parameter.  In that case, it will read beyond the end of the
line[] array and overwrite lots of other variables.

>My question is how do I perform the above operations [ (i), (ii) & (iii) ]
>without breaking a record into pieces. The output SHOULD preserve the 
>existing record format ( which "comm" does for small record lengths) and
>SHOULD NOT introduce extraneous characters in the output files. 

If you must use the standard utilities, you're stuck with their arbitrary
limitations.  

Often GNU versions of Unix utilities don't have these limits.  In
particular, they often use the GNU readline() subroutine to read input
instead of fgets().  Readline() allocates the input buffer itself, and
automatically expands it as necessary.  And if the GNU version still
doesn't quite meet your needs you have source so you can fix it if
necessary.

The GNU version of comm(1) is in the textutils package.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.unix.shell,comp.unix.questions
From: shmdgljd@rchland.vnet.ibm.com (Jay Schmidgall)
Subject: Re: Shell Scripts vs. C programs
Date: Tue, 01 Sep 1992 20:03:59 GMT
Reply-To: jay@vnet.ibm.com
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM Rochester, MN
Keywords: shell script, C

In article <1992Sep1.173604.15563@u.washington.edu>, donn@carson.u.washington.edu (Donn Cave) writes:
|> 
|> I have wondered if it would be possible to develop a reasonably usable shell
|> language that would have "software engineering" features for writing large
|> systems.  For me, that would mean some level of typing, structured types,
|> functional scoping, and some way to deal with code in separate modules,
|> but I'm sure there's more to it if one were to consult some standard texts
|> on this issue.  Would be nice to be able to create somewhat complex data
|> types, e.g., trees, and store "pointers" to functions, but not necessarily
|> the way C does it, maybe more like Lisp.  It would of course need to be
|> able to run fairly efficient code.

Take a look at tcl, in particular the shell that's shipped with extended tcl.
Tcl has a lispish/C-ish syntax, is very extendable, structured, &c &c.  I've
seen comparisons between tcl & lisp, tcl & perl, tcl & rexx, etc.

comp.lang.tcl for more info.

-- 
: jay          jay@vnet.ibm.com    My opinions and ideas, not my employer's.
: shmdgljd@rchland.vnet.ibm.com    (c) Copyright 1992.  All rights reserved.
Newsgroups: comp.unix.shell
From: brandy@tramp.Colorado.EDU (BRANDAUER CARL M)
Subject: Re: Wierd vi problem under Dynix/ptx
Organization: University of Colorado, Boulder
Date: Fri, 28 Aug 1992 00:31:52 GMT

Kim Holburn <kim@csc.canberra.edu.au> writes:

>On a sequent running ptx. vi does weird things with @ and #
>and maybe other letters. It treats them like some sort of control characters. 

You got the control character part right - have you tried them while using
the shell?  # is the erase character and @ the kill character from the days
when a TTY37 (hardcopy) was the ne plus ultra of terminals.  Use 'stty' to
make the proper changes and everything will be fine.
Newsgroups: comp.unix.shell
From: micah@hardy.u.washington.edu (Micah Anderson)
Subject: Could someone help me with script?
Summary: what can I do to fix this?
Keywords: script problem
Organization: University of Washington
Date: Thu, 3 Sep 1992 15:11:42 GMT

I run the They Might Be Giants mailing list which has over 260 users on
it, I am trying to make it much easier for me to subscribe and unsubscibe
users, I wrote this script to make the addition of users easier, but it
doesn't always work... comments are in brakets.

#/bin/sh
#new.exe - adds new users to master list and mails them info files
 
#look for duplicates in new list and remove
[what I do is go through all my mail and put all the addresses of people
who want to subscribe into a file called new, I want to check to see that
I don't have the same address in more than once - the problem with this
is if there is no duplicate address and the file new.uniq is empty, it just
sits there... any suggestions?]

sort new > new.sort
uniq -d new.sort > new.uniq
grep -v `cat new.uniq` new.sort > new.tmp
cat new.uniq >> new.tmp
rm new.uniq
rm new.sort
 
#mail info files to new users
mail `cat new.tmp` < Welcome
mail `cat new.tmp` < tmbg.info
 
#add new users to master list
cat new.tmp >> /com/mailer/TMBG/USERS
 
#check for duplicates in master list and remove
[here I am attempting to do the same thing as above, looking for duplicate
addresses, if an address is in more than once they get twice as much mail,
and is a big hassle...]

sort /com/mailer/TMBG/USERS > /com/mailer/TMBG/USERS.sort
uniq -d /com/mailer/TMBG/USERS.sort > /com/mailer/TMBG/USERS.uniq
grep -v `cat /com/mailer/TMBG/USERS.uniq` /com/mailer/TMBG/USERS.sort > USRS.tmp
cat /com/mailer/TMBG/USERS.uniq >> USRS.tmp
mv USRS.tmp /com/mailer/TMBG/USERS
rm /com/mailer/TMBG/USERS.sort
rm USRS.tmp
 
#output info to the log
[here I would like to also output errors (duplicate addresses) into the file
uniq -c will give me a 2 infront of any address that is repeated, BUT if
an address has a 2 in it, I cannot grep for the 2... here to explain a little
better: 
Ok, I am attempting to log when I have duplicates in a file, so I have this:
 
uniq -c new.sort|grep 2 > new.log
 
and I get something like:
 
 more new.log
      2 kavitzp@nickel.brooks.af.mil
      1 xgg2356@dcmdc.dla.mil
 
the first one is fine (as there were two of those and I needed to know that)
but the second one just has a 2 in the address... how can I check just for the
number in the beginning?]

date >> new.log
wc -l new >> new.log
echo ' ' >> new.log
cat new >> new.log
echo '------------------------------'>> new.log
rm new.tmp


any comments or suggestions to make this better are more than appreciated!

Thanks!
From: jerry@incc.com (Jerry Rocteur)
Newsgroups: comp.unix.shell
Subject: Re: file removal problem solved.
Summary: ??????????????????
Date: 2 Sep 92 18:23:24 GMT
Organization: InCC.com Perwez Belgium

In article <1992Sep01.193008.18522@jpradley.jpr.com>, jpr@jpradley.jpr.com (Jean-Pierre Radley) writes:
> In article <114.22393@incc.com> jerry@incc.com (Jerry Rocteur) writes:
> > This is all so tiresome pleaaaaaaase, Eric Liman summed it all up in
> > a post on Aug 27th, this should be posted on a daily basis, that way
> > we would not have to repeatedly read these stupid questions and often
> > answers, here is Eric's post, read it, print it and paste it on the
> > wall, please..........
> 
> _You_ are being tiresome, Jerry, by reposting all that stuff, and
> consuming net-bandwidth, especially considering that you have very bad
> standing to do so in view of your raging about Uwe in another newsgroup,
> and your persistence in sticking to an overly long signature block.
> 
> The correct observation is that the problem of removing files with funny
> names is dealt with in the FAQ posting.
> 
> -- 
> Jean-Pierre Radley   Unix in NYC   jpr@jpr.com   jpradley!jpr   CIS: 72160,1341

1) who rattled your s*it can and asked for your opinion ?

2) since when are you the moderator of free speech ?

3) why don't you let people get on with comp.unix.shell??
-- 
 __^__                                                              __^__
( ___ )------------------------------------------------------------( ___ )
 | / | Jerry Rocteur                       Email: jerry@InCC.COM    | \ |
 |___|             Independent Computer Consultants                 |___|
(_____)------------------------------------------------------------(_____)
   ^                                                                  ^
Newsgroups: comp.unix.shell
From: john@physiol.su.OZ.AU (John Mackin)
Subject: Re: How to empty a file
Organization: Department of Physiology, University of Sydney, Australia
Date: Thu, 27 Aug 1992 09:08:06 GMT

In article <1992Aug26.172228*Harald.Eikrem@delab.sintef.no>,
	Harald.Eikrem@delab.sintef.no writes:

> This is definitely a FAQ.  My favourite file making/nulling command is:
>
>  : > file
>
> which should work from any kind of shell (in csh "noclobber" must be
> neutralised).

Wrong again.  Nothing says this "should work from any kind of shell".
It will work from any kind of shell that has : as a functional comment
character (or, if you want to look at it that way, as a builtin
command that ignores its arguments and doesn't do anything).  Not all
shells have that.  One example of a shell that doesn't is rc.  (I
happen to define : as a null function in _my_ rc environment because
I like to be able to mouse and resend lines even if I have something
in the prompt... but that doesn't alter the fact that rc doesn't
normally use : this way.)

If you really want something that "should work from any kind of
shell", and you aren't happy with "cat /dev/null >target", then
use

	sh -c '> target'

All that depends on is that you have sh, and that single quotes
work as expected in the shell in use.

As for someone's suggestion of "echo > target", I have to point
out that many, indeed today probably most, versions of echo _do_
print a newline when given no arguments.

-- 
John Mackin <john@civil.su.oz.au>
`You ate WHAT?'
Newsgroups: comp.unix.shell,comp.unix.questions,netcom.general
From: westes@netcom.com (Will Estes)
Subject: Need Script To Kill Process Using Substring Of Application Name
Date: Sun, 30 Aug 92 23:07:51 GMT
Organization: Mail Group

Does anyone have a script that they could send to me that will take as
its input some substring and then kill any process you own that has that
substring in its application name?  So the script would do something
like:

	ps guaxww | grep "some_substring"

then it would exclude the line that contained the grep command, locate
the PID of the remaining processes, and kill each one.  Please post the
script for others to see if its short enough.

Thanks,
Will Estes		Internet: westes@netcom.com
Newsgroups: comp.unix.shell
From: rahner@iscnvx.lmsc.lockheed.com (Mark Rahner)
Subject: Re: file removal problem solved.
Organization: Lockheed Missiles and Space Co.
X-Newsreader: Tin 1.1 PL4
Date: Thu, 3 Sep 92 19:11:48 GMT


jpr@jpradley.jpr.com (Jean-Pierre Radley) writes:
: 
: The correct observation is that the problem of removing files with funny
: names is dealt with in the FAQ posting.

Couldn't have said it better myself.


jerry@incc.com (Jerry Rocteur) writes:
: 
: 1) who rattled your s*it can and asked for your opinion ?
: 
: 2) since when are you the moderator of free speech ?

Don't you see the blatant logical inconsistency in these two questions?
Or are you just worried that someone else might be after your job as
moderator of free speech?

-- 
Mark V. Rahner   rahner@lmsc.lockheed.com
From: hurtta@cs.Helsinki.FI (Kari E. Hurtta)
Newsgroups: comp.unix.shell
Subject: Re: alias problems
Date: 30 Aug 92 20:09:57 GMT
Organization: Department of Computer Science, University of Helsinki, Finland

In article <1992Aug29.140835.15176@sfera.kharkov.ua> mickey@sfera.kharkov.ua (Mickey Serg Antonoff) wrote:
>   there is a little problem to write alias in such way:
> 
> alias md "sh -c 'for f in \!*;do mkdir $f ; cd $f;done'"
            ---                               -----
>   it have to do:
> 	make directory, than cd to it;
>   call:
> 	cd ~
> 	md 1 2 3 4 5 6
>   result:
> 	cwd = ~/1/2/3/4/5/6

First:

You create new process (sh) what executes this cd -command.
No way. Parent (curretn shell) and that new process have
OWN current working directory! CHILD's environment don't
affect to parent !!!


- K E H
( Kari.Hurtta@Hurtta.FI,
  hurtta@cc.Helsinki.FI,
  hurtta@cs.helsinki.FI,
  HURTTA@FINUH.BITNET
)
Newsgroups: comp.unix.shell
From: gilmore@venice.sedd.trw.com (Larry Gilmore)
Subject: Re: How to empty a file
Organization: TRW Systems Engineering & Development Division, Carson, CA
Date: Wed, 2 Sep 1992 00:36:09 GMT

In article <1992Sep1.190410.17063@prism.poly.edu> kapela@prism.poly.edu (Theodore S. Kapela) writes:
>In article <ahn.714982174@ac> ahn@ac.wfunet.wfu.edu (Dave Ahn) writes:
>>
>>Try 'touch logfile'
>
>This will only leave an empty file if the file does not exist.  If the file
>exists, it will only change the access and modification times.
>
>
>-- 
>..............................................................................
> Theodore S. Kapela				kapela@poly.edu
> Center for Applied Large-Scale Computing	
> Polytechnic University

When I had to ensure a zero-length file, I used:

cat /dev/null > foofile


-- 
Larry A. Gilmore             Internet: gilmore@venice.sedd.trw.com
TRW SEDD, DH1/2849
P.O. Box 6213                Phone:    (310)764-3318
Carson, CA 90746             Fax:      (310)764-3946
Newsgroups: comp.unix.shell
From: casper@fwi.uva.nl (Casper H.S. Dik)
Subject: Re: tcsh completion bug on Silicon Graphics
Organization: FWI, University of Amsterdam
Date: Fri, 4 Sep 1992 13:09:16 GMT

posse@masg6.epfl.ch (Christian Posse) writes:



>TCSH COMPLETION BUG AND STRANGE WARNING MESSAGE WITH FLAG __STDC__
>------------------------------------------------------------------

>Hi tcsh gurus,

>I have implemented the 6.02 version of tcsh on our SGIs (INDIGO and
>4D35 running IRIX 4.0.3 or 4.0.4).

>I have found the following bug concerning the selective completion.

>> complete xdvi 'n/*/f:*.dvi/'
>> xdvi [TAB] 
>gives all files ending with .dvi BUT also all sub-directories! In fact the
>parameter f for files in the complete definition does not work in the
>sense that directories appear when the f parameter is used for defining
>selective completion.

>Has anyone encountered the same problem ? And how to correct this feature ?

It is a feature, I would say. The sub directories can also contain .dvi
files and can be part of valid .dvi completion. I use that feature a lot.

Casper
-- 
						|	Casper H.S. Dik
						|	casper@fwi.uva.nl
Newsgroups: comp.unix.shell
From: sandman@cray.csc.ncsu.edu (Mr Sandman)
Subject: Re: Help with directories!
Followup-To: /dev/null
X-Disclaimer: This message was written by a user at North Carolina
              State University. The opinions expressed are those of
              the user and not necessarily those of NCSU.
Reply-To: sandman@cray.csc.ncsu.edu (Mr Sandman)
Organization: North Carolina State University
Date: Tue, 25 Aug 1992 23:54:02 GMT


boyd@prl.dec.com (Boyd Roberts) writes:

: In article <1992Aug24.175614.15627@netnews.synoptics.com>,
ericd@synoptics.com
: (Eric Davis) writes:
: > I am looking for a sh routine to return a numerical value for a
: file/directory.
: > i.e. the files permissions are -rwxr-xr-x it would return a 755.
: > 
: 
: So for just how many minutes have you been reading this group for?

Your words are bitter; your tone, spiteful.

Newer users are obviously going to have questions which seem simple
to us.  Rather than answer a perfectly legitimate question with a flame, 
please just don't answer at all in the future.  There is *NO*
justification for doing so.

If you don't like a post then skip it.

: Boyd Roberts			boyd@prl.dec.com
: 
: ``When the going gets wierd, the weird turn pro...''
                        ^^^^^      ^^^^^
What the hell, you can't even spell ``weird'' consistently!  Sheesh!

--
sandman@cray.csc.ncsu.edu		north carolina state university
Newsgroups: comp.unix.shell
From: lwv26@cas.org (Larry W. Virden)
Subject: ksh: how to properly parse through arguments?
Followup-To: comp.unix.shell
Reply-To: lvirden@cas.org (Larry W. Virden)
Organization: Nedriv Software and Shoe Shiners, Uninc.
Date: Tue, 1 Sep 1992 19:36:05 GMT


Okay.  I have some code which has to read thru its arguments.  These arguments
may have quotes, definitely have spaces, etc.

I have to look thru them, acting on certain flags and then pass the rest
off to another program.

I have code like:


arg=""
while [ "$#" -gt 0 ] ; do
	case "$1" in

		-Q )
			echo "time to go fishing"
			shift
			;;
		-X )
			echo "Who knows?"
			shift
			;;

		* )
			arg="$arg $1"
			shift
			;;
	esac
done

other_cmd $arg
exit

The problem is that last line.  If I use that, then arguments which have
embedded blanks turn into separate words - not good.

If I make the line:

other_cmd "$arg"

then all the flags become one argument - not good.

If I try to put quotes around the arg="$arg \"$1\"" they seem to disappear
before other_cmd get the arguments.

What trick do I need here?
-- 
Larry W. Virden                 UUCP: osu-cis!chemabs!lvirden
Same Mbox: BITNET: lvirden@cas  INET: lvirden@cas.org
Personal: 674 Falls Place,   Reynoldsburg, OH 43068-1614
America Online: lvirden@aol.com
Newsgroups: comp.unix.shell
From: Harald.Eikrem@delab.sintef.no
Subject: Re: How to detect login shell in .cshrc ?
Organization: SINTEF DELAB, Trondheim, Norway.
Date: 25 Aug 92 23:54:52

! Is there a clean way in your .cshrc to determine whether it is
! being executed by the login shell?  I have some commands that I 
! want to execute only if this is *not* the login shell.
! 
! The best I could come up with is to run "ps" and count the number
! of lines it outputs after maybe grepping them for "csh".  Really ugly.

And the ugly answer is:  no.

In tcsh one might test $shlvl for value 1, but that will not always guarantee
that it is a login shell.

  ~~harald E.
Newsgroups: comp.unix.shell,comp.unix.questions
From: navarra@casbah.acns.nwu.edu (John Navarra)
Subject: Re: Shell Scripts vs. C programs
Keywords: shell script, C
Organization: Northwestern University, Evanston Illinois.
Date: Tue, 1 Sep 1992 08:54:12 GMT

In article <1992Sep01.062906.8332@tjhsst.vak12ed.edu> nurban@tjhsst.vak12ed.edu (Nathan Urban) writes:
>It seems to me that most tasks that you would write a shell script for
>could be implemented in very portable C without worrying too much about
>OS quirks if one so desired.
>
>
	And vice versa. But which is easier to write? And, suppose you
had to add capabilities to your program which DID involve 'OS quirks'.
Would you rather be responsible for making sure your C program compiled
on all machines or would you rather just update your shell script? In
general, shell scripts are much easier to write and maintain. Unless
there is some profuse lack of speed, shell scripts are very very useful.
But then again, there is always the perl alternative....

-tms


-- 
You can get further with a kind word | You can get further with a kind word
and a gun than a kind word alone.    | and a phaser than a kind word and a gun.
          --al capone                |           -- John Navarra
=======From the Lab of the MaD ScIenTIst....navarra@casbah.acns.nwu.edu========
From: tchrist@convex.COM (Tom Christiansen)
Newsgroups: comp.unix.shell
Subject: Re: Help with directories!
Date: 25 Aug 92 17:28:21 GMT
Reply-To: tchrist@convex.COM (Tom Christiansen)
Organization: Convex Computer Corporation, Colorado Springs, CO
Originator: tchrist@pixel.convex.com
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

From the keyboard of ash@ulysses.mr.ams.com (Alan Harder):
:I never said I had a solution to wasted bytes.  I just don't think
:that flaming is a good answer, especially if the question isn't in the FAQ.  

:Do you think he really
:deserved the flame?  


I believe my quote, somewhat milder than Boyd's which still didn't
seem particularly out of line, was 

    But we just discussed this 5 days ago!
    
If you consider this a flame, then we certainly have different 
standards for what constitutes such.

--tom
-- 
    Tom Christiansen      tchrist@convex.com      convex!tchrist

One good reason why computers can do more work than people is that they
never have to stop and answer the phone.
Newsgroups: comp.unix.shell