Re: Aliases

2001-11-27 Thread James R. Van Zandt



Benjamin Scott [EMAIL PROTECTED] wrote:

  Aliases are not the problem.  The problem is aliasing commands *for
someone else*.  If I alias 'ls' to 'rm -rf .', then that is my own
business, and presumably I have a reason.  It is things like Unix and
Linux distro vendors setting up default aliases which gets people
into trouble.

I'll second this.

I remember in my early Unix days having trouble with the man
command.  I read its manpage and set up MANPATH to point to a new
collection of man pages, but it was ignored.  which man confirmed I
was invoking the right program.  Eventually I discovered that some
helpful soul had set up 

alias man man -M /some/path

and the command line option overrides the environment variable.

That's the reason I now use type -a instead of which.

   - Jim Van Zandt

*
To unsubscribe from this list, send mail to [EMAIL PROTECTED]
with the text 'unsubscribe gnhlug' in the message body.
*



Re: Aliases

2001-11-26 Thread Ken Ambrose

Ben Scott Scribed:

   Aliases are not the problem.  The problem is aliasing commands *for
 someone else*.  If I alias 'ls' to 'rm -rf .', then that is my own business,
 and presumably I have a reason.  It is things like Unix and Linux distro
 vendors setting up default aliases which gets people into trouble.  I
 think that is a bad idea, for all the reasons Paul brings up, and wish
 vendors would not engage in the practice.

Hmmm.  A point all of you are making is how bad RH is for aliasing rm -i
because it gets you used to it.  Well... they don't.  Except as root.  You
guys aren't running as root all the time, are you? ;-)  That would be yet
another bad thing (YABT).  I happen to think it's handy to have rm, when
root, changed to rm -i: that way, when I spend the bulk of my time as
Joe User, rm works as God intended it, but those times when you run the
possibility of having too much power, it's handy to be forced to think
things through.  And, since it's the exception, and not the rule, it's not
like your fingers get used to it.

/devil's advocate

-Ken


*
To unsubscribe from this list, send mail to [EMAIL PROTECTED]
with the text 'unsubscribe gnhlug' in the message body.
*



Re: Aliases

2001-11-26 Thread Bill Mullen

On Mon, 26 Nov 2001, Derek D. Martin wrote:

snip

 I will point out that, as with virtually all things, It Depends(tm).
 For the average user, being root all the time is an extremely bad
 idea.  But I'm a system administrator...  the vast majority of what I
 do NEEDS to be done as root.  So I am root most of the time...  Of
 course I don't log in as root, and I maintain seperate xterms (which
 are different colors usually) in different desktops for being root, so
 that it's hard to mistake being root for being a regular user...

 Blanket statements are always wrong...  ;-)

Along these lines, I have the following in /etc/bashrc to colorize my
prompts, and ensure that if I am root, either as a login or via an su, my
prompt becomes a distinctive white on red:


if [ $SHLVL = 1 ] ; then
COLOUR=44  # blue
else
COLOUR=45  # magenta
fi

if [ $UID = 0 ] ; then
COLOUR=41  # red
fi

ESC=\033
STYLE=';1m'  # bold
#STYLE='m'# plain
export PS1=\[$ESC[$COLOUR;37$STYLE\]\u@\h:\[$ESC[m\]\w\\$ 
export PS2= 

This also colorizes the prompt in login shells (other than root's) to
white on blue, and in all subsidiary shells (other than root's) to white
on magenta. Handy to know when one more Ctrl-D will log you out. :)

-- 

Bill Mullen
[EMAIL PROTECTED]
Nov 26, 2001


*
To unsubscribe from this list, send mail to [EMAIL PROTECTED]
with the text 'unsubscribe gnhlug' in the message body.
*



Re: Aliases

2001-11-26 Thread Steven W. Orr

On Mon, 26 Nov 2001, Bill Mullen wrote:

=Along these lines, I have the following in /etc/bashrc to colorize my
=prompts, and ensure that if I am root, either as a login or via an su, my
=prompt becomes a distinctive white on red:
=
=
=if [ $SHLVL = 1 ] ; then
=COLOUR=44  # blue
=else
=COLOUR=45  # magenta
=fi
=
=if [ $UID = 0 ] ; then
=COLOUR=41  # red
=fi
=
=ESC=\033
=STYLE=';1m'  # bold
=#STYLE='m'# plain
=export PS1=\[$ESC[$COLOUR;37$STYLE\]\u@\h:\[$ESC[m\]\w\\$ 
=export PS2= 
=
=This also colorizes the prompt in login shells (other than root's) to
=white on blue, and in all subsidiary shells (other than root's) to white
=on magenta. Handy to know when one more Ctrl-D will log you out. :)
=
Or you can do what I do:

ignoreeof=3

into your .bash_profile

-- 
-Time flies like the wind. Fruit flies like a banana. Stranger things have -
-happened but none stranger than this. Does your driver's license say Organ
-Donor?Black holes are where God divided by zero. Listen to me! We are all-
-individuals! What if this weren't a hypothetical question? [EMAIL PROTECTED]



*
To unsubscribe from this list, send mail to [EMAIL PROTECTED]
with the text 'unsubscribe gnhlug' in the message body.
*



Re: Vendor defaults (was: Aliases) (was: Compression under ...)

2001-11-26 Thread Paul Lussier


In a message dated: Mon, 26 Nov 2001 18:32:26 EST
Benjamin Scott said:

...and for any given option, there has to be a default.

  Where do we draw the line?

How about at a blank .bashrc/.profile and leaving commands acting the 
way they were meant to out of the box?  Is that really too much to 
ask?

At the very least, if you want the user to know about possible
enhancements comment them out in the files with appropriate warnings
in place.


*
To unsubscribe from this list, send mail to [EMAIL PROTECTED]
with the text 'unsubscribe gnhlug' in the message body.
*



Re: Vendor defaults (was: Aliases) (was: Compression under ...)

2001-11-26 Thread Benjamin Scott

On Mon, 26 Nov 2001, Paul Lussier wrote:
 How about at a blank .bashrc/.profile ...

  Most of this stuff is actually set in /etc/profile and friends.  But even
if you include those, you run into other problems.  What about PATH?  MAIL?
What about locale settings?  The occasional program that requires some kind
of user environment setup?

 ... and leaving commands acting the way they were meant to out of the
 box?

  But who gets to decide how they were meant to act?  I mean, sure, with the
case of ls, color is off by default.  That one is easy.  But what about,
say, KDE?  How was that meant to act out of the box?

 At the very least, if you want the user to know about possible
 enhancements comment them out in the files with appropriate warnings
 in place.

  Documentation from distro vendors about what they do would certainly be
nice.  But that is a whole 'nother thread!  :-)

-- 
Ben Scott [EMAIL PROTECTED]
| The opinions expressed in this message are those of the author and do not |
| necessarily represent the views or policy of any other person, entity or  |
| organization.  All information is provided without warranty of any kind.  |


*
To unsubscribe from this list, send mail to [EMAIL PROTECTED]
with the text 'unsubscribe gnhlug' in the message body.
*



Re: Vendor defaults (was: Aliases) (was: Compression under ...)

2001-11-26 Thread Paul Lussier


In a message dated: Mon, 26 Nov 2001 19:24:10 EST
Benjamin Scott said:

On Mon, 26 Nov 2001, Paul Lussier wrote:
 How about at a blank .bashrc/.profile ...

  Most of this stuff is actually set in /etc/profile and friends.  But even
if you include those, you run into other problems.  What about PATH?  MAIL?
What about locale settings?  The occasional program that requires some kind
of user environment setup?

Sure, for path you include only those directories which contain 
executable files; i.e., anything ending in /bin is a decent start.  
Which brings up another really good point.  Why is it that RH 
*ALWAYS* leaves /sbin out of the /etc/profile?  That's ridiculous and 
a royal and annoying P.I.T.A.!!!  But I digress :)

What do you need a MAIL variable for?  If you discover you need one, 
set it.  Locale?  I'll let Derek answer that one, though in general, 
the default is usually C, which is fine, if you don't like it, change 
it.

 ... and leaving commands acting the way they were meant to out of the
 box?

  But who gets to decide how they were meant to act?  I mean, sure, with the
case of ls, color is off by default.  That one is easy.

I'm strictly talking about shell level commands here, nothing more.  

 But what about, say, KDE?  How was that meant to act out of the box?

It was meant to act easily replaceable by fvwm :)

  Documentation from distro vendors about what they do would certainly be
nice.  But that is a whole 'nother thread!  :-)

Too true :)  Let's save that one for tomorrow :)


*
To unsubscribe from this list, send mail to [EMAIL PROTECTED]
with the text 'unsubscribe gnhlug' in the message body.
*



Re: Aliases

2001-11-25 Thread Paul Lussier


In a message dated: Sun, 25 Nov 2001 20:40:19 EST
Benjamin Scott said:

 This would completely mess up things like:

$ for i in `ls /some/long/path`
 do
  cp $i ${i}.bak
  cp /some/long/path/$i .
 done

  Oh, and BTW:

   for i in /some/long/path/*

makes a lot more sense.  :-)

It was a brief example so I didn't have to type too much.  I usually 
do things like:

for i in `ls -lrt /some/long/path | grep 'Nov 25' | awk '{print `$9'
do
  some stuff here
done.

  If someone is that clueless, I doubt they will have the ability to create
the alias in the first place.

Go to any large Unix-based engineering environment and you'll find 
loads of people who all pass around their .cshrc files and don't have 
one clue what 99% of what's in them does or where it comes from.

  Aliases are not the problem.  The problem is aliasing commands *for
someone else*.  If I alias 'ls' to 'rm -rf .', then that is my own business,
and presumably I have a reason.  It is things like Unix and Linux distro
vendors setting up default aliases which gets people into trouble.  I
think that is a bad idea, for all the reasons Paul brings up, and wish
vendors would not engage in the practice.

  Is that what you are trying to say?  :-)

Yeah, but it's so much shorter to say:

I don't like aliases, don't use them! :)

 People in general never comment them ...

  I comment mine.  :-) 

You're not People in general... :)  As a matter of fact, you're not 
even People in private ;)

 And, in fact, for the same reason we are having this
conversation.  People sometimes find useful things in others' aliases; I
want them to know what is going on, not just copy a set of magic runes.

Well Ben, as Derek and I have said more times than I can count:

If more people were like us, this world would be a much 
better place!

Of course, we'd all be bored, since we'd then have nothing to bitch 
about :)

 You wouldn't catch a carpenter who didn't know all the ins and outs of
 his skill or miter saw ...

You also won't find a carpenter who insists on using hand tools for
building a house when power tools make the job ten times faster.  :-)

Damn!  No wonder my house still isn't finished ;)


*
To unsubscribe from this list, send mail to [EMAIL PROTECTED]
with the text 'unsubscribe gnhlug' in the message body.
*



Re: email aliases??

2000-03-09 Thread Charles C. Bennett, Jr.

 I add the line   helpme:   name1, name2, name3, to /etc/aliases  and
 run new aliases and I see the number of alisese change, but the messages
 do not move to the aliases users.

/etc/rc.d/init.d/sendmail restart

ccb


--
Charles C. Bennett, Jr. VA LiNUX Systems
Systems Engineer, Northeast US  25 Burlington Mall Rd., Suite 300
+1 617 543-6513 Burlington, MA 01803-4145
+1 888 LiNUX-4-U x 5738 +1 888 LiNUX-4-U
[EMAIL PROTECTED] www.valinux.com

You can't legislate Mathematics.

**
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**