Worm/Passwords
Gregory M. Paris
> they are easy to remember. A better technique, to come up with safer
> password, is to pick a phrase and use the initial letters and numbers:
> 'A stitch in time saves nine' for the password asits9.
I just used this heuristic to crack passwords on our system and found ten of
them! Just kidding. The point is that adopting any single system is not the
answer. No one system is better than any other, once it becomes well known.
Encouraging the use of more password selection methods is what is really
desired.
--
Greg Paris <g...@rayssd.ray.com>
{decuac,gatech,necntc,sun,uiucdcs,ukma}!rayssd!gmp
I'm losing my mind over matter.
John B. Nagle
Some years ago, I posted a small piece of code to the net which
was intended for incorporation in password-setting programs to prevent
the use of easily guessable passwords. In response to the recent
troubles, I am reposting it to comp.sources.unix.
John Nagle
id for use with uunet/usenet
> In article <22...@cornell.UUCP> pia...@cs.cornell.edu (Christine Piatko) writes:
> > they are easy to remember. A better technique, to come up with safer
> > password, is to pick a phrase and use the initial letters and numbers:
> > 'A stitch in time saves nine' for the password asits9.
>
> I just used this heuristic to crack passwords on our system and found ten of
> them! Just kidding. The point is that adopting any single system is not the
> answer. No one system is better than any other, once it becomes well known.
> Encouraging the use of more password selection methods is what is really
> desired.
It is possible to adopt a single system, if that system is random. For
example, I have included below a random password generating program, written
for SYS V, but I have been told that it does compile on BSD (please, no flames)
BSD systems may have to change the lines with srand48() and lrand48().
To compile it type:
cc (any local flags) -DMAIN randpass.c -o randpass
It can also be compiled as a callable function. To compile it this way type:
cc (any local flags) randpass.c -c
When calling the program use the following options:
-a to use all printable characters instead of
letters + numbers only
-s # where # is the length of the generated password
-n # where # is the number of passwords to generate.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
#include <stdio.h>
#include <ctype.h>
/*
* randpass.c -- generate really random passwords. For SYS V Unixes only.
* Includes all ASCII chars '0' through 'z', except '@' and '\\'
*/
#define PASSCHARS 80
#define TRUE 1
#define FALSE 0
#ifdef MAIN
main(argc, argv)
#else
char *randpass(argc, argv)
#endif
int argc;
char *argv[];
{
int i, c;
static char s[PASSCHARS+1];
extern long lrand48();
extern void srand48();
extern long time();
int DFLT_LEN = 8;
int option, err = 0, all = 0, num = 1;
char *program;
extern char *optarg;
program = *argv;
while (( option = getopt(argc, argv, "as:n:")) != EOF) {
switch (option) {
case 's': DFLT_LEN = atoi(optarg);
while (*optarg) {
if (!isdigit(*optarg)) {
err = TRUE;
break;
}
optarg++;
}
if ( !err && (DFLT_LEN <2 || DFLT_LEN > PASSCHARS) ) {
fprintf(stderr,"Invalid size for password\n");
exit(1);
}
break;
case 'a': all++;
break;
case 'n': num = atoi(optarg);
while (*optarg) {
if (!isdigit(*optarg)) {
err = TRUE;
break;
}
optarg++;
}
break;
default: err = TRUE;
}
if (err) break;
}
if (err) {
fprintf(stderr,"%s: [ -a ] [ -s # ] [ -n # ]\n",program);
exit(-1);
}
srand48(time((long *)0));
while (num--) {
for (i = 0; i < DFLT_LEN; ++i)
{
while ((c = lrand48() % 75 + '0') == '@' || c == '\\' ||
( !all && (
( c < 65 && c > 57) ||
( c > 90 && c < 97) ) ) )
;
s[i] = c;
}
#ifdef MAIN
s[DFLT_LEN] = '\n';
write (1, s, DFLT_LEN+1);
#else
s[DFLT_LEN] = 0;
return s;
#endif
}
exit(0);
} /* randpass.c */
John F. Haugh II
I have been working on a drop-in replacement for login and friends since I
learned of the Internet virus.
It has been posted to alt.sources and pubnet.sources. I truly welcome
comments and invite your participation. I'd have posted it to
comp.unix.sources but it is far from finished.
--
John F. Haugh II +----Make believe quote of the week----
VoiceNet: (214) 250-3311 Data: -6272 | Nancy Reagan on Artifical Trish:
InterNet: j...@rpp386.Dallas.TX.US | "Just say `No, Honey'"
UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------
Barry Margolin
>It is possible to adopt a single system, if that system is random.
As has been pointed out in many papers on security, random passwords
open up a big security hole. They are hard to remember, so users are
more likely to write them down. One of the rules of good password
management is "Don't write your password anywhere."
Multics has a password generator that tries to help in this regard.
Rather than generating a completely random string of characters, it
generated fake words. It has tables of syllables and digraphs, and
some rules for which syllables are likely to follow others in a
pronounceable word (probably based on a statistical analysis of
English). The syllables are then combined randomly, with skewing
based on the combination rules. These nonsense words are easier to
remember than completely random strings.
A problem with this Multics feature is that a cracker who knows that a
user uses a generated password could probably generate a list of all
the generated words in order of likely generation.
Barry Margolin
Thinking Machines Corp.
bar...@think.com
{uunet,harvard}!think!barmar
John B. Nagle
>It is possible to adopt a single system, if that system is random. For
>example, I have included below a random password generating program, written
>for SYS V, but I have been told that it does compile on BSD (please, no flames)
NO GOOD. Just find out, or guess, roughly when the password was changed,
and you can start guessing passwords. Last-login information is helpful here.
The time(II) call returns a value in units of seconds, so if you know when
someone logged in, the number of values to try is modest. Even if you don't,
just trying the value for each second over the busy hours of the day for the
last few days or weeks will probably provide some useful guesses.
Remember Von Neumann: "Anyone attempting to generate random numbers by
deterministic means is, of course, living in a state of sin."
The notion of generating random passwords is a good one, although
in environments where employees do not face severe disciplinary action for
security breaches, people tend to write them down and leave them near terminals.
But the generation technique must be better. Better sources of a few
random bits include using low-order bits from a microsecond clock, reading
angular addresses from all available rotating media, and computing hash
functions on sections of system memory. Using a clock value with one-second
ticks is not acceptable.
Always bear in mind that mapping a non-random value into a large space
does not make the value more random.
John Nagle
Jordan Brown
> It is possible to adopt a single system, if that system is random. For
Somebody go by this fellow's office and look at all the desk blotters and
scraps of paper to find written-down passwords. Then log in and mail him
a note to go watch War Games.
Doug Gwyn
>I have been working on a drop-in replacement for login and friends since I
>learned of the Internet virus.
Why? Your replacement would not have stopped this virus.
Making life harder for legitimate users does not necessarily
increase security, and it often achieves the opposite effect.
Ron Elliott
> In article <17...@glacier.STANFORD.EDU> j...@glacier.UUCP (John B. Nagle) writes:
> > Some years ago, I posted a small piece of code to the net which
> >troubles, I am reposting it to comp.sources.unix.
>
> comments and invite your participation. I'd have posted it to
> comp.unix.sources but it is far from finished.
> --
I guess it's too much to hope for, but here goes:
1) There are more and better minds avaliable to fix problems
regarding virii, worms, bugs, and the like than there are
people who will exploit these problems. However, if these
problems aren't widely and openly discussed, the more and
better minds won't be thinking about solutions.
Hence, count one vote for net.security.
2) The courts and society will have their way with the
Morriss'. That's the American way. I doubt that
net.fuzzy.opinions will count for much. Let's move
on.
3) Thousands of us out here don't have source code, and have
to rely on software venders. These venders are mostly
unresponsive to any problem brought up by end-users. Only
high level publicity and threat of negative corporate
image will move these venders to react. Often, even these
these threats aren't enough. Until there are more responsive
venders, we source-code-users are vunerable to all kinds of
attack -- and will remain vunerable.
4) Many of you talk about the thousands of hours lost due to
the Morris Worm. How about something like "rm *" ? How many
hours have been lost over the last 15 years over that
bug-feature.? Yes, I know the workarounds, and have installed
them. How come though Un*x venders still havn't issued fixed
rm's or even discuss the matter in their documentation? Or
even supplied the workarounds in their distribution?
Just had to put in my $0.02. Thanks for your attention.
Ron Elliott.
Flames Burn Bandwidth. Better Sent to /dev/null
Richard A. O'Keefe
> 4) Many of you talk about the thousands of hours lost due to
> the Morris Worm. How about something like "rm *" ? How many
> hours have been lost over the last 15 years over that
> bug-feature.? Yes, I know the workarounds, and have installed
> them. How come though Un*x venders still havn't issued fixed
> rm's or even discuss the matter in their documentation? Or
> even supplied the workarounds in their distribution?
You usually know when rm * happens, and if your site has a competent
administrator you can recover your state as of the previous day. An
rm mistake doesn't erode the trust in a world-wide community!
Now, how _do_ you fix "rm *"? Suppose you restrict rm to delete exactly
one file. Watch:
foreach F (* .o)
rm $F
end
OOPS! Major bug in foreach! Better fix that.
for F in * .o
do rm $F
done
OOPS! Major bug in for! Better fix that.
echo * .o | xargs -l1 rm
OOPS! Major bugs in echo and xargs! Better fix them.
Moral: you can't change _one_ thing.
PS: I first heard about "rm *" in the Unix V7 documentation...
John F. Haugh II
>In article <85...@rpp386.Dallas.TX.US> j...@rpp386.Dallas.TX.US (John F. Haugh II) writes:
>>I have been working on a drop-in replacement for login and friends since I
>>learned of the Internet virus.
>
>Why? Your replacement would not have stopped this virus.
I currently don't have any systems running TCP/IP or sendmail. Since the
current front-line attack for UUCP systems is through login, I thought it
would be a great idea.
One other consideration was that in the real world system programmers
don't have the source to all known forms of Unix to play with. Very soon
I hope there will be an infinitely configurable login to use.
>Making life harder for legitimate users does not necessarily
>increase security, and it often achieves the opposite effect.
And please examine the code before being so critical. Several of the new
[ cloned, rather ] features do not inconvenience the user.
Alan Char
|Now, how _do_ you fix "rm *"? Suppose you restrict rm to delete exactly
|one file. Watch:
| foreach F (* .o)
| rm $F
| end
|OOPS! Major bug in foreach! Better fix that.
|
|Moral: you can't change _one_ thing.
Actually, you can change the shell. (Nowadays, that's more like three to
five things.) For example, I would REALLY appreciate in csh a variable
set expandcheck=5
So that if some shell expansion expanded to more than 5 things, it would
prompt for confirmation:
% rm * .o
*: matches 400 files, are you sure?
Comments on this idea? --Alan
Achut Reddy
>A problem with this Multics feature is that a cracker who knows that a
>user uses a generated password could probably generate a list of all
>the generated words in order of likely generation.
>
pseudo-random number generator (say the low order bits of a
high-resolution clock).
Achut Reddy
Nick Felisiak
> My favorite - how much time do you spend explaining to your users not
> to tell their passwords to everyone else in the entire company?
> Our users routinely login as each other to avoid having to copy files
> back and forth between accounts. Nice, eh?
Perhaps I'm just a simple developer not caught up in the wave of paranoia, but
I trust my associates, and really don't worry too much if they login as me, if
I've had an attack of paranoia and protected something they have a need to
access.
If it wern't for the fact that our machines are accessible to the outside
world on phone lines, I'd argue very strongly that we should avoid passwords
at all costs!
Come on now, most of us are on the same side, aren't we?
--
- Usual disclaimers.
--
Nick Felisiak
Spider Systems Ltd
ni...@spider.co.uk
uunet!ukc!spider!nick
Matt Crawford
) For example, I would REALLY appreciate in csh a variable
) So that if some shell expansion expanded to more than 5 things, it would
) prompt for confirmation. Comments on this idea?
This sounds much, MUCH better than changing any other system program in
any way.
Matt
Rich Kulawiec
developed locally, and now in general use here. For further info,
it's probably best to contact Matthew Bradburn at m...@j.cc.purdue.edu,
since he's the author. Enclosed below is the abstract from the paper
describing the system.
"rm * .o" vs. the Novice User
Matthew J. Bradburn
Purdue University Computing Center
West Lafayette, IN 47907
ABSTRACT
This paper addresses the need for a mechanism to
recover accidentally deleted files. We consider
various procedures for saving ("entombing") the
these files and the relative merits of each.
Many of our users occasionally have reason to
require the restoration of some file, or group of
files, which has been accidentally deleted.
Currently, each user must create his own file
backup procedure which may not be efficient,
effective, or secure, and which may cause some
inconvenience by consuming a large portion of the
user's allotted disk space, or they must burden
the Computing Center staff with requests to
retrieve files from backup tape, a procedure which
may involve the loss of many hours' work and which
may not result in the recovery of the file.
While we recognize that the most comprehensive
method of solving this problem is to do so at the
kernel level, we feel that practical considera-
tions (including portability) make other solutions
more attractive. Our system of file entombing can
be added to any program without source code
changes by recompiling it with our entombing
library. This causes our subroutines to be sub-
stituted for system calls which commonly destroy
files.
Richard A. O'Keefe
>In article <6...@quintus.UUCP> o...@quintus.UUCP (Richard A. O'Keefe) writes:
>|Moral: you can't change _one_ thing.
>Actually, you can change the shell. (Nowadays, that's more like three to
>five things.) For example, I would REALLY appreciate in csh a variable
> set expandcheck=5
>Comments on this idea? --Alan
Well, there _is_ such a feature already, except that the limit is rather
high, and you can't change it (:-). BSDish systems impose a limit of
10,240 bytes of argv[]; this seems to include the pointers, so you can't
pass more than about 2000 files to any command (hence xargs(1)). The
trouble is that I can't think of a reasonable number for the limit: I
do "egrep foo $dirs/*.c" (rummaging around in dozens of files) often
enough that I'd find it a nuisance to have to clear a small limit. If
you are doing something non-destructive to the files, you usually don't
want a limit, it's only if you're over-writing or destroying the files
that you have a problem. And expandcheck _still_ wouldn't stop
find . ! -user $LOGNAME -exec rm {} \;
{remove all files not owned by me in the current subtree} -- forget the
"!" and you lose big. The standard trick for csh is
alias rm "/bin/rm -i"
Charles Meo
>> 4) Many of you talk about the thousands of hours lost due to
>> the Morris Worm. How about something like "rm *" ? How many
>> hours have been lost over the last 15 years over that
>> bug-feature.? Yes, I know the workarounds, and have installed
>> them. How come though Un*x venders still havn't issued fixed
>> rm's or even discuss the matter in their documentation? Or
>> even supplied the workarounds in their distribution?
>
> You usually know when rm * happens, and if your site has a competent
> administrator you can recover your state as of the previous day. An
> rm mistake doesn't erode the trust in a world-wide community!
>
> Now, how _do_ you fix "rm *"? Suppose you restrict rm to delete exactly
> one file. Watch:
<stuff deleted>
Why not put something in rm to check for the '*' token by itself and say
something like:
Are you sure y/n?
You may recognise this prompt; it is from the DYING UPPER CASE O/S:
MSDOS!!!
I am sure unix wizards will find this unnecessary and tedious: just like
restoring yesterday's backup (which we ALL did didn't we?) and bringing
in the work lost.
Perhaps this is a worthwhile departure from the traditional unix mode of
operation, 'Silent but Deadly'.
Chuck.
Obnoxious Math Grad Student
And while whosoever is at it, how about a histnoclobber variable? The
only time I've regretted having noclobber unset was the time that I had
an unintended invocation of a clobbering command via history.
Any other goodies like this for the merely mildly clumsy/paranoid?
ucbvax!garnet!weemba Matthew P Wiener/Brahms Gang/Berkeley CA 94720
John Mackin
> Actually, you can change the shell. (Nowadays, that's more like three to
> five things.) For example, I would REALLY appreciate in csh a variable
>
> set expandcheck=5
>
> So that if some shell expansion expanded to more than 5 things, it would
> prompt for confirmation:
>
> % rm * .o
> *: matches 400 files, are you sure?
>
> Comments on this idea? --Alan
My basic comment is `Oh, no!!!'
The point about any hack that is supposed to make mistakes in
command lines, say rm command lines, less dangerous is that it's
just fine as long as the people who are going to use it are never,
at any time in the future, going to use a different UNIX system on
which the hack doesn't exist. When they do, they will get into
big trouble, because they won't be used to being careful with
`dangerous' commands, like rm; they'll expect the system to
babysit them, and it won't, just like it never should have in
the first place.
I know systems where rm is interactive by default. I've personally
seen plenty of users on such systems whose habitual way of cleaning
up a directory was `rm *'. How much trouble will they be in when
they go somewhere else that runs a _real_ rm command?
Hacks like this are a _terrible_ idea. Please do not
implement such things.
John Mackin, Basser Department of Computer Science,
University of Sydney, Sydney, Australia
jo...@basser.oz.AU (john%basser...@UUNET.UU.NET)
{uunet,mcvax,ukc,nttlab}!munnari!basser.oz!john
Paul Traina
< Actually, you can change the shell. (Nowadays, that's more like three to
< five things.) For example, I would REALLY appreciate in csh a variable
<
< set expandcheck=5
<
< So that if some shell expansion expanded to more than 5 things, it would
< prompt for confirmation:
<
< % rm * .o
< *: matches 400 files, are you sure?
<
< Comments on this idea? --Alan
I'll assume (from the gist of the protection) that this is to stop
stupidity, rather than a deliberate attack. After all, a worm would
either know what to do at this point, or more likely, have used unlink(2).
My question is, if we have the shell fix it, how can we get the shell
to understand flags passed to the executable? To give an example, if I
do 'rm * .o' I probably wouldn't mind seeing the match message come up.
However, 'rm -f * .o' means do it, yes I mean it, don't ask stupid questions.
I would use it in a shell script no doubt. Now of course, it's pretty unlikely
that's what I meant. Perhaps better consistency checking in rm itself would
be the answer.
For instance, have rm (if -f is not used) check each path parameter passed to
it. If one doesn't match at existing file at all, ask that the command be
confirmed. Well, like any solution that's been discussed so far, this has
problems too. I guess the best solution would be a modification of the human
involved so s/he always types what s/he means to type. hmmm.
Comments on these ideas?
------
Paul Traina To believe that what is true for
{uunet|pyramid}!comdesign!pst you in your private heart is true
p...@cdi.com for all men, that is genius.
James Logan III
>Why not put something in rm to check for the '*' token by itself and say
>something like:
>
>Are you sure y/n?
This isn't possible without modifying the shell. Rm never gets
to see the asterisk because the shell expands it and passes the files
that match the wildcard expression to the rm command.
>MSDOS!!!
<<GAG>> If they made MS-DOS support multiple links to a file,
let you move a file rather than having to copy and delete, and
got rid of that stupid out-of-reach backslash it wouldn't be half
bad. Then again...
-Jim
--
Jim Logan lo...@vsedev.vse.com
(703) 892-0002 uucp: ..!uunet!vsedev!logan
inet: logan%vsedev....@uunet.uu.net
Alan Char
|In article <12...@atari.UUCP> ac...@atari.UUCP (Alan Char) writes:
||I would REALLY appreciate in csh a variable
|| set expandcheck=5
|
|I do "egrep foo $dirs/*.c" (rummaging around in dozens of files) often
|enough that I'd find it a nuisance to have to clear a small limit. If
|you are doing something non-destructive to the files, you usually don't
|want a limit, it's only if you're over-writing or destroying the files
|that you have a problem.
Usually if I'm doing "egrep foo $dirs/*.c", I expect the command to take
a substantial (at least noticable) amount of time, so I don't think I'd
find it much of a nuisance to confirm my intentions. It just depends on
what your tolerance is for that kind of thing, I guess.
|And expandcheck _still_ wouldn't stop
|
| find . ! -user $LOGNAME -exec rm {} \;
|
|{remove all files not owned by me in the current subtree} -- forget the
|"!" and you lose big.
Personally, I would blame this on the syntax of find. This has nothing to
do with shell expansion generating something you didn't intend. It has to
do with an arcane syntax being prone to typographical catastrophes.
|The standard trick for csh is
| alias rm "/bin/rm -i"
Yes, but getting confirmed when you want to remove only one file? Every time?
That really IS a nuisance.
% rm core
rm: remove core?
--Alan Char
Charlie Geyer
This is all very easy. If you don't like rm(1) put
alias foo rm -i
in your .cshrc or put a shell script foo in ~/bin
rm -i $*
and use foo to remove files.
Guy Harris
Of course, SunOS 4.0 imposes a limit of
#define NCARGS 0x100000
so it won't help on a 4.0 system....
Patrick Barron
>something like:
>
>Are you sure y/n?
The 'rm' command never sees the '*', since wildcard expansion is done by
the shell. For instance, if your current directory contains "this_file",
"that_file", and "other_file", and you type "rm *", what the 'rm' command
actually sees is "rm other_file that_file this_file". That is, it doesn't
know a wildcard was used.
--Pat.
Alan Char
||From article <12...@atari.UUCP>, by ac...@atari.UUCP (Alan Char):
||
|| set expandcheck=5
||
|| So that if some shell expansion expanded to more than 5 things, it would
|
|My question is, if we have the shell fix it, how can we get the shell
|to understand flags passed to the executable? To give an example, if I
|do 'rm * .o' I probably wouldn't mind seeing the match message come up.
|
|However, 'rm -f * .o' means do it, yes I mean it, don't ask stupid questions.
|I would use it in a shell script no doubt. Now of course, it's pretty unlikely
|that's what I meant. Perhaps better consistency checking in rm itself would
|be the answer.
As is the case now, I think the shell should not have to know about
special flags passed to the executable, so your script will still get
caught. Of course, after you've debugged your script, you can put
"unset expandcheck" at the top.
|For instance, have rm (if -f is not used) check each path parameter passed to
|it. If one doesn't match at existing file at all, ask that the command be
|confirmed. Well, like any solution that's been discussed so far, this has
|problems too. I guess the best solution would be a modification of the human
|involved so s/he always types what s/he means to type. hmmm.
Well, it's not always rm that needs to be checked. How about
"mv * .o <remote dir>"? This was the original objection in the article
by Richard O'Keefe: You can't change just one thing. --Alan
a.v.reed
> It is possible to adopt a single system, if that system is random. For
> example, I have included below a random password generating program, written
> for SYS V, but I have been told that it does compile on BSD (please, no flames)
> BSD systems may have to change the lines with srand48() and lrand48().
And after you generate this random "pasword", no human user will be able
to remember it. And so your users will write the "passwords" down, paste
them on their terminals, keep them in the top drawers of their desks,
carry them in their pockets and lose them in the cafeteria - do I need
to go on? If it is written down, *IT IS NOT A SECURE PASSWORD*. And if
it cannot be reliably *remembered* by the average user, it *WILL* be
written down. The world's least secure systems are those whose security
is managed by the "I program computers, don't bother me with human
psychology" types. Yes, there are good programs that generate passwords
which incorporate a random element but can be remembered by humans
anyway. To design such a program, you have to know not only what is
difficult to crack, but also what is easy for people to remember.
(Hint: ever used AT&T Mail?)
Adam Reed (a...@mtgzz.ATT.COM)
Louis A. Mamakos
% set noglob
You will have no further problems with pesky '*' characters. Haven't we
solved this problem yet? Is this is problem that needs to be solved? Is
this a problem at all?
Louis A. Mamakos WA3YMH Internet: lo...@TRANTOR.UMD.EDU
University of Maryland, Computer Science Center - Systems Programming
Doug Gwyn
>something like:
>Are you sure y/n?
This is supposed to be comp.unix.wizards (UNIX-WIZARDS),
not comp.unix.questions (INFO-UNIX). Wizards know what's
wrong with your suggestion. In fact, anyone who read the
UNIX tutorial should know.
J A Biep Durieux
doesn't exist.
--
Biep. (bi...@cs.vu.nl via mcvax)
Is the difference between a difference of degree and a differ-
ence of sorts a difference of degree or a difference of sorts?
Rahul Dhesi
is to make the "rm" command a built-in, so it asks "Are you sure?" if
the user attempts "rm *".
Experienced users could alias "rm" to "rm -n", which never prompts with
the "Are you sure?" message.
Note that making "rm" a built-in does not mean that the code for it
must be linked with the shell. The shell only needs to recognize "rm"
and handle wildcard expansion in a special way, and then invoke /bin/rm
to do the actual unlinking. This naturally means that a user could
create a new alias for /bin/rm, or invoke /bin/rm by full pathname, to
get the effect of the original program. This is actually a feature
rather than a bug.
Better still, let's avoid changing what established commands do. All
shell authors, please include a special keyword "del" that prompts
with the "Are you sure?" question if it sees "*" as a parameter, and
then exec /bin/rm. Tell novice programmers to use "del".
--
Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
T T Phillips
> to remember it. And so your users will write the "passwords" down, paste
I don't know about other government installations installations,
but here at Los Alamos, we are given what seem to be random
passwords annually. You must protect your password as you do
your badge. My observation is that the engineers, scientists,
secretaries and managers seem to be able to cope with the random
passwords without significant problems.
M.R.Murphy
I think that the following shell script does about what is asked for. The
idea is to use existing tools rather than change exisiting tools.
#! /bin/sh -
if test `echo "$*" |wc -w` -gt 5
then
echo ": expands to more than 5 arguments, are you sure? \c"
read answer
if test "$answer" != "yes" -a "$answer" != "y"
then
exit 1
fi
fi
#change "echo" below to the command(s) that you feel like doing for $*
echo $*
Barry Shein
idea the more I like it, it can be implemented in some reasonable way.
There's even precedent, like noclobber, so I don't see any look and
feel problem with it (ie. some things like this are a stench in the
nose of god, this isn't.)
A very similar proposal would be more like the CMU Csh (and I believe
the Korn shell) which echo back history substitutions and wait for
confirmation <NL>, I could imagine doing (OPTIONALLY) the same for
wildcard matches past a certain threshold...
The only possible objection to any of this that pops to mind is
transparency between shell scripts and interactive sessions but that's
easy, it should always start out as false/zero/infinity and if set
will do its thing (heck, if it confirmed to /dev/tty it could be
useful in scripts.)
-Barry Shein, ||Encore||
Steven Bickel
# providing you have some extra disk space and the rm_purge alias is executed
# regularly ie. in a .login file. It will currently purge all files from
# the removal directory after 21 days.
# remove script
num=0;
for i in $@
do
if test -r $i
then
chmod 777 $i;
rm_dir="/usr/tmp/rmtmp/$i";
echo "moved" $i $rm_dir ;
mv $i $rm_dir;
num=num+1;
fi
done
alias rm_purge "find /usr/tmp/rmtmp/ -name '*' -print -atime +21 -exec rm -r '{}' \;"
Steve Bickel bic...@nprdc.arpa
Systems Engineering Assoc. (619) 553-9306
Naval Personel R & D Center.
M.R.Murphy
|I think that the following shell script does about what is asked for. The
|idea is to use existing tools rather than change exisiting tools.
|
|#! /bin/sh -
|if test `echo "$*" |wc -w` -gt 5
|then
| echo ": expands to more than 5 arguments, are you sure? \c"
| read answer
| if test "$answer" != "yes" -a "$answer" != "y"
| then
| exit 1
| fi
|fi
|#change "echo" below to the command(s) that you feel like doing for $*
|echo $*
And I should know that
`echo "?#"`
is preferable to
`echo "$*" |wc -w`
because it is faster.
More than one way to skin a cat (no offense to cat lovers :-)
Larry Wall
with an alias to some form of vanish or other. It's a trivial program to
write--there's one as an example with the perl distribution. Then just
expire your .deleted directories after a few days.
Then it doesn't matter if they type rm * .o because they can turn around
and unvanish anything they like.
Haven't we learned anything from all these whiz-bang graphics interfaces
with trashcans?
Larry Wall
lw...@jpl-devvax.jpl.nasa.gov
Richard A. O'Keefe
>At the very least, 'rm * .o' should refuse to do anything when the file '.o'
>doesn't exist.
I have posted a "del" command to comp.sources.unix which does this.
Obnoxious Math Grad Student
>However, 'rm -f * .o' means do it, yes I mean it, don't ask stupid
>questions. I would use it in a shell script no doubt. Now of course,
>it's pretty unlikely that's what I meant.
And while you're at it, don't forget the problem of the lexicograph-
ically first file being named "-f".
You know. That could make for a cutesy pie variant of the Morris worm.
Just deposit "innocent" files named "-x" for various values of `x' in
random directories. Confuse and annoy the hell out of people for a few
minutes whenever they type * as part of a command.
This game won't work with "<name" and ">name" though. Awwww.
Dennis L. Mumaugh
Spafford out to summarize and put into the 100 questions
document:
In a job a long time ago in a place far, far away .... Four of
us got bit by the rm * problem within two days. I lost a whole
day's worth of power coding and had to reconstuct an entire
project from memory [see Knuth on the merits of this] when I
typed rm *.c instead of rm *.o.
So, I decided there must be a better way. Since we also had a
set of other similar commands [del and delete for the PDP-10
lovers] we built a trap door into the shell. If the command was
exactly {rm|del|delete} and the glob function returned a true
[expanded a * ? or [ ...] construct] we echoed out to the
terminal the expanded form of the command and a request to
confirm.
e.g the command
rm *.c
whould result in
glob: rm foo.c bar.c barf.c fubar.c unix.c
confirm?
The query would only be echoed if the stdin was a terminal.
Also, it worked ONLY with simple command names, full path names
or alias expansions weren't checked.
We also got bit later by the following:
rm -rf ..
So we had to put a check into rm for that kind of combination.
Yes, we did get a few people who would hit y<CR> by habit. But
only until they did it one too many times. After that they
learned.
--
=Dennis L. Mumaugh
Lisle, IL ...!{att,lll-crg}!cuuxb!dlm OR cuuxb!d...@arpa.att.com
Dennis G. Rears (FSAC)
J A Biep Durieux writes:
>At the very least, 'rm * .o' should refuse to do anything when the file '.o'
>doesn't exist.
"rm" doesn't see the *. The shell does all the expansion. All rm
sees is the options and a list of file names. If you don't like the
actions of rm, either change it by making the interactive option the
default or write you own. rm does what you tell it do nothing more
nothing less. Gee, I wish my boss was like that :-).
Dennis
Dennis G. Rears (FSAC)
Here at Picatinny ( An Army R&D Center) our computers use both
systems. We also have to protect our passwords. It is not always
done. Our higher level people routinely give their passwords to
their secretaries so they can pull off email for them. I have
accounts on over 10 computers. On machines where I can choose my
own password they are the same. of course on some I forgot/never
use the password and just use rlogin/rsh. On the ones I have the
assigned passwords, I don't remember them, I keep them encrypted on my
UNIX machines. I see passwords written down a lot. Also since I
am considered the "expert" in my building people say to me:
Can you help me? My problem is ****. My user name is ****. You
can get my password anyway so I might as well give to you. It is
***. Even though I tell them keep your passwords to yourself
they always like to give it out.
Dennis
--------------------------------------------------------------------------
Dennis Rears
ARPA: dre...@ardec-ac4.arpa UUCP: ...!uunet!ardec-ac4.arpa!drears
AT&T: 201-724-6639 USPS: Box 210, Wharton, NJ 07885
Work: SMCAR-FSS-E, Bldg 94, Picatinny Ars, NJ 07806
--------------------------------------------------------------------------
Andrew Koenig
> And while you're at it, don't forget the problem of the lexicograph-
> ically first file being named "-f".
If your rm command uses getopt, you can remove a file named "-f" by saying
rm -- -f
or even
rm -f -- -f
The `--' is a widget that says `There are no more options after this;
everything else is an argument even if it looks like an option.'
--
--Andrew Koenig
a...@europa.att.com
Eduardo Krell
>If your rm command uses getopt, you can remove a file named "-f" by saying
>
> rm -- -f
What's wrong with good old "rm ./-f" ?
This works regardless of getopt.
Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ
UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekr...@ulysses.att.com
Henry Spencer
>> And after you generate this random "pasword", no human user will be able
>> to remember it. And so your users will write the "passwords" down, paste
>> them on their terminals, ...etc.
>
>passwords annually. You must protect your password as you do
>your badge. My observation is that the engineers, scientists,
>secretaries and managers seem to be able to cope with the random
>passwords without significant problems.
This is unquestionably true when the environment is such that users can
be *ordered* to protect their passwords properly, with serious penalties
for violating such orders. It doesn't work so well in looser environments.
--
Sendmail is a bug, | Henry Spencer at U of Toronto Zoology
not a feature. | uunet!attcan!utzoo!henry he...@zoo.toronto.edu
jim gustafson
>In article <6...@quintus.UUCP> o...@quintus.UUCP (Richard A. O'Keefe) writes:
>|one file. Watch:
>| foreach F (* .o)
>| rm $F
>| end
>|OOPS! Major bug in foreach! Better fix that.
>| [ other examples ]
>|
>|Moral: you can't change _one_ thing.
Maybe I missed something, but doesn't everybody have 'rm' re-defined as
an alias or $HOME/bin/rm? Something like:
for fnam in $*
do
mv -f $fnam $HOME/.trash
done
In Korn, I use alias rrm=/bin/rm in my .kshrc so I can do the dirty work.
(the trick is to always use 'rm' ;-).
--
Jim Gustafson UUCP: uunet!ndsuvax!ncgus
North Dakota State University Bitnet: ncgus@ndsuvax
Fargo, North Dakota 58105 Internet: nc...@plains.nodak.edu
Doug Gwyn
-> to remember it. And so your users will write the "passwords" down, paste
-> them on their terminals, ...etc.
-I don't know about other government installations installations,
-but here at Los Alamos, we are given what seem to be random
-passwords annually. You must protect your password as you do
-your badge. My observation is that the engineers, scientists,
-secretaries and managers seem to be able to cope with the random
-passwords without significant problems.
I don't know what your observations consist of. Security specialists
would bet that most of those persons have written down the password
(also combinations, etc.) and that there is a significant chance that
it could be compromised undetectably. I assume your badge has your
photo on it and other things that make it much harder to compromise
than a password.
Doug Gwyn
>And while you're at it, don't forget the problem of the lexicograph-
>ically first file being named "-f".
In a general-purpose shell script, one would want to use the -- option
list terminator to avoid this problem. (Some systems still don't fully
support the UNIX command language syntax standard, though.)
Obnoxious Math Grad Student
>In article <17...@agate.BERKELEY.EDU>, wee...@garnet.berkeley.edu (Obnoxious Math Grad Student) writes:
>> And while you're at it, don't forget the problem of the lexicograph-
>> ically first file being named "-f".
>If your rm command uses getopt, you can remove a file named "-f" by saying
> rm -- -f
I'm not asking about how to remove the file (thanks, anyway, although
I see the how-many-ways-to-do-so discussion is starting up again): I'm
just saying that "while you're at it [ie, `fixing' rm *]", you as might
as well consider the problem of the user who wants to remove some of his
files, and types "rm -i *", expecting to get interactive prompting, and
instead has all his files removed. If the first file is "-f", you now
have one unhappy user.
"rm -i -- *" will avoid this problem, but I don't expect a lot of people
to get into the habit of typing "--" here and in similar situations.
Michael I. Bushnell
>I'm not asking about how to remove the file (thanks, anyway, although
>I see the how-many-ways-to-do-so discussion is starting up again): I'm
>just saying that "while you're at it [ie, `fixing' rm *]", you as might
>as well consider the problem of the user who wants to remove some of his
>files, and types "rm -i *", expecting to get interactive prompting, and
>instead has all his files removed. If the first file is "-f", you now
>have one unhappy user.
Actually you don't:
Script started on Sat Nov 19 22:42:02 1988
turing.unm.edu 1 ls
foo
turing.unm.edu 2 touch ./-f
turing.unm.edu 3 ls
-f foo
turing.unm.edu 4 rm -i *
rm: remove foo? y
turing.unm.edu 5 ls
-f
turing.unm.edu 6 ^D
script done on Sat Nov 19 22:42:23 1988
All that happens is that ./-f isn't removed. As the man page *and*
the source (RTFS, you know...) say, -f prevents error messages and the
asking of questions for files you can't write.
N u m q u a m G l o r i a D e o
\ Michael I. Bushnell
\ HASA - "A" division
/\ mi...@turing.unm.edu
/ \ {ucbvax,gatech}!unmvax!turing.unm.edu!mike
Richard A. O'Keefe
>Maybe I missed something, but doesn't everybody have 'rm' re-defined as
>an alias or $HOME/bin/rm?
I do hope not. It is a bad idea to define aliases for the standard
commands (and if you are a system administrator, giving new users
profiles with such redefinitions in them is _extremely_ bad manners).
For example, I very much like the "-F" option in ls, but it would be
incredibly stupid to "alias ls 'ls -F'". Instead I "alias lf 'ls -AF'"
and use "lf". Just so, if you don't like what rm does, _leave_it_alone_
and define yourself an alias, script, C program, or whatever, called
"del", "delete", "delf", or whatever takes your fancy, and use that.
Apart from the obvious problem of changing something so that it no longer
does what the manual says it does, there are other reasons for not relying
on aliases for standard commands. For example, we have several different
systems on our net here, running several varieties of UNIX. Some of them
have the C shell, some don't. Some of them I have my own accounts on,
some of them I share a "porting" account. If I rely on an alias for rm
to protect me, the next time I log into a new box I will be _sunk_.
Boyd Roberts
>
>However, 'rm -f * .o' means do it, yes I mean it, don't ask stupid questions.
>
Incorrect. When I type "rm * .o" it means do it, yes I mean it, don't ask
stupid questions. Admittedly, I'd just type "rm *".
How many more safety net arguments to we have to suffer? There's no
way:
set don't-do-an-incredibly-stupid-thing = 5
will ever be an appropriate solution to this (non) existant problem.
Do something stupid, pay the price. Easy!
The next thing you'll want is VAXen like console processors where you
can go:
>>> SET NO AXE THROUGH CPU
And a titanium cage closes around your processor.
Boyd Roberts NEC Information Systems Australia
bo...@necisa.necisa.oz
``When the going gets wierd, the weird turn pro...''
D
G. Ewing
>You must protect your password as you do your badge.
Um... I hope this isn't the *only* requirement for protecting passwords.
Presumably it's not so serious to let someone else *see* your badge...
[:-), in case you haven't realised it yet.]
Greg Ewing Internet: gr...@cantuar.uucp
Spearnet: gr...@nz.ac.cantuar Telecom: +64 3 667 001 x8357
UUCP: ...!{watmath,munnari,mcvax,vuwcomp}!cantuar!greg
Post: Computer Science Dept, Univ. of Canterbury, Christchurch, New Zealand
Disclaimer: The presence of this disclaimer in no way implies any disclaimer.
Jeff Venters
The following alias will prevent wildcard expansions. The actual wildcard
characters will be passed to the script. Add the following alias to your
~/.cshrc:
alias rm ~/bin/del \!\*:q
Next, add the following shell script to your personal "bin" directory (or
wherever you like). Obviously, the script could be made intellegent enough
to recognize "-f" but it would be slower (csh is very inefficient). You
could write a C-program to do this slightly faster (you would still have
to fork a shell to glob the input arguments).
---- CUT HERE -------- CUT HERE -------- CUT HERE -------- CUT HERE ----
#! /bin/csh -f
set nonomatch file=$0 # no wildcard matches allowed/get argv[0]
set exp_names=($argv) # expand wildcards (if any)
#
# if the number words after globbing is not equal to the orignal,
# ask for conformation.
if ($#argv == $#exp_names) then
/bin/rm $exp_names:q
exit $status # exit script here (faster)
else
echo "$file:t: The following $#exp_names files will be deleted:"
# show them the damage they could do
/bin/ls -Fd $exp_names:q
echo -n "Are you sure you want to do this (Y or N)? "
if ($< =~ [Yy]) then
exec /bin/rm $exp_names:q
else
echo ""
echo "$file:t: aborted - no files deleted"
exit (1)
endif
endif
---- CUT HERE -------- CUT HERE -------- CUT HERE -------- CUT HERE ----
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Jeff Venters, Convex Computer Corporation, Richardson, Texas
Internet: ven...@convex.COM | UUCP: {uiucuxc,sun,rice}!convex!venters
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Geoff Clare
}The point about any hack that is supposed to make mistakes in
}command lines, say rm command lines, less dangerous is that it's
}just fine as long as the people who are going to use it are never,
}at any time in the future, going to use a different UNIX system on
}which the hack doesn't exist. When they do, they will get into
}big trouble, because they won't be used to being careful with
}`dangerous' commands, like rm; they'll expect the system to
}babysit them, and it won't, just like it never should have in
}the first place.
}
}I know systems where rm is interactive by default. I've personally
}seen plenty of users on such systems whose habitual way of cleaning
}up a directory was `rm *'. How much trouble will they be in when
}they go somewhere else that runs a _real_ rm command?
}
}Hacks like this are a _terrible_ idea. Please do not
}implement such things.
I wouldn't go so far as to say don't implement them at all.
What I would say is CALL THEM SOMETHING ELSE. If you implement a
safe 'rm', call it something else like 'del', and tell novice users
not to use 'rm' because it is dangerous. (To make sure they don't
use it you could put a dummy 'rm' in their path which echoes "rm is
dangerous - use del instead". Then when they move to a different
system and they get 'del: not found' they will know how to use 'rm'
but will be careful with it.
--
Geoff Clare UniSoft Limited, Saunderson House, Hayne Street, London EC1A 9HH
g...@root.co.uk ...!mcvax!ukc!root44!gwc +44-1-606-7799 FAX: +44-1-726-2750
Jonathan Bayer
> jba...@ispi.UUCP writes:
> > It is possible to adopt a single system, if that system is random. For
> > example, I have included below a random password generating program, ...
>
> Somebody go by this fellow's office and look at all the desk blotters and
> scraps of paper to find written-down passwords. Then log in and mail him
> a note to go watch War Games.
(mild flame)
Mr. Brown,
Instead of being critical without offering suggestions, why don't you
shut up? The program I posted was an example. We don't use it here because
we are too small. I have seen other critisisms of my program, but they
were constructive in that they were pointing out problems with it. I challenge
you to develop a program which will create random passwords which will be
easy to remember. The challenge includes posting it to the net in less than
200 lines. If you do this then you will have contributed something worthy to
the net instead of useless abuse.
(flame off)
Jonathan Bayer
Intelligent Software Products, Inc.
Tony Nardo
>This is all very easy. If you don't like rm(1) put
>
> alias foo rm -i
>
>in your .cshrc...
A half-measure. If you *really* don't like rm(1), put
alias rm "rm -i"
in your .cshrc file. That way, if you want to use rm without the -i switch,
you have to do a little extra work (/bin/rm). By the same token,
alias cp "cp -i"
can protect you from yourself with file copying.
==============================================================================
ARPA, BITNET: t...@aplcomm.jhuapl.edu
UUCP: {backbone!}mimsy!aplcomm!trn
==============================================================================
Juergen Wagner
>In article <18...@ndsuvax.UUCP> nc...@ndsuvax.UUCP (jim gustafson) writes:
>>Maybe I missed something, but doesn't everybody have 'rm' re-defined as
>>an alias or $HOME/bin/rm?
>
>I do hope not. It is a bad idea to define aliases for the standard
>commands (and if you are a system administrator, giving new users
>profiles with such redefinitions in them is _extremely_ bad manners).
Redefining "rm" as "rm -i", "mv" as "mv -i", and "cd" et al. to the prompt-
changing versions is *VERY* common practice, I think. System administrators
do not put these into the .cshrc to surprise people, they are there to help
beginners to start in a safe environment (at least safer than without these
definitions), without having to worry about mistakenly typing "rm foo/ *".
Expert users may change that as soon as they are logged in for the first time.
(Before I work on a system, I check the .cshrc, .login, etc. to see what's
in there.)
>For example, I very much like the "-F" option in ls, but it would be
>incredibly stupid to "alias ls 'ls -F'". Instead I "alias lf 'ls -AF'"
>and use "lf". Just so, if you don't like what rm does, _leave_it_alone_
>and define yourself an alias, script, C program, or whatever, called
>"del", "delete", "delf", or whatever takes your fancy, and use that.
Bad example. "ls" is a command you can execute umpteen plus one times without
destroying anything. "rm" and "mv" *CAN* destroy files. I agree that aliasing
"ls" to "ls -F" or similar stuff would be stupid. Aliasing "rm" is less stupid
because it protects the user against him/herself. Personally, I tend to give
longer names to destructive command than to the non-destructive versions.
"rm" prompts me for confirmation, "delete" doesn't. If an expert user doesn't
like that aliasing as soon as he/she logs in for the first time...
>Apart from the obvious problem of changing something so that it no longer
>does what the manual says it does,
The point is, if UNIX gives a novice user a command to erase important files
with five keystrokes and no confirmation, this command should be made safe,
so it will at least prompt for confirmation. By the kind of aliasing we are
discussing here, the safety of commands is increased, never decreased.
Therefore, the manual accurately describes what "rm" does, modulo that little
safety feature.
People who know little about UNIX are likely to know basic commands such as
"rm", "mv", "cp", "ls", ... and they know what they do. They do not know how
to alias commands, edit the .cshrc. Everything is magic in the beginning, so
they try to stick to the commands they think they know. Well, and then it just
happens that files are accidentially deleted.
> there are other reasons for not relying
>on aliases for standard commands. For example, we have several different
>systems on our net here, running several varieties of UNIX. Some of them
>have the C shell, some don't. Some of them I have my own accounts on,
>some of them I share a "porting" account. If I rely on an alias for rm
>to protect me, the next time I log into a new box I will be _sunk_.
I guess, you wouldn't consider yourself a novice user of UNIX. If you like the
unaliased "rm", that's fine. Unexperienced users do appreciate the extra
protection.
As for non-csh shells, how about "rm () { /bin/rm -i $* }" as an 'alias' for
"rm".
As a consultant, I am also working under other peoples accounts. If I am just
fixing something, I simply do not rely on "rm" being aliased. If I have to work
longer under some account, I define the aliases necessary, or just load my
setup into a new shell.
To summarize: Some people like the aliases, some don't. Those who like and
appreciate them (like novice users and many expert users) should have them,
those who don't like them, who are considering them harmful, bad style, or
whatever, shouldn't have them. I don't seen any reason why anybody should
insist on any solution being better than the other - it depends!
However, it is desirable to protect new users against the unwanted effects of
some silent and destructive commands, so I would put the respective aliases
into new users .*rc file. Those who don't like them (etc.) can remove the
aliases easily, and will have completely different .cshrc/.login files than
the system default, anyway.
This is my personal opinion.
--
Juergen Wagner gan...@csli.stanford.edu
wag...@arisia.xerox.com
paul kirkaas
>In article <7...@quintus.UUCP> o...@quintus.UUCP (Richard A. O'Keefe) writes:
>>In article <18...@ndsuvax.UUCP> nc...@ndsuvax.UUCP (jim gustafson) writes:
--- (deleted) ---
>>For example, I very much like the "-F" option in ls, but it would be
>>incredibly stupid to "alias ls 'ls -F'". Instead I "alias lf 'ls -AF'"
--- (deleted) ---
> ... I agree that aliasing
>"ls" to "ls -F" or similar stuff would be stupid...
I may well be incredibly stupid. I suspect, however, there is far more
convincing evidence for that proposition than the fact that
I alias ls to ls -F.
I guess I'm a little disturbed at how easily we call others stupid
for using harmless practices which differ from our own.
If I ever run into problems because of my alias, I'll change it.
So far I've survived.
Paul Kirkaas
kir...@cs.ucla.edu
Jonathan I. Kamens
>Why is this a partial answer? Well, there are lots of scripts around
>that just blindly use their caller's path, and they'd get the safe "rm",
>thus harassing users with questions as to whether they really want to
>remove /tmp/xa012237a, /tmp/xa012237b, /tmp/xa012237c, /tmp/xa012237d,
>and so on.
>
>Anyone got a better solution? (Yeah, I know, rewrite all those @#$!@#
>scripts. I said "a better solution". Maybe we could rewrite all the
>intro-to-Unix books so they don't mention "rm". ;-)
I am in the process of designing for Project Athena a suite of
file-deletion utilities which allow for file recovery (Can you say
"design review?" I knew you could. :-). This suite will replace rm
and rmdir with a program called delete (intuitive, isn't it?) and add
a few other commands (lsdel, undelete, expunge, purge), but we decided
very early on that we wouldn't really *replace* rm and rmdir, that is,
we would not give the new programs the same names as the old ones, for
the very reason mentioned here.
We decided to place delete somewhere in the standard user's path and
to modify all Project Athena documentation to recommend the use of
delete.
Furthermore, although delete will be more user-friendly than rm ever
was, it can be made to act exactly like rm or rmdir (it replaces both
of them) by giving it certain command-line arguments. Therefore,
someone who wants to continue to type "rm" and "rmdir" and have the
file-recovery option available to him/her cna alias rm and rmdir to
the proper delete commands.
I think that this way, we have the best of both worlds.... new users
of Project Athena get a real file-deletion utility that is
user-friendly and intelligent, while experienced users can get the
same interface as rm or rmdir and still have the ability to recover
accidentally deleted files.
Finally, since I assume that most shell scripts aren't going to read
the user's .cshrc or .profile file (or at least they *shouldn't*),
they won't get any aliases that the user might have defined, so
they'll use the correct rm, i.e. the real one.
Jonathan Kamens
MIT '91 -- Project Athena Watchmaker
j...@Athena.MIT.EDU
Joseph S. D. Yao
>Come on now, most of us are on the same side, aren't we?
Emphatically yes.
On the other hand ... what side was that now?
Truth, fairness, justice, equality, niceness, goodness, integrity,
proper treatment of each other as sentient beings, etc. OK?
Fine. And a five shilling prize to the first one to properly define
all of the words in the last sentence ... AND get every other being on
the net to agree to his or her (or its) definitions.
The two problems are: (a) since all of us are fallible human beings
with different perceptions of the world, we need to agree on some
basics (and each pair needs to agree!) before allowing even the degree
of intimacy that shared passwords provides; and (b) even the most
idealistic among us (and I'm sure I just barely don't qualify) would
agree that there are not only folks like RM Jr who make mistaskes out
there (oh dear, did I make one too????), but also "bad guys" who get
their kicks out of capitalising on others' trust, and even destroying
those others' properties after betraying that trust.
(*sigh*) Until we are all perfected, after the Millenium (but, again,
a mille of what?) ... [;-)]
Joe Yao js...@hadron.COM (not yet domainised)
hadron!jsdy@{uunet.UU.NET,dtix.ARPA,decuac.DEC.COM}
arinc,att,avatar,blkcat,cos,decuac,dtix,\
ecogong,empire,gong,grebyn,inco,insight, \!hadron!jsdy
kcwc,lepton,netex,netxcom,phw5,rlgvax, /
seismo,sms,smsdpg,sundc,uunet /
Joseph S. D. Yao
>In article <6...@quintus.UUCP> o...@quintus.UUCP (Richard A. O'Keefe) writes:
> if some shell expansion expanded to more than 5 things, it would
>prompt for confirmation:
What I did, a decade ago, was to have a list of _commands_ which the
shell, after calling glob, would always prompt for after printing out
the entire expanded command line. The list included "rm" and "rmdir".
No prompting if "glob" was not called.
Perhaps I should go resurrect that code.
Joseph S. D. Yao
>#! /bin/sh -
>if test `echo "$*" |wc -w` -gt 5
> ...
>#change "echo" below to the command(s) that you feel like doing for $*
>echo $*
This shell script, and all shell scripts that use "$*" in this manner,
fail in the presence of special characters like white space in file
names. This is a problem, if you read the (numerous) articles titled
"Ghost file", and the like.
Lars P. Fischer
>< Actually, you can change the shell. (Nowadays, that's more like three to
>< five things.) For example, I would REALLY appreciate in csh a variable
><
>< set expandcheck=5
><
>However, 'rm -f * .o' means do it, yes I mean it, don't ask stupid questions.
#!/bin/csh
unset expandcheck
rm -f * .o
--
Lars Fischer, fis...@iesd.dk, {...}!mcvax!diku!iesd!fischer
We must remove the TV-induced stupor that lies like a fog
across the land. - T. H. Nelson
Richard A. O'Keefe
>>I do hope not. It is a bad idea to define aliases for the standard
>>commands (and if you are a system administrator, giving new users
>>profiles with such redefinitions in them is _extremely_ bad manners).
>
>Redefining "rm" as "rm -i", "mv" as "mv -i", and "cd" et al. to the prompt-
>changing versions is *VERY* common practice, I think. System administrators
>do not put these into the .cshrc to surprise people, they are there to help
>beginners to start in a safe environment (at least safer than without these
>definitions), without having to worry about mistakenly typing "rm foo/ *".
A very common practice may never-the-less be a bad idea.
It is no service to beginnners to give them an alias WHICH DOES NOT MATCH
THE DOCUMENTATION. By all means, provide a "del" or "delete" command
which is safe, and a "move" or "rename" command which is safe, but if you
want to protect beginners from the dangerous commands, give them aliases
which flat-out refuse to do anything at all:
alias rm 'echo "Use \"delete\" to delete files; rm is dangerous."'
System administrators may not _intend_ to surprise people with their
redefinitions, but that is one of the effects they do in fact produce.
The other effect is that the commands available to the beginner no longer
match the documentation; how anyone can perceive that as good is beyond me.
>>For example, I very much like the "-F" option in ls, but it would be
>>incredibly stupid to "alias ls 'ls -F'". Instead I "alias lf 'ls -AF'"
>>and use "lf". Just so, if you don't like what rm does, _leave_it_alone_
>>and define yourself an alias, script, C program, or whatever, called
>>"del", "delete", "delf", or whatever takes your fancy, and use that.
>
>Bad example.
No, it is _not_ a bad example. If I "alias ls 'ls -F'", I am likely to
use it in a script which _relies_ on that behaviour. Then I give it to
someone else and it doesn't work. THIS KIND OF THING **HAPPENS**. But
if I use "lf" in my script, then the other user is going to be told that
there isn't any such command.
>As for non-csh shells, how about "rm () { /bin/rm -i $* }" as an 'alias' for
>"rm".
Well, that's nice for you, but many of the machines that I use do not
support Bourne shell functions. I get
syntax error: `(' unexpected
when I try that. (We have Suns running 3.x and 4.x, which support shell
functions, but also Suns running 2.x, which don't, and several other
machines running 4.2BSD. What is *really* confusing is the machines
which offer two "universes", where shell functions work in one universe
but not the other. My .profile has to work under _all_ of these.)
>As a consultant, I am also working under other peoples accounts. If I am just
>fixing something, I simply do not rely on "rm" being aliased.
No, that's not the problem. The problem is that you can't rely on it NOT
being aliased. If you are using someone else's account, you haven't
ANY IDEA *AT ALL* what rm does until you have checked for aliases and
shell functions. Especially with the "rm" aliases which copy files
someone else, if you issue an "rm" command to delete a file that you have
just created, you cannot rely on that not destroying a file that the real
user was hoping to keep. I for one am sick of having to type \rm.
>However, it is desirable to protect new users against the unwanted effects of
>some silent and destructive commands, so I would put the respective aliases
>into new users .*rc file.
I repeat: it is ok to alias a standard command so that it refuses to do
anything at all, and makes it plain that it has not worked. But it is
a bad idea to make a command _do_ something, but not _exactly_ what is
described in the manual. I tell you what, someone who writes C code can
do a lot of silent and destructive stuff. Let's protect users against
this by making sure they can't use the C compiler. (And we must keep
them away from perl, or the poor little simpletons will get into real
trouble. And we had better disable ">", so let's set noglob and noclobber
in everyone's .cshrc.)
If you want a shell which tries to protect people from themselves, is
verbose, and is widely liked, there are at least two implementations
of DEC's DCL command language for UNIX.
Or you could do what Sun are starting to do in SunOS 4.0, and give people
mouse-oriented tools for deleting files &c. Giving people an easy way of
deleting files by clicking on an icon makes thing safer for them without
taking anything at all away. Emacs "DIRED" mode is the same kind of
safety-through-convenience approach.
Richard A. O'Keefe
>I guess I'm a little disturbed at how easily we call others stupid
>for using harmless practices which differ from our own.
I didn't call _you_ stupid. I called your "harmless practice" stupid.
If you are careful to confine your aliases to the C-shell, and always
write your scripts in Bourn shell, and take care never to write shell
functions that redefine standard commands, you're pretty safe. Of
course new users would be well advised to stay away from you when they
need help, because what they see on your screen won't match what they
get, but that's no loss to you (I never said _you_ were stupid).
Aliasing standard commands is like #define if while in C.
Richard A. O'Keefe
[about rm *]
>What I did, a decade ago, was to have a list of _commands_ which the
>shell, after calling glob, would always prompt for after printing out
>the entire expanded command line. The list included "rm" and "rmdir".
>No prompting if "glob" was not called.
Nice one, but how does this handle user commands with similar properties?
(For example, "a.rm".)
One answer, of course, would be to have a
GLOBASK=rm:rmdir
shell variable, so that one could put
GLOBASK=a.rm:$GLOBASK
in ones .profile. (Did I just make a constructive suggestion? Oops.)
Steve Harris
>...I am in the process of designing for Project Athena a suite of
>file-deletion utilities which allow for file recovery ...
Replacing rm (or supplying an alternative "delete" with "undelete"
capability) is a useful task. However, it only goes part way. There
are so many other ways to clobber files (redirection, ":w" in vi, "of="
in dd, etc.).
The extreme in the opposite direction is exemplified by VMS/TOPS-20/
TENEX(??) where files have generation numbers -- you see only the most
recent generation(s), but the older copies do not go away until:
(a) you logout,
(b) you explicitly "expunge" them, or
(c) the OS/operator arbitrarily expunges them (e.g., when the
disk full-ness passes some high-water-mark).
(This is as I remember TOPS-20, I assume VMS (and TENEX and other OS's
derived from TENEX) behave similarly).
This scheme has two problems:
(a) you must have LOTS of disk space available or the system
will be continually expunging, and
(b) UNIX just isn't set up this way (i.e., file names and generation
numbers are incompatible).
Rather than rewriting the kernel and the file system, or rewriting the
shells and all the other utilities, I find intresting the concept of
"watchdog" extensions to the UNIX kernel, described by (damn!! I cannot
find the reference -- I thought it was the summer 88 Usenix conference
but I don't see it in the proceedings -- can anybody help??).
The basic idea is that there exists a set of "watchdog" programs, each
of which protects one (or more) file(s). When your program attempts to
open/read/write/close such a file, the kernel first consults the
watchdog for that file. The watchdog can then, e.g., make a backup
copy in some "shadow" directory, to be "expunged" later. (Obviusly,
there's a lot more you can use a watchdog for than simply keeping backup
copies of files).
Well, that's my five (or ten :-) cents' worth. Hope you can find the
reference -- check back issues of ;login:, and proceedings of other
usenix conferences. Or maybe somebody else can supply it.
--
Steve Harris -- Eaton Corp. -- Beverly, MA -- uunet!etnibsd!vsh
Juergen Wagner
>A very common practice may never-the-less be a bad idea.
I agree 100%.
>...
>want to protect beginners from the dangerous commands, give them aliases
>which flat-out refuse to do anything at all:
> alias rm 'echo "Use \"delete\" to delete files; rm is dangerous."'
That's a good idea, too. But it aliases "rm", so it no longer doesn what the
manual says, ...and beware of shell scripts using this kind of rm.
>...
>The other effect is that the commands available to the beginner no longer
>match the documentation; how anyone can perceive that as good is beyond me.
Hmmm... I think, it's the other way round. Documentation should match the
tools!
>...
>No, it is _not_ a bad example. If I "alias ls 'ls -F'", I am likely to
>use it in a script which _relies_ on that behaviour. Then I give it to
>someone else and it doesn't work. THIS KIND OF THING **HAPPENS**.
>...
People writing shell scripts must not rely on such thinks. If I am writing
a safe shell script, I am either disallowing .cshrc to be read, or giving
pull paths of the commands, or unalias'ing the commands before using them.
People writing shell scripts should do that for the very reason to be
compatible because some users may have weird aliases which are breaking
code.
>...
> If you are using someone else's account, you haven't
>ANY IDEA *AT ALL* what rm does until you have checked for aliases and
>shell functions.
Right! Before I am executing destructive operations, I am checking that.
>...
> I tell you what, someone who writes C code can
>do a lot of silent and destructive stuff. Let's protect users against
>this by making sure they can't use the C compiler. (And we must keep
>them away from perl, or the poor little simpletons will get into real
>trouble. And we had better disable ">", so let's set noglob and noclobber
>in everyone's .cshrc.)
"set noclobber" is a good idea but it will only work in csh, right? As for
the guys writing C code to silently erase a user's files, I wouldn't say
they are beginners, would you? Someone writing such code should know what
he/she is doing. No operating system can be fool-proof without being trivial.
>If you want a shell which tries to protect people from themselves, is
>verbose, and is widely liked, there are at least two implementations
>of DEC's DCL command language for UNIX.
Widely liked? Humph!
VMS isn't foolproof, either (although it would like to be).
>Or you could do what Sun are starting to do in SunOS 4.0, and give people
>mouse-oriented tools for deleting files &c. Giving people an easy way of
>deleting files by clicking on an icon makes thing safer for them without
>taking anything at all away. Emacs "DIRED" mode is the same kind of
>safety-through-convenience approach.
Coming closer! That's my idea of a user-friendly interface. An "undo"
operation should be an essential part of the user interface... but that
will remain utopical for most UNIX systems for the time being, I am afraid.
(why not use a LISP machine :-) ).
---
Charlie Geyer
writes:
>In article <10...@entropy.ms.washington.edu> cha...@mica.stat.washington.edu
>(Charlie Geyer) writes:
>>This is all very easy. If you don't like rm(1) put
>>
>> alias foo rm -i
>>
>>in your .cshrc...
>
>A half-measure. If you *really* don't like rm(1), put
>
> alias rm "rm -i"
>
>in your .cshrc file. That way, if you want to use rm without the -i switch,
>you have to do a little extra work (/bin/rm). By the same token,
>
> alias cp "cp -i"
>
>can protect you from yourself with file copying.
Ah yes. Well actually I do have
alias rm rm -i
alias cp cp -i
alias mv mv -i
set noclobber
in all of my .cshrc files. I just didn't want to *recommend* such a
practice knowing I'd get flamed for it. Only once or twice have I
forgotten with a new account that I haven't set these aliases *yet*.
It is a bit of a pain embedding /bin/rm and /bin/mv in c-shell
scripts I write. Can anyone tell me if this is nonportable? Don't tell
me that if I would just write Bourne shell scripts that I wouldn't have to
worry about the stupid alias. I know that. Also don't tell me the c-shell
is nonportable.
Alex Danilo
> Creeping featurism considered harmful. Leave it alone.
> This is all very easy. If you don't like rm(1) put
> alias foo rm -i
> rm -i $*
> and use foo to remove files.
>
This solution (& lots of others proposed) are just bodges that novice users
would learn about after the fateful 'rm * .o':-) They are also useless for
people who choose to use 'sh' instead of 'csh'.
A possibly better solution could be to destroy the utility 'rm' and make
it a built-in command in 'sh', 'csh' & 'ksh' just as 'cd' is built-in.
Whenever file(s) are removed using wildcards, the shell could simply relink
the file(s) to another unique & (almost) invisible name (i.e. prefixed by
'.') & maintain a linked list of original file names with associated hidden
name. The next command executed by the user may be either an 'unrm' or another
valid command. If 'unrm' was executed the files may simply be relinked &
restored, no harm done. Any other command (valid command that is, not a typo)
following the 'rm' can trigger the shell to unlink all the hidden file names
& achieve the same result as an intentional 'rm'. Perhaps the number of
commands that may be executed before an 'unrm' could be another environment
variable. This system is idiot-proof & saves those late night typing mistake
nightmares. The main drawback is the file space being used until the purge is
actually done. Any shell source hackers think this will slow it too much?
E PLURIBUS UNIX - al...@megadata.oz
D
D
Maarten Litmaath
\shell, after calling glob, would always prompt for after printing out
\the entire expanded command line. The list included "rm" and "rmdir".
It's quite unnecessary to include "rmdir".
--
fcntl(fd, F_SETFL, FNDELAY): |Maarten Litmaath @ VU Amsterdam:
let's go weepin' in the corner! |ma...@cs.vu.nl, mcvax!botter!maart
Jonathan Bayer
> In article <4...@yarra.oz.au>, c...@yarra.oz.au (Charles Meo) writes:
> Once again, it's time to mention the dark side of modifying rm: Lots of
> applications need a way to unconditionally remove files, and for scripts,
> rm is the tool of choice. If the user runs a script, do you really want
> the user to be forced to verify that it is OK to remove all the script's
> /tmp files? I've seen it happen, and many users don't consider that to
> be particularly user-friendly.
>
Another possibility is to have rm check for two things: one, is stdin a
tty (use the isatty() function). If it isn't, emulate the normal rm. Second,
for a user, if only one file is being removed then go ahead and do it.
Otherwise, prompt for each file.
I have implemented a "safe" rm on my system doing the above. It also moves
the removed files to a trashcan directory instead of deleting them. It
has a force option (turns off the safe mode), a verbose option, and others.
If there is interest I will mail to a few requests, if a lot of requests
I will post it instead.
The normal system rm has been moved to "rm2", which is used by a daily
cron script which cleans out the trashcan directories on a daily basis. Only
files which are 7 days old or older are removed.
This program is based on an old posting. The poster's name escapes me
at this point in time, but credit is given in the program.
Brandon S. Allbery
+---------------
| psychology" types. Yes, there are good programs that generate passwords
| which incorporate a random element but can be remembered by humans
| anyway. To design such a program, you have to know not only what is
| difficult to crack, but also what is easy for people to remember.
+---------------
I once hacked together a program that used tables of letters which commonly
followed one another in English to create random but (usually) pronounceable
passwords. I don't know how anyone else's brain works (heck, I'm fuzzy on
how *mine* works ;-) but I find pronounceable passwords MUCH easier to
remember. The program is dust now, along with the computer it ran on (OSI
SuperBoard II, 8K BASIC!) but I should be able to recreate the program with
a little thinking.
A possible enhancement is to use phonemes instead of letters, thus
increasing the chances of a pronounceable password. It could be combined
with a phoneme-to-letter table which could randomly (or maybe not so
randomly, depends on how much time I want to put in it) choose between
alternative representations (f/ph, etc.) of a phoneme.
++Brandon
--
Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X
uunet!hal.cwru.edu!ncoast!allbery <PREFERRED!> ncoast!all...@hal.cwru.edu
allb...@skybridge.sdi.cwru.edu <ALSO> all...@uunet.uu.net
comp.sources.misc is moving off ncoast -- please do NOT send submissions direct
Send comp.sources.misc submissions to comp-sources-misc@<backbone>.
Piercarlo Grandi
As quoted from <46...@mtgzz.att.com> by a...@mtgzz.att.com (a.v.reed):
+---------------
| psychology" types. Yes, there are good programs that generate passwords
| which incorporate a random element but can be remembered by humans
| anyway. To design such a program, you have to know not only what is
| difficult to crack, but also what is easy for people to remember.
+---------------
I once hacked together a program that used tables of letters which commonly
followed one another in English to create random but (usually) pronounceable
passwords. I don't know how anyone else's brain works (heck, I'm fuzzy on
how *mine* works ;-) but I find pronounceable passwords MUCH easier to
remember. The program is dust now, along with the computer it ran on (OSI
SuperBoard II, 8K BASIC!) but I should be able to recreate the program with
a little thinking.
A possible enhancement is to use phonemes instead of letters, thus
increasing the chances of a pronounceable password. It could be combined
with a phoneme-to-letter table which could randomly (or maybe not so
randomly, depends on how much time I want to put in it) choose between
alternative representations (f/ph, etc.) of a phoneme.
As has been discussed at length and conclusively, generating by algorithm
menmonic passwords is a very bad idea, because:
[1] It restricts unconscionably the key space (usually to a few thousand
or at best dozen thousand entries).
[2] If the algorithm used to generate the passwords get known, it can be
used to obtain a complete list of all possibly passwords. This gives a
penetrator confidence that he now knows 100% of the passwords on 100%
of the sites that use the algorithm.
[3] If the penetrator does not the algorithm, he can still usually deduce it
quite easily and accurately because of [1].
Manual generation of passwords also suffers from problem [1], but at least
the penetrator does not enjoy certainty [2].
--
Piercarlo "Peter" Grandi INET: p...@cs.aber.ac.uk
Sw.Eng. Group, Dept. of Computer Science UUCP: ...!mcvax!ukc!aber-cs!pcg
UCW, Penglais, Aberystwyth, WALES SY23 3BZ (UK)
T. William Wells
: followed one another in English to create random but (usually) pronounceable
: passwords.
: SuperBoard II, 8K BASIC!) but I should be able to recreate the program with
: a little thinking.
:
: A possible enhancement is to use phonemes instead of letters, thus
: increasing the chances of a pronounceable password. It could be combined
: with a phoneme-to-letter table which could randomly (or maybe not so
: randomly, depends on how much time I want to put in it) choose between
: alternative representations (f/ph, etc.) of a phoneme.
Save yourself some effort. Go hunt up a `travesty' program. (I think
that was the name.) I recall seeing them in some computer magazines in
the last year or so, and didn't I see one get posted? You ought to
be able to modify one to create pronouncable passwords with only a
little effort.
---
Bill
{uunet|novavax}!proxftl!twwells!bill
The Grey Wolf
>In article <7...@quintus.UUCP> o...@quintus.UUCP (Richard A. O'Keefe) writes:
>>...
>>A very common practice may never-the-less be a bad idea.
>
>I agree 100%.
>
>>...
>>want to protect beginners from the dangerous commands, give them aliases
>>which flat-out refuse to do anything at all:
>> alias rm 'echo "Use \"delete\" to delete files; rm is dangerous."'
>
>
>>No, it is _not_ a bad example. If I "alias ls 'ls -F'", I am likely to
>>use it in a script which _relies_ on that behaviour. Then I give it to
>>someone else and it doesn't work. THIS KIND OF THING **HAPPENS**.
>>...
>
For one thing, csh aliases (which seems to be the format of the aliases
you are describing) are NOT EXPORTED to shell scripts OF ANY SORT. 'ls'
evaluates to whichever 'ls' is found first in your $PATH. If you're going
to write a csh script, you're better off prefacing it with the line
#! /bin/csh -f
The reason I did that was because it saves on my startup time (it won't
read .cshrc). All one *really* needs from one's environs to use a script is
going to be things like $PATH, $TERM, $HOME, possiblye $USER, and maybe
$LOGNAME if you're running under System V...
Now, if you're writing ksh scripts or scripts under a shell which will
support functions, and the user decides to export that function to their
environment (which can be done, I understand), the script will have to
re-define things like "ls" and "rm" to be what they should be, i.e., /bin/ls
and /bin/rm (respectively :-).
With respect to bad practice of re-defining what you want your commands
to do, it's purely a matter of opinion and subject to debate. If I can,
I redefine 'ls' to be '/bin/ls -A'. If I can't, then ls is obviously
one of the braindamaged type that can't tell a file from a tty, and
redefine it to be '/bin/ls -aC'. I'm just used to seeing things a certain
way, and if they come out different, that's my problem.
(ALWAYS type in /bin/rm from someone else's account! point taken: you
never know WHAT they're gonna have set up...I run my own version of rm which
follows the (evidently age-old) process of moving things to a .trash file...)
/*
VCC: "Hey, Wo[ol]f!" | WC: Roan Anderson
UUCP: sun!unisoft!greywolf | First-name-pronounced: "RO-an"
CORP: UniSoft Corporation | ATT: +1 415 420 6410 168
TFTD: "A malfunctioning machine is a sure sign of a flashing red light."
*/
--
...TheysaidDoyouseethebiggreenglowinthedarkhouseuponthehill?andIsaidYesIseethebiggreenglowinthedarkhouseuponthehillTheresabigdarkforestbetweenmeandthebiggreenglowinthedarkhouseuponthehillandalittleoldladyonaHoovervacuumcleanersayingIllgetyoumyprettyandyourlittledogTototoo
I don't even *HAVE* a dog Toto...
Richard A. O'Keefe
>It is a bit of a pain embedding /bin/rm and /bin/mv in c-shell
>scripts I write. Can anyone tell me if this is nonportable?
(1) If you want to avoid aliases, but don't mind picking things up out of
the $path, you should know that quoting any part of a command will
suppress alias lookup. Thus it suffices to write \rm, \mv, and so on.
'rm', "mv" will do as well. Better still is to use the "-f" option if
you have it.
(2) The SVID in section FILSYS(BA_ENV) says what the base of the
directory tree should look like:
/
.../bin
.../dev
.../ect
.../tmp
.../usr
....../usr/bin
....../usr/tmp
The ENVVAR(BA_ENV) section suggests PATH=/bin/usr/bin (sic!).
If the SVID says where rm &co live, I can't find it, but assuming that
cat, cp, ln, ls, mkdir, mv, rm, rmdir are in /bin should be ok.
(It is _not_ portable to assume that "wc" is in /bin.)
Doug Gwyn
> Save yourself some effort. Go hunt up a `travesty' program. (I think
> that was the name.) I recall seeing them in some computer magazines in
> the last year or so, and didn't I see one get posted? You ought to
> be able to modify one to create pronouncable passwords with only a
> little effort.
Save ort. Go be thing to crecall some and dify a lithe you
ought year modidn't programe and dify only able lasty' prograve
to come prones in so, able you ourself see to be to magazin
so, able th only a las ine able pasty' posted? Yought pas
wittle the effor modidn't wasswort. Go be progravest prograves
thin that up and didn't up able yeat year ourself seeing
thate paste posted? Yount I recable nam. Go come.) I seein
to hunt to be effort. Go huncall so, able effort. (I recable
get I reater onesty' progravesty' prograve las to computer
modidn't programe get to huncall seeing thin seeine the
thing thin self seein the to come yoursee come program.
Go magazin th one that posty' progravesty' prone little
progravesty' programe.) I the crecable a `travesty' program.
Go modify and didn't yought you ort. (I somputed? You onou
only a lasswords wast to huncall some and didn't wittle
name a `trave get to be the computer only a `tram. (I some.)
I the yought withated? Youncall so, and dify ought I reat
withe name th one get withe to magazin think to crecall
self so, a little year modidn't passwort. (I sompute them
in so, a little lithat wittle to creater modidn't up a lithe
effor ort. Go be a `traves wasswort. Go crear modidn't wasswords
wittle get the nam. Go crear some youncable effor seein
so, and dify a `traveste thin some.) I thin thin so, able
pronought yeat year some effort. Go hunt wasty' pasted?
Yount you ort. (I reat to created? Yoursee name name.)
Which pretty much sums it up. (The above was created via
"travesty 2", which is the minimum practical scope. Larger
values produce a very high percentage of actual English words.)
This reminds me of output from "jive", for some reason.
Go be a `traves wasswort.
Brandon S. Allbery
+---------------
| jba...@ispi.UUCP writes:
| > It is possible to adopt a single system, if that system is random. For
| > example, I have included below a random password generating program, ...
|
| Somebody go by this fellow's office and look at all the desk blotters and
| scraps of paper to find written-down passwords. Then log in and mail him
| a note to go watch War Games.
I've posted my random password generator (well, first draft of a UNIX/C
version) to comp.sources.misc. It has the advantage that the passwords it
generates are pronounceable (usually!) by speakers of English; this makes
them easier for me to remember, and hopefully for others as well. (My
memory for spelling is closely tied to my memory for pronunciation; if I
remember the pronunciation, I've got the spelling, but *not* vice-versa.)
Richard A. O'Keefe
>In article <65...@csli.STANFORD.EDU> wag...@arisia.xerox.comP (Juergen Wagner) writes:
>>In article <7...@quintus.UUCP> o...@quintus.UUCP (Richard A. O'Keefe) writes:
>>>No, it is _not_ a bad example. If I "alias ls 'ls -F'", I am likely to
>>>use it in a script which _relies_ on that behaviour. Then I give it to
>>>someone else and it doesn't work. THIS KIND OF THING **HAPPENS**.
>For one thing, csh aliases (which seems to be the format of the aliases
>you are describing) are NOT EXPORTED to shell scripts OF ANY SORT. 'ls'
>evaluates to whichever 'ls' is found first in your $PATH.
I don't quite understand what "The Grey Wolf" means here.
Unless you take steps to prevent it, the C shell *does* source .cshrc
when it reads a script (that is, after all, what .cshrc is FOR), and
that is where most people put aliases like that. (If you put your
"rm", "ls", and suchlike aliases in .login, you're safe.) You can
tell which aliases will affect C-shell scripts by doing
% csh -c alias
>If you're going to write a csh script,
>you're better off prefacing it with the line
>#!/bin/csh -f
Indeed you are. You're even better off not writing Csh scripts.
>With respect to bad practice of re-defining what you want your commands
>to do, it's purely a matter of opinion and subject to debate.
Well, everything is subject to debate. But "purely a matter of opinion"
is an attitude of despair. We _can_ approach questions like this
objectively. We simply have to measure which approach is less likely to
lead to error. All it would take to determine whether (a) redefining rm
to be something LIKE rm but different, or (b) adding a new command and
deleting rm, or (c) adding a new command and leaving rm alone, or (d)
doing nothing would be better is an experiment which would take a couple
of months, a few dozen people, and money. Pending such a study (anyone
want to fund me to do it?) we can analyse the matter logically. Of the
four approaches, (a), (c), and (d) all permit disastrous mistakes.
T. William Wells
: In article <2...@twwells.uucp>, bi...@twwells.uucp (T. William Wells) writes:
: > Save yourself some effort. Go hunt up a `travesty' program. (I think
: > that was the name.) I recall seeing them in some computer magazines in
: > the last year or so, and didn't I see one get posted? You ought to
: > be able to modify one to create pronouncable passwords with only a
: > little effort.
: [A travesty of my message]
:-)
: Which pretty much sums it up. (The above was created via
: "travesty 2", which is the minimum practical scope. Larger
: values produce a very high percentage of actual English words.)
Here are the words from your travesty that might do as passwords:
creater crecable crecall huncall lassword lithat magazin
modidnt onesty ourself passwort programe prograve pronough
reater recable seeine sompute somputed traves traveste
wassword wasswort withated wittle yought youncabl youncall
yoursee
(I got a few chuckles making up meanings for some of these, though at
least one is actually a valid English word.
Say, what's a `huncall'? Loot! Loot! Loot! :-)
These were obtained by removing punctuation and words shorter than six
letters, truncating words longer than 8 letters, and deleting words
that `spell' accepted. As you can see, many of these would make
easily pronounceable passwords.
Using a better database might create more or better passwords. And
each user could have his own database; this makes knowledge of the
travesty algorithm useless for guessing someone's password.
Doug Gwyn
> ... lassword ...
Oh, but I can't let you have the lassword!
>As you can see, many of these would make easily pronounceable passwords.
>
>Using a better database might create more or better passwords. And
>each user could have his own database; this makes knowledge of the
>travesty algorithm useless for guessing someone's password.
I didn't mean to imply that this approach wasn't viable, but I
couldn't resist the experiment and thought (since the posted travesty
program wasn't runnable on anything except MS-DOS) that an illustration
of what "travesty" produces might be informative to many readers.
Indeed, use of samples of a natural language itself as a database
for producing statistically similar "random" text is a good idea.
I seem to recall one of the Computer Recreations columns in
Scientific American a couple of years ago exploring this method.
Certainly a larger, more varied database would have produce a better
selection of lasswords.
David W. Barts
only the file's owner or root can unlink() it. BSD already does this,
so the new change wouldn't create yet another UNIX standard, only
more compatability.
David W. Barts N5JRN, Ph. 509-373-4554 (FTS 440-4554), dx...@lanl.GOV
BCS Richland Inc. | 603 1/2 Guernsey St.
P.O. Box 300, M/S S2-01 | Prosser, WA 99350
Richland, WA 99352 | Ph. 509-786-1024
a.v.reed
> > And after you generate this random "pasword", no human user will be able
> > to remember it. And so your users will write the "passwords" down, paste
> > them on their terminals, ...etc.
>
> I don't know about other government installations installations,
> but here at Los Alamos, we are given what seem to be random
> passwords annually. You must protect your password as you do
> your badge. My observation is that the engineers, scientists,
> secretaries and managers seem to be able to cope with the random
> passwords without significant problems.
Not knowing the details, I would assume that a mnemonic heuristic,
similar to that used by AT&T Mail, is also used to generate the
"random" passwords distributed in Lost Alamos.
If, on the other hand, these "passwords" really ARE just random
sequences of printable ASCII, then kremvax!root probably hopes
you really believe that last sentence of yours. And I have a
beautiful bridge I might let you invest in....
Adam Reed (a...@mtgzz.ATT.COM)
Alan Char
GLOBASK is not that different from expandcheck. In fact,
setting GLOBASK=<all commands> is exactly the same as setting
expandcheck=1 modulo the prompt text. You mean there isn't
some value I can use for GLOBASK to ask for all commands? Oh.
--Alan Char
Jakob Riis
>>At the very least, 'rm * .o' should refuse to do anything when the file '.o'
>>doesn't exist.
>
>I have posted a "del" command to comp.sources.unix which does this.
EXACTLY !!
Make new commands, don't mess around with the old ones.
I agree that users need to be protected: Give them safer commands, Menu shells
or PullDown help screens, nurse them good, but don't take away the alertness
to the real thing - Unix is fast and dangerous, real progreammers reread their
"rm" statements twice !!
Don't let users expect that "rm -r *" will help them trim their filesystem
by asking them to confirm each file. Teach a user that, and watch his face
running on another system one day !!
B.T.W:
Think of the portability - 100.000+ shell scripts that needs to be rewritten.
We have enough trouble with differences between BSD and V, Csh, Bsh, Ksh etc.
as it is.
(Just my 2 cents opinion)
Jakob Riis ___________________________________
NCR Systems Engineering Copenhagen | |
| " If Batman is so damned clever, |
j...@ncrsecp.Copenhagen.NCR.com | why is he wearing his undershorts |
or | outside his trousers ? " |
....mcvax!enea!dkuug!ncrsecp!jr | -Danish graffitti |
|___________________________________|
Guy Harris
>Just make it so that if the sticky bit is set on the directory's mode,
>only the file's owner or root can unlink() it. BSD already does this,
4.3BSD, anyway. So does System V Release 3.2; both systems, as I
remember, also allow the owner of the *directory* to remove any entries
in it. I think there's one other case where S5R3.2 allows an entry to
be removed but 4.3BSD doesn't, but I can't remember what it is.
Richard A. O'Keefe
No it isn't, because it is not *possible* to set GLOBASK=<all commands>.
That's an open set. (The set of commands accessible through my $PATH at
the moment is 661, and that's after I pruned my $PATH.) It's also quite
a different perspective; it's quite pointless to limit
echo * | wc -w
which expandcheck would do, whereas the GLOBASK approach explicitly
identifies only the believed-dangerous commands.
I am not seriously proposing GLOBASK; just pointing out that more focussed
approaches than expandcheck are possible.
Jordan Brown
> In article <1...@herron.uucp>, jbr...@herron.uucp (Jordan Brown) writes:
> > jba...@ispi.UUCP writes:
> > > It is possible to adopt a single system, if that system is random. For
> > > example, I have included below a random password generating program, ...
> > Somebody go by this fellow's office and look at all the desk blotters and
> > scraps of paper to find written-down passwords. Then log in and mail him
> > a note to go watch War Games.
> Instead of being critical without offering suggestions, why don't you
> shut up?
You may disagree with me on the security of randomly generated passwords,
but I don't think this tone is reasonable. (At least I don't think my
comment was this nasty. My apologies if it came across that way.)
> I challenge you to develop a program which will create random passwords
> which will be easy to remember.
I'm not sure what "easy to remember" means. Enough users have problems
remembering passwords that *they* picked to make me doubt that any random
scheme has any chance. I didn't mean to say that *your* random password
program was bad, but that they *all* are.
I'm not going to try to write a "better" version, as I'm convinced it
isn't possible to write one "good enough".
> If you do this then you will have contributed
> something worthy to the net instead of useless abuse.
Again, I did not intend abuse. Randomly generated passwords are the
"obvious" answer to the problem of easily-guessed passwords, but cause
their own brand of security hole (which is probably worse, as it doesn't
take the same level of ingenuity to exploit it). Random passwords make
life more awkward for the user while possibly *reducing* security.
Thinking about it, there's another serious problem. If you don't have a
*very* good seed source, your random passwords are easily guessable.
(For instance, suppose you use the time in seconds as your source.
if you know what day the password was assigned, then there are only 86k
passwords to try. It'll typically take a second or so to try each, so
about a day of CPU time later... Time in ms would be better, but it is
still probably practical to observe password changes and search the
appropriate range of random numbers. Write a program that "watches"
/etc/passwd and logs username and time when it's updated. Probably
an adequate solution is to continuously increment a counter while
waiting for a keystroke. That's pretty close to truly random.)
You presented a "solution" to the problem; I poked what I consider
to be a gaping hole in it, one that I thought was "well-known"
(documented in a mainstream motion picture, even).
I hate a flawed solution to a problem more than no solution at all.
At least when you know there's no solution you aren't deceived.
Sorry if I've offended; I just don't think random passwords are a
viable answer. (You'd probably figured that out. :-)
Root Boy Jim
? > jba...@ispi.UUCP writes:
? > > It is possible to adopt a single system, if that system is random. For
? > > example, I have included below a random password generating program, ...
? >
? > Somebody go by this fellow's office and look at all the desk blotters and
? > scraps of paper to find written-down passwords. Then log in and mail him
? > a note to go watch War Games.
? (mild flame)
? Mr. Brown,
? Instead of being critical without offering suggestions, why don't you
? shut up? The program I posted was an example. We don't use it here because
? WE ARE TOO SMALL. I have seen other critisisms of my program, but they
? were constructive in that they were pointing out problems with it. I challenge
? you to develop a program which will create random passwords which will be
? easy to remember. The challenge includes posting it to the net in less than
? 200 lines. If you do this then you will have contributed something worthy to
? the net instead of useless abuse.
? (flame off)
? Jonathan Bayer
? Intelligent Software Products, Inc.
Sorry, bozo, why don't *YOU* shut up! I hope you and your company of
dwarves** never sell that program, and anyone who buys it would be a
fool. Besides Jordan Brown's objections, you are artificially limiting
the password name space. And if such a program became widespread, crackers
could encrypt its output as well as the dictionary. THINK before you
post suggestions about improving security; oftentimes the obvious
solutions actually decrease security instead of improving it.
(Root Boy) Jim Cottrell (301) 975-5688
<r...@nav.icst.nbs.gov> or <r...@icst-cmr.arpa>
Crackers and Worms -- Breakfast of Champions!
** see the phrase I capitalized from his quote
Jonathan Bayer
. > In article <1...@herron.uucp>, jbr...@herron.uucp (Jordan Brown) writes:
. > > jba...@ispi.UUCP writes:
. > > > It is possible to adopt a single system, if that system is random. For
. > > > example, I have included below a random password generating program, ...
.
. > > Somebody go by this fellow's office and look at all the desk blotters and
. > > scraps of paper to find written-down passwords. Then log in and mail him
. > > a note to go watch War Games.
.
. > Instead of being critical without offering suggestions, why don't you
. > shut up?
.
. You may disagree with me on the security of randomly generated passwords,
. but I don't think this tone is reasonable. (At least I don't think my
. comment was this nasty. My apologies if it came across that way.)
.
. > I challenge you to develop a program which will create random passwords
. > which will be easy to remember.
.
. I'm not sure what "easy to remember" means. Enough users have problems
. remembering passwords that *they* picked to make me doubt that any random
. scheme has any chance. I didn't mean to say that *your* random password
. program was bad, but that they *all* are.
.
. I'm not going to try to write a "better" version, as I'm convinced it
. isn't possible to write one "good enough".
.
. Thinking about it, there's another serious problem. If you don't have a
. *very* good seed source, your random passwords are easily guessable.
. (For instance, suppose you use the time in seconds as your source.
. if you know what day the password was assigned, then there are only 86k
. passwords to try. It'll typically take a second or so to try each, so
. about a day of CPU time later... Time in ms would be better, but it is
. still probably practical to observe password changes and search the
. appropriate range of random numbers. Write a program that "watches"
. /etc/passwd and logs username and time when it's updated. Probably
. an adequate solution is to continuously increment a counter while
. waiting for a keystroke. That's pretty close to truly random.)
.
. You presented a "solution" to the problem; I poked what I consider
. to be a gaping hole in it, one that I thought was "well-known"
. (documented in a mainstream motion picture, even).
.
. I hate a flawed solution to a problem more than no solution at all.
. At least when you know there's no solution you aren't deceived.
Your apology is accepted. I continually see comments that probably are
not meant to offend, but since this is a written medium the tone of voice
does not come across. I appreciate your civil reply, as opposed to a
totally bozo response I received by mail. I will not mention the bozo's
name unless he (see, I've given you a hint :-) ) posts his message in
a news group.
BTW, Brandon Allbery posted a program which is 264 lines long (including
comments) which does pretty much what I asked you to do. It was posted
to comp.sources.misc.
I agree that if ONE system becomes universal then it makes life easier
for the crackers. I posted one solution, admittedly a simple one. Brandon
has posted a more sophisticated one. I am sure there are others (one which
crosses my mind is to have the password be two random words, seperated by
a non-character. If the dictionary is big enough then there is a lot of
work for the cracker). The more solutions which are available, both
publicly and privately, the harder it is for the cracker.
For the bozo who likes to call people names, remember that name-calling
is not going to produce any answers. Rather, it makes at least one party
upset and angry, while providing you with, perhaps, momentary pleasure. It
would be better to provide CONSTRUCTIVE critisism (which I will be glad to
take) rather than DESTRUCTIVE critisism (which you are glad to give).
T. William Wells
: In article <2...@twwells.uucp> bi...@twwells.UUCP (T. William Wells) writes:
: > ... lassword ...
:
: Oh, but I can't let you have the lassword!
But I haven't cried `youncall' yet! :-)
: I didn't mean to imply that this approach wasn't viable, but I
: couldn't resist the experiment and thought (since the posted travesty
: program wasn't runnable on anything except MS-DOS) that an illustration
: of what "travesty" produces might be informative to many readers.
I didn't think you were; I was just addressing a valid objection
raised elsewhere about password generators. The travesty program has
the benefit of augmenting its random generator with additional data
that the crasher has to get to before he can crack the password.
This eliminates the problem with a crasher simply running a generator
program through all its possible states.
Eirik Fuller
)
) I was just addressing a valid objection
) raised elsewhere about password generators. The travesty program has
) the benefit of augmenting its random generator with additional data
) that the crasher has to get to before he can crack the password.
)
) This eliminates the problem with a crasher simply running a generator
) program through all its possible states.
Yes, it means he has to guess the meta-password too :-)
If he knows the algorithm for the meta-password, do you choose a
meta-meta-password? How many levels are enough?
If there is no algorithm for the meta-password, it probably comes from
the usual password mechanism, but once the mpw is guessed it gives
uniform (if slow) access to all the passwords. Of course there might
not be a good test for correctness of guesses for the meta-password ...
Then again, I might just be babbling. My own preference for passwords
is to change the algorithm every time I change my password. The set of
mappings from meaningful scraps of information into eight character
gibberish is limited only by imagination, and in a creative, careful
community there will be as many of them as there are accounts.
The real problem with generated passwords is remembering them, not
guessing them.
Brandon S. Allbery
+---------------
Since I seem to have started this thread, let me point out that I never
expected that "pwgen" was perfect. Indeed, the version I posted was only a
first approximation. (I should mention that the phoneme and spelling
databases were culled from a number of comp.unix.wizards articles. ;-)
I'm not going to leave "pwgen" as is; I'm going to experiment with more
phonemes, combinations of same, and random number generation. It was pointed
out to me that my srand() call was fairly easy to predict; true, but it was
just an example; add in such things as a checksum of the contents of the
process table and etc. and it becomes impossible to duplicate the RNG seed
without a snapshot of the entire system at the time the program is run.
Hardware random numbers (i.e. "/dev/static", which is just a A/D converter
attached to a radio receiver tuned to a frequency filled with static ;-) are
another possibility. Not that I can test that last on ncoast.... (Note the
smiley; I can think of a fairly easy way for a hardware hacker to break it,
and a good reason why it wouldn't work anyway. It's just an idea for people
to think about, to get the creative juices flowing. For that matter, so is
pwgen.)
At least one person has expressed a desire to add pwgen to the UN*X his
company is shipping. One word to all who are contemplating this: DON'T.
Pwgen is a first attempt at code to implement an idea; I don't claim it to
be the best way to do it, and it has a number of problems as is. (The
biggest may be the databases. Look at them and tell me how easy it is to
change them, either to add phonemes or spellings or to "nationalize" it.
When I put the databases together I decided that the next upgrade would
include a database generator.) Nor do I claim that the idea itself is in
either a final or a useable form. Pwgen DOES work to some extent, but I'd
hate to see a large number of sites try to base their security on it as is.
Just in case anyone's interested, here's a run of "pwgen 8 96". This was
run on ncoast, with its less-than-useable rand(); I will recompile with
another RNG and see how it affects the output.
(Press "n" if you aren't interested...)
shetheg ehooshi ooreyov uudotush fequasi ifoomih etequam aroochoo
ronuthi phelide ngaehoo ngoomoh ushudath rongovi ipalema uchukoe
tixoora chibith hooburi komoofo koosiqu tingofi soyichoo goothur
soovire epaethoo thidoqu meidong oojaqui uchokix xithabo jogirath
tofiqua nuphadi mooloot jithulu neoouse rofunequ ratheth nerekos
uboroaqu quiloop giligath nofedij yoteeub ooxekam mothoob achaniu
senohev aeboove mebokeu quigooy gujinoo chetone ixoosil ngadeyi
nihochi modaepu peraboth ngitooth hoothoch oudutix ichafea boyothe
joonguf patuxong egooxoo thotahu oosoipe choongi ogootha hiheeip
hogoojee ipaedaa thipair hipusab ehoothae thilise oopuloo isimequ
agiuveb singaab oojasho iyefooj ootuoov thaniay revisai akichoo
vojeting ngiremae rikakee nathehe mithisi beaepin xeruvep ihayouu
I see a few problems in here, like a tendency to overuse "oo"; since "pwgen"
has a few bugs, it'll be interesting to see what happens when I fix them.
My account
A quick and easy way of adding a catch to a common word password is to
imbed a number in it. Such as then password - pencil - when I add the
first 3 numbers of my ssn it becomes - pen040cil - . All I have to do
is remember the password and the numbers and where I decided to place
them in the password. Also it further increases the difficulty of the password
if I spell the result backwards (Drives people who are looking over your
shoulder *NUTS* )
-- John Grzesiak --
Omega Dynamics
47 Spring Street
Wallingford Ct 06492
Opinions expressed are mine and not attributable to any companies
that may employ my services.
"When we are born we cry that we are come , to this great stage of fools"
T. William Wells
: In article <2...@twwells.uucp> bi...@twwells.UUCP (T. William Wells) writes:
: ) I was just addressing a valid objection
: ) raised elsewhere about password generators. The travesty program has
: ) the benefit of augmenting its random generator with additional data
: ) that the crasher has to get to before he can crack the password.
: )
: ) This eliminates the problem with a crasher simply running a generator
: ) program through all its possible states.
:
: Yes, it means he has to guess the meta-password too :-)
Yes, but consider the difficulty the crasher has if he has to guess
say, the contents of some random read protected file plus some random
dictionary? I keep a copy of my incoming and outgoing mail and
interesting news messages in a protected directory; it amounts to
several megabytes. Imagine a crasher trying to figure out the
probabilities from that!
Not only that, but it changes all the time; in order to use this
information to work on my password, he'd have to snarf the data at
the time I changed the password.
And it'd be of no use to him the next time I changed my password.
: The real problem with generated passwords is remembering them, not
: guessing them.
Well, the point of this discussion is how to create a reasonably
crasher-proof password generator that also creates passwords that can
be reasonably easily remembered.
John Chambers
> >mouse-oriented tools for deleting files &c. Giving people an easy way of
> >deleting files by clicking on an icon makes thing safer for them without
> >taking anything at all away. Emacs "DIRED" mode is the same kind of
> >safety-through-convenience approach.
>
> Coming closer! That's my idea of a user-friendly interface. An "undo"
> operation should be an essential part of the user interface... but that
> will remain utopical for most UNIX systems for the time being, I am afraid.
> (why not use a LISP machine :-) ).
>
Oh, I don't know about that; I recall 'way back when I first stumbled across
Unix, after having worked on N other commercial systems. When I found that
the rm command just did what I told it and didn't complain, my reaction was
"Wow, this is really a nice, friendly system!" But in the years since then,
Unix has gotten less and less friendly to me, because people think I'm too
stupid to think before hitting <RETURN>, and they add "features" such as
checks to rm. So now I find myself doing things like:
rm aud/*
^C
rm -f aud/*
while thinking many unprintable thoughts about the @#$^% idiots who would
do such a thing and cause me to waste my time with such silliness.
The real solution is: People who can't handle commands like rm shouldn't
have /bin in their search path. Even better, vendors should supply them
with tools like mice and menus, and not bother holding the hands of those
users that like simple, direct, powerful tools.
Unix has a perfectly good mechanism for providing different users with
different interfaces. Why not use it?
[No, I've never typed "rm * .o", or at least I've never hit <RETURN> after
such a typo. My right little finger tends to delay automatically when it
knows I've typed a possibly dangerous command, to give my brain time to
think about it.]
--
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)
[Any errors in the above are due to failures in the logic of the keyboard,
not in the fingers that did the typing.]
john richardson
>In article <14...@unisoft.UUCP> grey...@unisoft.UUCP (The Grey Wolf) writes:
>
>>If you're going to write a csh script,
>>you're better off prefacing it with the line
>>#!/bin/csh -f
>
>Indeed you are. You're even better off not writing Csh scripts.
and then...
>Well, everything is subject to debate.
Has there been a past discussion of writing scripts for csh vs. sh?
I see some advantages both ways:
CSH:
2X faster (on the only benchmark we attempted)
more builtins, less process generation (i.e., test, basename)
:r,:e,:t suffixes to variables
we are committed to Berkeley software so csh is portable enough
I use csh for interactive work
SH:
trap statement
"| while read x" construct
easy stderr redirection
portable to Berkeley and ATT installations
John Richardson
jr...@devnet4.hac.com
Hughes Aircraft Company, Fullerton, Ca.
(714) 732-5588
Subject to the usual disclaimers as well as
all failings normally associated with the efforts of man.