HDTenEightyP/NetNews huggingface dataset:
From: Tom Christiansen <tchrist@convex.COM>
Subject: Re: file name completion for ksh?
Originator: tchrist@pixel.convex.com
Reply-To: tchrist@convex.COM (Tom Christiansen)
Organization: CONVEX Realtime Development, Colorado Springs, CO
Distribution: na
Date: Thu, 23 Jul 1992 03:36:02 GMT
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 sjs@netcom.com (Stephen Schow):
:The ksh is hands down the best.  As the last response showed, there is usually
:a way to do it in the ksh.  In addition, the ksh has tons of over features
:that none of the other shells can even touch.  

Down boy.  That's overkill.  Read the tcsh man page some day.

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


Any opinions expressed are my own, and generally unpopular with others.
From: milanj@sematech.org (Jon Milan)
Subject: Re: Where does the sugar go? (was Re: Sort problem )
Organization: SEMATECH Manufacturing Systems Development
Date: Fri, 31 Jul 1992 17:33:53 GMT

In article <84902@netnews.upenn.edu> chip@eniac.seas.upenn.edu (Charles H. Buchholtz) writes:
>tchrist@convex.COM (Tom Christiansen) writes:
>>
>>Expected output should go out to stdout.  Exceptional output related
>>to diagnostics or other error messages should go out stderr.  
>
>I agree, but I often wonder what to do with the output "sugar", such
>as prompts or headers, which are not well suited for filtering.  It's
>nice when someone is looking at the output, but takes extra effort to
>remove when piped into a filter, eg
>
>	finger | tail +2l | [...]
>	ps | (read header; echo "$header"; [...])
>
>So, folks, what's the verdict?  Output goes to stdout, preferably
>arranged in lines and fields for easy filtering.  Error messages and
>diagnostics (abnormal stuff) goes to stderr.  Where should the sugar
>go?  stdout?  /dev/tty?  /dev/null?  >&3?


It can go to stdout as long as there's a command line option to shut it off
for filtering.  Or preferably, an option to turn the "sugar" ON if someone
wants it.

What eats me is when there's NO such option (so I have to hack around the noise),
then a new version of software comes along that breaks code cause the _noise_ changed!
I, for one, don't care to rewrite code for _that_ reason.

Unfortunately, UNIX is too flexible!  It'll let any programmer do just about
whatever they please!  And it also lets me rewrite stuff if I don't like it!  :-)

-- 
Jon Milan         jon_milan@sematech.org      |
SEMATECH Manufacturing Systems Development    |
"is was as was was when was was as is" (pmk)  |
= = = = = = = = = = = = = = = = = = = = = = = =
Xref: sparky comp.unix.shell:3115 comp.unix.programmer:3887
From: boyd@prl.dec.com (Boyd Roberts)
Subject: Re: sh equivalent of csh's `source` wanted
Keywords: help
Organization: Digital Equipment Corporation - Paris Research Laboratory
Date: Fri, 31 Jul 1992 08:29:29 GMT

.

RTFM


Boyd Roberts			boyd@prl.dec.com

``When the going gets wierd, the weird turn pro...''
Newsgroups: comp.unix.shell
From: Harald.Eikrem@delab.sintef.no
Subject: Re: script to center text
Followup-To: comp.unix.shell
Organization: SINTEF DELAB, Trondheim, Norway.
	<1992Jul28.151623.12798@news.eng.convex.com>
Date: 28 Jul 92 23:36:33

This is a possible sed centering solution, but them y'know, I'm a sed
loonie.....
Note that the very first substitution trades any tabs for 4 spaces,
because there wont be a single *correct* way to interpret a tab after
the centering operation has taken place....

===================
#!/bin/sh

sed '
	s/	/    /g
	s/^  *//
	s/  *$//
	: fill
	/.............................................................................../!s/.*/ & /
	t fill
' $@
===================

  ~~harald E.
Newsgroups: comp.unix.shell
From: jimh@pacdata.uucp (Jim Harkins)
Subject: tcsh - too many features?
Organization: Pacific Data Products
Date: Thu, 30 Jul 1992 21:00:45 GMT

Never saw the original article but this has been quoted several times.

! If both these questions have solutions already it only shows that tcsh 
! has too many features.  I can't remember them so I don't use them.

'scuse me?  I've probably forgotten more about the shell than I know.  Hell,
I don't even remember what that little knob on the side of my toaster is for.
I like my toast the way it comes out so why mess with it, although I'm sure
some pop-tart junkie is really happy the knob is there.

Having lots of features is what I consider a 'rich' environment.  This is
opposed to a 'gui' environment, of which it's been said 'Gui's make simple
things easier, and hard things impossible.'  If you're any good at all then
someday you'll be glad some nameless soul added that obscure feature to
tcsh.  And if you're smart you'll put that obscure feature into your .login
or .cshrc so you don't have to re-learn it.

Excuse the Gui slam but a few months ago I spent a week on a Mac.  It would
have been a day had anybody known how to get straight to the hardware a-la
Dos's mode command or the SunOS /etc/remote file.  What I needed was
non-standard, thus Apple decided I didn't need to do it.  I've also had bad
experiences with CASE tools, where the vendor got so wrapped up in his mouse
he forgot that all I wanted to do was get my job done.

Excuse the Mac slam, but that wasn't a pleasant experience :-(

If you think tcsh has too many features then forget about ever learning perl.

jim

-- 
Lawyers Creed:  What's mine is mine, what's yours is negotiable.
--------------------------------------------------------------
Jim Harkins                         [ucsd|uunet]!pacdata!jim
Pacific Data Products               jim@pacdata.com
--------------------------------------------------------------

Newsgroups: comp.unix.shell
From: yeates@rtsg.mot.com (Tony J Yeates)
Subject: zsh was Re: tcsh in the future - what should it be like?
Organization: Motorola Inc., Cellular Infrastructure Group
Distribution: comp.unix.shell
Date: Thu, 23 Jul 1992 18:53:24 GMT

cedman@714-725-3165.nts.uci.edu (Carl Edman) writes:

>Tom Christiansen writes
>> From the keyboard of barr@darwin.psu.edu (David Barr):
>> 
>> There are so so many limitations.  I just don't think it
>> feasible to try to take care of all of them.  

>And most of all why would anyone bother ? To see how much effort, talent and  
>good ideas have gone into tcsh is almost heart-rending. I've previously  
>publicly asked for any good reason to continue to use csh descended shells  
>instead of eg. zsh and been met only with resounding silence.

>	Carl Edman

tcsh has an excellent use interface (i.e. command line editing),
incorporating the best features of ksh, csh and 4DOS IMHO. Its
also backward compatible with tcsh (a painless transition).

I've never used zsh, and haven't heard any rave-reviews ...
is this something special or just another free shell?
Whats the associated programming language like?  (If
its not Bourne Shell, ksh, REXX, perl or csh compatible - forget
it, there are too many shell language alternatives already!)
Newsgroups: comp.unix.shell
Subject: process substitution in zsh
Supersedes: <92207.163611BRL102@psuvm.psu.edu>
Organization: Penn State University
Date: Sat, 25 Jul 1992 23:18:52 EDT
From: <BRL102@psuvm.psu.edu>
Followup-To: poster

I've recently begun exploring zsh, and am having trouble with process substi-
tution.  Consider the following minimalist example:

   echo foo > >(cat)

Near as I can tell, this should write "foo" to echo's stdout, which will be
redirected into a named pipe.  Stdin for cat will also be redirected from that
named pipe, so it should copy "foo" to its stout.  Since cat's stdout is not
redirected, "foo" should be printed on the terminal.  Instead, "zsh: write
error: broken pipe" results.

A few possibly related examples:

   cat > >(cat)         reads a single line from the terminal but does not echo
   cat < <(cat)         terminates immediately without reading from terminal

I thought, from the documentation, that both of these should perform just like
a single "cat", with a bit of variety as to which "cat" is reading from where.
Who is confused:  me, zsh, or my Unix box?  Pertinent data:  I am version 1.0,
zsh is version 2.2.0, and my box is running SunOS 4.1.1.

Any clues?  I'm directing all followups to me directly, as me UseNet access is
a bit sporadic these days.  I promise to post a summary of all replies.


Ben Liblit   -----   "Fais que tes reves soient plus longs que la nuit."
liblit@cs.psu.edu   --   brl102@psuvm.psu.edu   --   brl102@psuvm.bitnet
Newsgroups: comp.unix.shell
From: dattier@ddsw1.mcs.com (David W. Tamkin)
Subject: stale lock removal
Organization: Contributor Account at ddsw1, Chicago, Illinois  60657
Date: Wed, 29 Jul 1992 16:14:17 GMT
X-Disclaimer:  Material posted in this article is the sole responsibility of
                the poster and does not represent MCSNet or the system owners.

The discussion of file locking from the shell has raised a question in my
mind.

Say a process finds that another process has the lock and it's going to wait
a bit and then try again.  How can it determine whether the process that has
the lock is actively using it or has stalled?

One thing I considered is to make the lock with mkdir and then > $lockdir/$$
to put the locking process's signature on it.  Then, if a process finds a
lock in existence, it can ps -p `(cd $lockdir; echo *)`, but [1] a stalled
process might not necessarily disappear from the ps output, and [2] the
process that had the lock when mkdir failed could have given it up since.
Maybe [2] isn't a problem, because then ps -p would still return a nonzero
exit status.

Potentially process A could find that process B had the lock and go into these
tests; B could end and process C could get the lock but not yet have created
the signature file by the time A tests for a signature file to find out which
process has the lock.  Then, for absence of a signature file, A would get a
nonzero exit from ps -p, think B had gone zombie, steal a lock that really
belongs to process C, and make a mess.  [As I muse, I see some relief to that
if a process giving up its lock does rm -r $lockdir so that the directory and
the signature file disappear together; that way an empty lock directory could
be recognized as one where a fresh lock hasn't been signed yet.]

Another thought I had was mkdir lockdir.* and then mv lockdir.* lockdir.$$;
if another process has the lock, sh will expand the asterisk in the mkdir
command to the existing name and mkdir will fail, even if the process that
has the lock hasn't yet renamed it (in which case the asterisk will be
expanded to a literal asterisk).  Unfortunately, in sh another fork will be
needed (expr or tr, for example) to get the owning process out of the lock
name.

I don't want an unremoved stale lock to make another process to keep
repeating its sleeps until the system goes down.  One could put a numeric
limit on the number of sleep cycles it takes and then, if the signature
hasn't changed, figure the older process has stalled and then steal the lock.
That does allow for a race condition, though.

Finally, is there some good way simply to tell the age of a lock (if not one
made with /etc/link, at least one make with mknod p or with mkdir)?  If a
lock is older than a certain age, one can figure that it is stale.  Various
ls options will display last inode modification time or access time, but how
does one compare them to the current time efficiently?

Any suggestions?  This will have to be done with shell scripts or existing
utilities.

David W. Tamkin   Box 59297   Northtown Station, Illinois  60659-0297
dattier@ddsw1.mcs.com    CompuServe: 73720,1570    MCI Mail: 426-1818
Newsgroups: comp.unix.shell
From: Tom Christiansen <tchrist@convex.COM>
Subject: Re: setting variable from script to current environment??
Originator: tchrist@pixel.convex.com
Reply-To: tchrist@convex.COM (Tom Christiansen)
Organization: CONVEX Realtime Development, Colorado Springs, CO
Date: Thu, 23 Jul 1992 03:37:48 GMT
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 wayne@gbrmpa.gov.au (Wayne Amisano):
:I am trying to write a script to set an environment variable in
:my tcsh environment.  I could use an alias to do it, but would
:much rather do it from a script.  What i need to do is, run a
:script to change the value of one environment variable, but
:every time i do this, it changes the variable in the spawned
:process, but it then disappears when it dies.
:
:I need this variable to remain around!!  Any ideas would be welcome.

RTFFAQ.

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


If God had meant for us to be naked, we would have been born that way.
From: cedman@714-725-3165.nts.uci.edu (Carl Edman)
Subject: Re: zsh was Re: tcsh in the future - what should it be like?
Newsgroups: comp.unix.shell
Reply-To: cedman@golem.ps.uci.edu (Carl Edman)
Date: 24 Jul 92 15:56:48 GMT
Distribution: comp.unix.shell

Tony J Yeates writes
> cedman@714-725-3165.nts.uci.edu (Carl Edman) writes:
> > And most of all why would anyone bother ? To see how much
> > effort, talent and   good ideas have gone into tcsh is
> > almost heart-rending. I've previously   publicly asked
> > for any good reason to continue to use csh descended
> > shells   instead of eg. zsh and been met only with
> > resounding silence. 
> 
> tcsh has an excellent use interface (i.e. command line
> editing), incorporating the best features of ksh, csh
> and 4DOS IMHO. Its also backward compatible with tcsh (a
> painless transition).

That is the biggest problem of tcsh - it is compatible with csh which means  
that it has almost all the csh brain damage.

> I've never used zsh, and haven't heard any rave-reviews

Well, then you haven't been reading this newsgroup very long, I take it ? :-)

> ... is this something special or just another free shell?
> Whats the associated programming language like?  (If its
> not Bourne Shell, ksh, REXX, perl or csh compatible -
> forget it, there are too many shell language
> alternatives already!)

Combines the best of all imaginable worlds by having almost all the interactive  
features of tcsh (only the most fancy custom command line completion stuff  
introduced in the most recent tcsh is not in zsh yet) in addition to many  
useful ones of its own. But it is based on sh/ksh, not csh which means that it  
is can also be used for programming tasks.

	Carl Edman

Newsgroups: comp.unix.shell
From: Tom Christiansen <tchrist@convex.COM>
Subject: Re: tcsh in the future - what should it be like?
Originator: tchrist@pixel.convex.com
Keywords: tcsh
Reply-To: tchrist@convex.COM (Tom Christiansen)
Organization: CONVEX Realtime Development, Colorado Springs, CO
Distribution: comp.unix.shell
Date: Fri, 24 Jul 1992 00:13:40 GMT
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 yeates@rtsg.mot.com (Tony J Yeates):
:First redirect stdout, then redirect both stdout (now eliminated)
:and stdout.  e.g. to "loose" stderr and retain stdout:-
:
:	( command > /dev/tty ) >& /dev/null

You're deceiving yourself.  stdout just got lost.
/dev/tty is NOT stdout.  See csh.whynot for details.

--tom
-- 
    Tom Christiansen      tchrist@convex.com      convex!tchrist
I can identify with steelworkers. I can identify with workers that 
have had a difficult time.
		--Vice President Dan Quayle addressing workers at 
Newsgroups: comp.unix.shell
From: sjs@netcom.com (Stephen Schow)
Subject: Re: file name completion for ksh?
Date: Wed, 22 Jul 92 19:44:07 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Distribution: na

The ksh is hands down the best.  As the last response showed, there is usually
a way to do it in the ksh.  In addition, the ksh has tons of over features
that none of the other shells can even touch.  

If you have access to the ksh...use it and just start learning how to do 
stuff.

-- 
------------------------------------------------------------------
Steve Schow    | But you don't have to use the claw, if you
sjs@netcom.com | pick the pear with the big paw paw......
               | Have I given you a clue......?
               |                       - Baloo the Bear
------------------------------------------------------------------
From: cedman@714-725-3165.nts.uci.edu (Carl Edman)
Subject: Re: GNU bash shell -- how to do csh alias things in bash functions
Newsgroups: comp.unix.shell
Reply-To: cedman@golem.ps.uci.edu (Carl Edman)
Date: 24 Jul 92 20:56:21 GMT

David Keber writes
> Specifically, I have two directory related aliases in csh like this:
> 
>     alias dir='ls -aFglNqsT \!* | more'
>     alias ls='ls -CFq \!* | more'
> 
> My understanding is that you cannot put command line arguments into
> bash aliases (right?), so I wrote the following two bash functions:
> 
>     dir () { ls -aFglNqsT $1 | more ; }
>     ls () { ls -CFq $1 | more ; }
> 

The problem with these functions is the ls function. When you type
'ls' the 'ls' function is executed. But during the execution of this
function you call 'ls' again. Bash will take this to mean the 'ls'
function, nor the external 'ls' command. So the 'ls' function gets
called again ad infinitum, or until process slots run out. Change
these definitions so that it is clear that you are refering to the ls
program eg. like this.

dir () { /bin/ls -aFglNqsT $1 | more ; }
ls () { /bin/ls -CFq $1 | more ; }

> 
> Another question I had was in converting the following alias:
> 
>     alias whereis "find ~ -name '\!*' -print | more"
> 
> the function I wrote was:
> 
>     whereis() { find ~ -name $1 -print | more }
> 
> For some reason, this function won't work with the single quotes just
> after the -name option and before the -print function (why?).  As it
> is now, it just works unreliably.  In csh, this is supposed to give a
> list of all files matching a specific pattern, for example
> 
>           whereis *.ps
> 
> would list the full pathname of any file that ended in ".ps".

The problem here is command line expanasion. The shell will expand
*.ps to the names of all ps files in the current directory and then
pass that argument list to whereis. Whereis will then just take the
first of that list and try to find that (as you used $1). Try calling
whereis like this to avoid premature expansion.

       whereis '*.ps'

Some shells (like zsh) also include a noglob directive which prevents
wildcard expansion for some functions. Check you bash doc on this.

	Carl Edman

Newsgroups: comp.unix.shell
From: etxmesa@eos.ericsson.se (Michael Salmon)
Subject: Re: Where does the sugar go? (was Re: Sort problem )
Reply-To: etxmesa@eos.ericsson.se (Michael Salmon)
Organization: Ericsson Telecom AB
Date: Fri, 31 Jul 1992 10:25:10 GMT

In article <1253@uknet.ac.uk>, 
tlg@uknet.ac.uk (Tim.Goodwin) writes:
|> In article <84902@netnews.upenn.edu> chip@eniac.seas.upenn.edu (Charles H. Buchholtz) writes:
|> >I agree, but I often wonder what to do with the output "sugar", such
|> >as prompts or headers, which are not well suited for filtering.
|> >...
|> 
|> UNIX is (was) a diet OS.  Sugar free.
|> 
|> I fume every time I want to say
|> 
|>     sccs delget `sccs info`
|> 
|> but can't.  This "sugar" is bitter to my taste.
|> 
|> Pragmatically, why not turn on the sugar with a command line flag?

Or have 2 commands as sccs has, info and tell.

The suggestion of using 3> isn't a bad one either (apart from
compatability with old scripts). We could have a stdsugar that pointed
to fd 3 if it was open otherwise to stdout. Then of course we could add
a shell redirection of *> to catch all when we wanted that. Maybe thats
something for plan 9 or hurd to thing of, SunOS only has 64 file
descriptors.

-- 

Michael Salmon

#include	<standard.disclaimer>
#include	<witty.saying>
#include	<fancy.pseudo.graphics>

Ericsson Telecom AB
Stockholm
Newsgroups: comp.unix.shell
From: peter@merlin.acadiau.ca (Peter Steele)
Subject: Re: tcsh - too many features?
Organization: Acadia University
Date: Fri, 31 Jul 1992 11:03:33 GMT

>If you think tcsh has too many features then forget about ever learning perl.

And don't even go *near* zsh!
--
Peter Steele        Unix Services Manager            peter.steele@acadiau.ca 
Acadia Univ., Wolfville, NS, Canada B0P 1X0  902-542-2201  Fax: 902-542-4364
Newsgroups: comp.unix.shell
From: Tom Christiansen <tchrist@convex.COM>
Subject: Re: file locking in shell scripts
Originator: tchrist@pixel.convex.com
Reply-To: tchrist@convex.COM (Tom Christiansen)
Organization: CONVEX Realtime Development, Colorado Springs, CO
Date: Fri, 24 Jul 1992 21:01:30 GMT
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 friedman@gnu.ai.mit.edu (Noah Friedman):
:You can easily create a lock file in a C program using
:
:            open (lockfile_path, O_CREAT|O_EXCL|..., mode);
:
:This is an atomic operation, so you shouldn't have to worry about any race
:conditions (locally, anyway.. I don't know if anything is guaranteed over
:NFS, including other locking methods!)

Only atomic under UNIX, not under NFS.

You must use the fcntl() method there, and good luck with your 
friend lockd.

:   Tom or Larry: can perl do this correctly?

It's really more up to the lockdaemon than to perl.  Sigh.

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

    All language designers are arrogant.  Goes with the territory... :-)
	    --Larry Wall in <1991Jul13.010945.19157@netlabs.com
Xref: sparky comp.unix.shell:3077 comp.lang.perl:4847
From: merlyn@romulus.reed.edu (Randal L. Schwartz)
Newsgroups: comp.unix.shell,comp.lang.perl
Subject: Re: How to compile a shell script?
Date: 21 Jul 92 16:01:00 GMT
Article-I.D.: romulus.MERLYN.92Jul21090055
Organization: Reed College

In article <14h0jrINNvd@betty.cs.widener.edu> brendan@cs.widener.edu (Brendan Kehoe) writes:
   Someday someone will write sh2perl.  (Note you'd probably only really
   win on things that were more procedurally heavy than exec'ing a lot of
   different shell commands for various things.)

OK, here's sh2perl: :-)

#!/usr/bin/perl
print "#!/usr/bin/perl\nsystem <<'UnlikelyString'\n",<>,"\nUnlikelyString\n";

There.  Too easy. :-)

print "Just another Perl hacker," # in chicago.  can't be creative. :-)

--
Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
merlyn@reed.edu (guest account) merlyn@ora.com (better for permanent record)
cute quote: "Welcome to Portland, Oregon -- home of the California Raisins!"
Newsgroups: comp.unix.misc,comp.unix.programmer,comp.unix.questions