HDTenEightyP/NetNews huggingface dataset:
From: ckd@eff.org (Christopher Davis)
Subject: Re: Epoch client/server
Organization: Electronic Frontier Foundation Tech Central
Date: Wed, 29 Jul 1992 20:31:59 GMT

Narayanan> == Narayanan Shadagopan <shadagop@central.rutgers.edu> 

 Narayanan> 	However, I do not want many instances of Epoch starting
 Narayanan> up. Rather, every time I call Epoch, I want to connect to
 Narayanan> one Epoch 'server' (for obvious reasons, I don't want all
 Narayanan> the functions in my .emacs starting over and over again. I
 Narayanan> just want one screen.) Is there such a thing as Epoch
 Narayanan> client/server? Is this the idea behind emacsclient?

Yes, though I recommend the gnuserv/gnuclient stuff from Andy Norman.
(For security's sake, disable the TCP/IP connection stuff, though...)

Available at your friendly neighborhood archive site; ask archie.
--
Christopher Davis * ckd@eff.org * System Administrator, EFF * +1 617 864 0665
   ``The First Amendment is often inconvenient.  But that is besides the
  point.  Inconvenience does not absolve the government of its obligation
         to tolerate speech.'' --Justice Anthony Kennedy, in 91-155
Newsgroups: gnu.epoch.misc
From: jerry@math.ep.utexas.EDU (Jerry)
Subject: Re: Cut&Paste to OpenWindows
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 31 Jul 1992 18:19:57 GMT

Ulf Westermark Tph on July 31 wrote:
-> I have been happily been using Epoch 4.0p2 for a while. I'm running it
-> on a SparcStation with SunOS 4.1.1 and OpenWindows 3.
-> 
-> This might bee a silly question, but I have problems with doing
-> copy&paste from Epoch to OpenWindows-programs such as shelltool and
-> cmdtool. Copying information from shelltool to Epoch works fine.

Put the following in your ../epoch-lisp/site-init.el file:

(epoch-add-setup-hook
 '(lamda ()
	 (setq mouse::selection-atom (intern-atom "CLIPBOARD"))))

and rebuild epoch.  Alternatively, just put

(if (boundp 'epoch::version)
    (setq mouse::selection-atom (intern-atom "CLIPBOARD")))

in your ~/.emacs.

-Jerry

P.S.--Lose the giant .sig....
Newsgroups: gnu.bash.bug
From: chet@odin.ins.cwru.edu (Chet Ramey)
Subject: Re: builtin test -w unaware of group permissions
Reply-To: chet@po.cwru.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 27 Jul 1992 05:17:38 GMT

> It seems Bash's builtin "test" command didn't know that I could write
> a file based on group permissions, whereas all the other "test"
> commands I could find worked OK.

This is a problem with SunOS for which bash 1.12 does not have a correct
workaround.  SunOS 4.1.x is (nominally) a Posix system, so bash uses the
Posix.1 types uid_t and gid_t.  Groups in SunOS when using the (default)
BSD includes and libraries are int everywhere but in the stat structure,
where they are gid_t.

The Sun getgroups(2) actually takes and returns an array of int rather than
gid_t, but bash was following Posix.1 and calling with an array of gid_t. 
Since gid_t is unsigned short, the values returned in the array were
garbage. 

Bash 1.13 should do this correctly.

Chet

--
``The use of history as therapy means the corruption of history as history.''
	-- Arthur Schlesinger

Chet Ramey, Case Western Reserve University	Internet: chet@po.CWRU.Edu

Newsgroups: gnu.bash.bug
From: chip@tct.COM (Chip Salzenberg)
Subject: Re: rsh, rcp with bash
Organization: TC Telemanagement, Clearwater, FL
Distribution: gnu
Date: Wed, 29 Jul 1992 12:41:34 GMT

According to chet@po.cwru.edu:
>Bash attempts to source the .bashrc for non-interactive shells running
>rsh and rcp so things like $PATH get set.

... which is, in my opinion, a BIG mistake.

Thus the following patch to Bash 1.12 to eliminate that behavior:

Index: shell.c
***************
*** 567,572 ****
--- 575,585 ----
  	 bash foo		NO
  	 foo			NO
+ #if BUGGY_DASH_C
  	 rsh machine ls		YES (for rsh, which calls `bash -c')
  	 rsh machine foo	YES (for shell started by rsh) NO (for foo!)
+ #else
+ 	 rsh machine ls		NO
+ 	 rsh machine foo	NO
+ #endif
  	 echo ls | bash		NO
  	 login			YES
***************
*** 574,580 ****
        */
        if (!act_like_sh && !no_rc &&
! 	  (interactive_shell || (!isatty (fileno (stdin)) &&
! 				 local_pending_command)))
! 	maybe_execute_file (bashrc_file);
  
        /* Try a TMB suggestion.  If running a script, then execute the
--- 587,602 ----
        */
        if (!act_like_sh && !no_rc &&
! 	  (interactive_shell
! #if BUGGY_DASH_C
! 	   /* I'm sorry, but Brian Fox is just plain wrong here.
! 	      He'd like to read .bashrc on "rsh host ls", but I
! 	      can't support the weirdness it requires.  --Chip */
! 	   || (!isatty (fileno (stdin)) && local_pending_command)
! #endif
! 	   ))
! 	{
! 	  maybe_execute_file (global_bashrc_file);
! 	  maybe_execute_file (bashrc_file);
! 	}
  
        /* Try a TMB suggestion.  If running a script, then execute the

-- 
Chip Salzenberg at Teltronics/TCT  <chip@tct.com>, <73717.366@compuserve.com>
   "Do Rush place weird subliminal backmasked messages in their songs to
 compel unwilling geeks to commit evil .sig atrocities?"  -- Dean Engelhardt

Newsgroups: gnu.bash.bug
From: chet@odin.ins.cwru.edu (Chet Ramey)
Subject: Re: rsh, rcp with bash
Reply-To: chet@po.cwru.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 24 Jul 1992 04:36:22 GMT

> I wonder whether this problem has been beaten to death in this group 
> before.  I use bash 1.12.1  as login shell on my machines (Sun Sparcs 
> running SunOS 4.1.1) and having problem with rsh and rcp. The symptoms
> are as follows:
> 
>     host1>  rcp localfile host2:remotefile
>     stty: TCGETS: Operation not supported on socket
>     host1>  rsh host2 ls
>     stty: TCGETS: Operation not supported on socket

I'll bet you have something that does output or manipulates the terminal
state in your .bashrc.  Bash attempts to source the .bashrc for non-
interactive shells running rsh and rcp so things like $PATH get set.

What you should probably do is to make your .bashrc look like this:

unset INTERACTIVE
case "$-" in
*i*)	INTERACTIVE=on ;;
esac

... initialization for all shells, interactive or not ...

if [ -z "$INTERACTIVE" ]; then
	return
fi

... initialization for all interactive shells ...

Chet

--
``The use of history as therapy means the corruption of history as history.''
	-- Arthur Schlesinger

Chet Ramey, Case Western Reserve University	Internet: chet@po.CWRU.Edu

Newsgroups: gnu.bash.bug
From: chet@odin.ins.cwru.edu (Chet Ramey)
Subject: Re: problem with bash 1.12.1 w/ trap
Reply-To: chet@po.cwru.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 27 Jul 1992 03:52:17 GMT

> Currently, I cannot get scripts with trap in them to work correctly
> under bash version 1.12.1.

I rewrote the trap and signal handling code for the next version, which
should correct many of the bugs people have found.

>   delay=6
>   trap 'trap 14' 14
>   echo "What is your Quest? \c"
>   (sleep $delay; kill -14 $$ 2>/dev/null)&
>   read YourQuest
>   kill $! 2>/dev/null
>   [ ! -z "$YourQuest" ] && echo "Bah. Humbug. Not interested in $YourQuest" \
>                         || echo "You must be interested in something!"

You're expecting the SIGALRM to interrupt the read, I'm sure.  It doesn't
do so on BSD systems.  On my SunOS 4.1.2 systems, after changing the above
trap command to `trap "echo 14 ; trap 14" 14', I found that out of bash,
ksh-88, /bin/sh, ash, the new BSD sh, and zsh, only bash and zsh even
printed the `14'.  None of those shells let the SIGALRM interrupt the
`read'.

>   PATH=/bin:/usr/bin
>   trap "" 1 2 3 4 5 6 7 8 '9' 10 11 12 13 14 15 16 17 18 \
>                   19 20 21 22 23 24 25 26 27 28 29 30 31
>   set - $(who am i)
>   echo $1

The specific problem with this script is that you've told bash to ignore
SIGCHLD, and version 1.12 does not handle that correctly.  (It sets the
SIGCHLD handler to SIG_IGN in the child shell created to run the command
substitution, and that shell never reaps the `who' and exits.)

Chet

--
``The use of history as therapy means the corruption of history as history.''
	-- Arthur Schlesinger

Chet Ramey, Case Western Reserve University	Internet: chet@po.CWRU.Edu

Newsgroups: gnu.bash.bug
From: ktm@oort.cs.rice.edu (Ken Marshall)
Subject: problem with bash 1.12.1 w/ trap
Summary: bash does not handle traps correctly.
Keywords: bash, traps
Organization: Rice University, Houston, Texas
Distribution: gnu
Date: Fri, 24 Jul 1992 17:39:06 GMT

Currently, I cannot get scripts with trap in them to work correctly
under bash version 1.12.1.  Here is a simple delay script that does
not work:

  delay=6
  trap 'trap 14' 14
  echo "What is your Quest? \c"
  (sleep $delay; kill -14 $$ 2>/dev/null)&
  read YourQuest
  kill $! 2>/dev/null
  [ ! -z "$YourQuest" ] && echo "Bah. Humbug. Not interested in $YourQuest" \
                        || echo "You must be interested in something!"

Similarly, the following script hangs at the "who am i" if the trap line
is there.  If the trap line is commented out, the scripts runs to completion.

  PATH=/bin:/usr/bin
  trap "" 1 2 3 4 5 6 7 8 '9' 10 11 12 13 14 15 16 17 18 \
                  19 20 21 22 23 24 25 26 27 28 29 30 31
  set - $(who am i)
  echo $1

Does anyone know of any patches for bash's signal handling code?
Thank you.

--Ken

Newsgroups: gnu.bash.bug
From: chanoh@ccwf.cc.utexas.edu (Chanhee Oh)
Subject: rsh, rcp with bash
Reply-To: chanoh@ccwf.cc.utexas.edu (Chanhee Oh)
Organization: The University of Texas at Austin, Austin TX
Distribution: gnu
Date: Wed, 22 Jul 1992 16:45:43 GMT

Hi folks,

I wonder whether this problem has been beaten to death in this group 
before.  I use bash 1.12.1  as login shell on my machines (Sun Sparcs 
running SunOS 4.1.1) and having problem with rsh and rcp. The symptoms
are as follows:

    host1>  rcp localfile host2:remotefile
    stty: TCGETS: Operation not supported on socket
    host1>  rsh host2 ls
    stty: TCGETS: Operation not supported on socket

I'd appreciate any experience of other netters regarding this problem.
I am getting tired of using ftp everytime I need to transfer files.
Thanks in advance.

Chanhee Oh
-- 
==================================================================
 Chanhee Oh 		         Dept. Electrical & Comp. Eng.
 chanoh@ccwf.cc.utexas.edu       The Univ of Texas at Austin
==================================================================

Newsgroups: gnu.bash.bug
From: freeman@devon.prepnet.com (Jon Freeman)
Subject: Bug in Bash 1.12
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 27 Jul 1992 21:24:49 GMT

In Bash 1.12, the file general.h contains the following statement:

#if !defined (__STDC__)
char *index (), *rindex ();
#endif

On an RS6000 running AIX 3.2, however, the symbol __STDC__ is not
defined but index and rindex are defined in /usr/include/string.h.
This leads to a fatal error, either with or without full prototypes.

				Jon
				(freeman@devon.prepnet.com)

Newsgroups: gnu.bash.bug
From: bjornw@colargol.edb.tih.no (Bjoern Wennberg)
Subject: bug or feature with 'type' command ?
Organization: Colargol, Trondheim College of Engineering
Distribution: gnu
Date: Thu, 23 Jul 1992 13:36:19 GMT

Hi!

What should the 'type' command display ?
When I do 'type -all man' I get
man is aliased to `bman'
man is ./man
       ^^^^^
This is a directory and shouldn't be displayed according to the 
documentation of 'type'. The 'help type' says:

    If the -all flag is used, displays all of the places that contain an
    executable named `file'.  This includes aliases and functions, if and
    only if the -path flag is not also used.

Is this correct?

bjornw>

bjornw@colargol.edb.tih.no


Newsgroups: gnu.bash.bug
From: Dan_Jacobson@att.com
Subject: builtin test -w unaware of group permissions
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 25 Jul 1992 00:10:00 GMT

It seems Bash's builtin "test" command didn't know that I could write
a file based on group permissions, whereas all the other "test"
commands I could find worked OK.

SunOS Release 4.1.2  BASH_VERSION=1.12.1
bash$ ls -lg music.cal
-rw-rw-r--  1 pwyc     rnd          4284 Jul 24 16:35 music.cal
bash$ id
uid=47941(danj1) gid=47941(danj1) groups=47941(danj1),34718(rnd)
bash$ touch music.cal
bash$ ls -lg music.cal
-rw-rw-r--  1 pwyc     rnd          4284 Jul 24 18:54 music.cal
bash$ test -w music.cal && echo writeable
bash$ /bin/test -w music.cal && echo writeable
writeable
bash$ type test
test is a shell builtin
bash$ ksh
$ type test
test is a shell builtin
$ test -w music.cal && echo ksh says writeable
ksh says writeable
$ sh
$ test -w music.cal&& echo sh too
sh too
$ type test
test is a shell builtin
$ csh
ihspa% if (-w music.cal) echo ooooo
ooooo

Newsgroups: gnu.bash.bug
From: jjd@spserv.bbn.com (James J Dempsey)
Subject: Re: rsh, rcp with bash
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 30 Jul 1992 13:31:35 GMT

> According to chet@po.cwru.edu:
> >Bash attempts to source the .bashrc for non-interactive shells running
> >rsh and rcp so things like $PATH get set.
> 
> ... which is, in my opinion, a BIG mistake.
> 
> Thus the following patch to Bash 1.12 to eliminate that behavior:

I strongly disagree with you.

Rsh is almost useless to me if I can't get my shell to run some init
file to set PATH and other environment variables.

If you disable bash from running an init file, there is no way to get
the behaviour I want.

If you leave it the way it is, you can get the behaviour you want
in non-interactive mode by wrapping 

if [ "$PS1" ]; then

< your entire .bashrc >

fi

around your entire init file.


Shells like sh and ksh that don't run any init file are really useless
to me.  Shells like tcsh, bash and csh do the right thing, IMHO.

Given that this is such a religious issue, it seems best to leave it
the way it is.  This way either methodology can be implemented in the
.bashrc file.  Changing it to not source .bashrc leaves many of us out
in the cold.

		--Jim Dempsey--
		jjd@bbn.com

Newsgroups: gnu.bash.bug
From: chet@odin.ins.cwru.edu (Chet Ramey)
Subject: Re: ! history expansion problems
Reply-To: chet@po.cwru.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 27 Jul 1992 03:50:48 GMT

> How can I disable csh-style history expansion within shell character classes?
> For example:
> 
> 	cp ../skeleton/.[!.]* .
> 
> to set up a user's account.
> 
> As ! here indicates inversion of the character class, I think it
> should be added to the set of special cases where it is not expanded
> as history.

You can use ^ in place of ! to indicate character class inversion.

Chet

--
``The use of history as therapy means the corruption of history as history.''
	-- Arthur Schlesinger

Chet Ramey, Case Western Reserve University	Internet: chet@po.CWRU.Edu

Newsgroups: gnu.bash.bug
From: tuppa@eued50.tuwien.ac.at (Walter Tuppa)
Subject: ulimit -c 0 for HP (hack, useful)
Organization: Technical University of Vienna
Distribution: gnu
Date: Tue, 28 Jul 1992 09:39:02 GMT

Hello,

I just saw in another group, that HP/UX supports all calls for setting all
types of BSD like limits, like ulimit -c 0, which is very important if you
don't like any COREs. here my patch:

please apply in the bash-1.12/builtins directory
====================== cut here =============================================
*** ulimit.def.org      Tue Jan 21 06:01:35 1992
--- ulimit.def  Tue Jul 28 10:21:10 1992
***************
*** 75,78 ****
--- 75,91 ----
  #  undef HAVE_RESOURCE
  #endif
+ #ifdef HPUX_70
+ /* don't know HPUX 7.xx but HPUX_8.0 has it */
+ #include <sys/resource.h>
+ /* since this is only included in -D_KERNEL, it's copied to here. */
+ #define HAVE_RESOURCE
+
+ #define       RLIMIT_CPU      0               /* cpu time in milliseconds */
+ #define       RLIMIT_FSIZE    1               /* maximum file size */
+ #define       RLIMIT_DATA     2               /* data size */
+ #define       RLIMIT_STACK    3               /* stack size */
+ #define       RLIMIT_CORE     4               /* core file size */
+ #define       RLIMIT_RSS      5               /* resident set size */
+ #endif /* HPUX_70

  /* **************************************************************** */
====================== cut here =============================================

I know it's dirty, but it is very useful to us.

--
============================================================================
Walter Tuppa	Inst. for MicroElectronics, Technical University of Vienna
		Gusshausstrasse 27-29 / 1040 Vienna / AUSTRIA

E-Mail:		tuppa@iue.tuwien.ac.at
Phone:		+43/1/58801-3713
Fax:		+43/1/5059224
============================================================================

Newsgroups: gnu.bash.bug
From: chet@odin.ins.cwru.edu (Chet Ramey)
Subject: Re: Bug in Bash 1.12.1
Reply-To: chet@po.cwru.edu
Organization: Gnus Not Usenet
Distribution: gnu
Date: Mon, 27 Jul 1992 10:29:55 GMT

> I seem to have found a bug in Bash.
> 
> How to cause the bug to appear:
> 1) Start a long username-completion, e.g.
>       cat ~user<TAB>
>    Let it run for a while (don't know exactly how long...)
>    Before it's finished, hit ^C (or whatever the break character
>    is set to)
> 2) As the next command, run a filename completion with a username in it, eg.
>       cat ~username/.log<TAB>
> 
> Error message:  "free: Called with already freed block argument

This is a bug in the Sun YP code that everyone seems to have picked up.

Sun keeps static state in the YP library code -- a pointer into the
data returned from the server.  When YP initializes itself (setpwent),
it looks at this pointer and calls free on it if it's non-null.  So far,
so good.

If one of the YP functions is interrupted during getpwent (the exact function
is interpretwithsave()), and returns NULL, the pointer is freed without being
reset to NULL, and the function returns.  The next time getpwent is called,
it sees that this pointer is non-null, calls free, and the Gnu free()
blows up because it's being asked to free freed memory.

The traditional Unix mallocs allow memory to be freed multiple times; that's
probably why this has never been fixed.  You can probably stop it by adding
an #undef USE_GNU_MALLOC to the appropriate machine description in machines.h.

Chet

--
``The use of history as therapy means the corruption of history as history.''
	-- Arthur Schlesinger

Chet Ramey, Case Western Reserve University	Internet: chet@po.CWRU.Edu

Newsgroups: gnu.bash.bug
From: idf@cs.bham.ac.UK (Ian Fitchet)
Subject: Re: rsh, rcp with bash
Organization: School of Computer Science, University of Birmingham
Distribution: gnu
Date: Sun, 26 Jul 1992 16:20:56 GMT

On 24 Jul 92 04:36:22 GMT, Chet Ramey wrote

> I wonder whether this problem has been beaten to death in this group 
> before.  I use bash 1.12.1  as login shell on my machines (Sun Sparcs 
> running SunOS 4.1.1) and having problem with rsh and rcp. The symptoms
> are as follows:
> 
>     host1>  rcp localfile host2:remotefile
>     stty: TCGETS: Operation not supported on socket
>     host1>  rsh host2 ls
>     stty: TCGETS: Operation not supported on socket

Chet> I'll bet you have something that does output or manipulates the terminal
Chet> state in your .bashrc.  Bash attempts to source the .bashrc for non-
Chet> interactive shells running rsh and rcp so things like $PATH get set.

 Exactly.  I had for ages the same error message popping up
(I remember it particularly when using shell-command in Emacs) and
after much grief, especially when crypting files as the error message
appeared in the file, I realised I had

stty pass8 ;

 in my .bashrc so I could use the META keys.  I now avoid it by doing:

if [ -n "$-" ] ; then
	stty pass8 ;
fi

 which "tests" for `i' for interactive in $- (the current bash flags)
which thanks to Chet I now realise is a *bit* flaky - I always wanted
to know how to test for an individual flag :-)

 I may be an idiot, but I'm happy.



--
Cheers,

	Ian

-------------------------------------------------------------------------------
Ian Fitchet     				      I.D.Fitchet@cs.bham.ac.uk
School of Computer Science
Univ. of Birmingham, UK, B15 2TT

Newsgroups: gnu.bash.bug
From: chet@odin.ins.cwru.edu (Chet Ramey)
Subject: Re: bug or feature with 'type' command ?
Reply-To: chet@po.cwru.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 24 Jul 1992 04:43:38 GMT

> Hi!
> 
> What should the 'type' command display ?
> When I do 'type -all man' I get
> man is aliased to `bman'
> man is ./man
>        ^^^^^
> This is a directory and shouldn't be displayed according to the 
> documentation of 'type'.

This has already been fixed for the next version of bash.

Chet

--
``The use of history as therapy means the corruption of history as history.''
	-- Arthur Schlesinger

Chet Ramey, Case Western Reserve University	Internet: chet@po.CWRU.Edu

Newsgroups: gnu.bash.bug
From: Mark.Bush@prg.ox.ac.UK (Mark Bush)
Subject: Re: rsh, rcp with bash
Organization: Oxford University Computing Laboratory
Distribution: gnu
Date: Thu, 30 Jul 1992 11:19:31 GMT

In article <2A7691FE.7354@tct.com> chip@tct.COM (Chip Salzenberg) writes:
#According to chet@po.cwru.edu:
#>Bash attempts to source the .bashrc for non-interactive shells running
#>rsh and rcp so things like $PATH get set.
#
#... which is, in my opinion, a BIG mistake.

Why is this a BIG mistake?  If this behaviour isn't the default and I want
it to happen, I have to mess with various things to get my .bashrc sourced.

If the .bashrc is known to be sourced, I can do things like checking PS1 to
see if I am interactive.

If I run `rsh host ls', then I want to know which `ls' I am running by
getting *my* PATH at the remote end.

Mark

Newsgroups: gnu.bash.bug
From: eyvind.ness@hrp.NO (Eyvind Ness)
Subject: rsh, rcp with bash
Reply-To: Eyvind.Ness@hrp.no
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 30 Jul 1992 06:30:00 GMT

  | Date: Wed, 29 July 1992, 12:41 GMT
  | From: Chip Salzenberg
  |
  | According to chet@po.cwru.edu:
  | >Bash attempts to source the .bashrc for non-interactive shells running
  | >rsh and rcp so things like $PATH get set.
  | 
  | ... which is, in my opinion, a BIG mistake.

I agree. But why don't you just put:

    if tty -s
    then
	....

at the head of your .bashrc? This should block any Bash attempts to read
the rest of ~/.bashrc when there is no terminal associated with your
Bash-process.

Eyvind.

Newsgroups: gnu.bash.bug
From: rod@ccwf.cc.utexas.edu (alan da wicked)
Subject: Re: bug or feature with 'type' command ?
Organization: The University of Texas at Austin
Distribution: gnu
Date: Sun, 26 Jul 1992 08:28:52 GMT

In article <1992Jul23.133619.4012@ugle.unit.no> bjornw@colargol.edb.tih.no (Bjoern Wennberg) writes:

   Hi!

   What should the 'type' command display ?
   When I do 'type -all man' I get
   man is aliased to `bman'
   man is ./man
	  ^^^^^
   This is a directory and shouldn't be displayed according to the 
   documentation of 'type'. The 'help type' says:

       If the -all flag is used, displays all of the places that contain an
       executable named `file'.  This includes aliases and functions, if and
       only if the -path flag is not also used.

   Is this correct?

   bjornw>

   bjornw@colargol.edb.tih.no

I believe it does this because the execute bit is set on directories. This
could/sould be corrected by checking for the directory bit, but apparently is
not (patch?)
--

=================================================================
      alan da wicked               (rod@ccwf.cc.utexas.edu)
=================================================================

Newsgroups: gnu.bash.bug
From: peterc@suite.sw.oz.AU (Peter Chubb)
Subject: ! history expansion problems
Organization: Softway Pty Ltd
Distribution: gnu
Date: Fri, 24 Jul 1992 03:26:41 GMT

How can I disable csh-style history expansion within shell character classes?
For example:

	cp ../skeleton/.[!.]* .

to set up a user's account.

As ! here indicates inversion of the character class, I think it
should be added to the set of special cases where it is not expanded
as history.



			Regards,

				- Peter Chubb

Softway Pty Ltd, P.O. Box 305, Strawberry Hills, NSW 2012, AUSTRALIA
Phone: +61 2 698 2322;       Fax: +61 2 699 9174;     Telex: AA27987
Internet: peterc@softway.oz.au	   UUCP: ...!uunet!softway.oz!peterc