My other ISP runs Linux and there seems to be the following grep/egrep
problem when I run csh.  The problem does not arise with bash or ksh.

Here's the problem:

        When '^' is the first character in the grep/egrep search pattern
        and '*' appears in the filname position, grep/egrep treat '^'
        as a literal and not as a metacharacter.

I have two files, junk and junk1.  They differ only in that '^' is
the first character in junk1.

        67 > cat junk
        sql
        68 > cat junk1
        ^sql

        77 > egrep 'sql' j*  ; show that filename expansion is working
        junk:sql
        junk1:^sql
        78 >

Now, look at the following:

        71 > egrep '^sql' j*
        junk1:^sql
        72 >

This isn't correct!!  '^' as the first character in a grep/egrep
search pattern is a metacharacter standing for the beginning of a
line.  But it's being interpreted literally here.  So it matches.

Notice that if I use junk1 instead of j* that it gets it right.

        72 > egrep '^sql' junk1
        73 >

That is, the pattern isn't found because the requesting pattern is
'sql' at the beginning of a line.  (The first line in junk1 is '^sql',
where '^' is simply another character in the file, so it doesn't match
with 'sql' at the beginning of the line.)

Similarly, things work properly if I put in both file names explicitly:

        80 > egrep '^sql' junk junk1
        junk:sql
        81 >

If I run bash (or ksh) instead of csh, they get it right.  For example,
in bash:

        73 > bash
        bash$ egrep '^sql' j*
        junk:sql
        bash$

Again, csh gets it wrong, but only when a * is in the filename:

I don't have this problem on the various Solaris and SunOS 4.X systems
I have access to, just on this Linux system.

For what it's worth, here's what 'uname -a' on the Linux system shows:

        Linux bolt 2.0.36 #1 Tue Nov 24 05:29:56 PST 1998 i686

-- Roy

Very weird.  I don't see any way that the egrep program itself could be
sensitive to which shell it was run from or whether the filenames were
typed explicitly or generated from a wildcard -- by the time the program is
executed, it looks the same.  The only guess I can come up with is that you
have a csh alias for egrep that does something strange.

--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

I have NO aliases and get the problem.  In fact, I renamed my .cshrc
file (I had no .login) to make sure it wasn't coming from it.

Btw, the problem is there with grep as well.

-- Roy

[royhg@bolt]$ alias
[royhg@bolt]$

(Yes, I know the prompt is weird, but it's the default supplied by the
ISP in question.)

Here's what 'set' and 'env' show.  I have no idea what MINICOM is:

[royhg@bolt]$ set
argv    ()
cwd     /home/r/royhg
history 1000
home    /home/r/royhg
path    (/usr/local/bin /usr/bin /bin . /usr/X11R6/bin /usr/bin/mh)
prompt  [royhg@bolt]$
prompt2 ?
shell   /bin/csh
status  0
term    xterm
user    royhg
[royhg@bolt]$ env
DISPLAY=134.56.92.9:0.0
TERM=xterm
HOME=/home/r/royhg
PATH=/usr/local/bin:/usr/bin:/bin:.:/usr/X11R6/bin:/usr/bin/mh
SHELL=/bin/csh
MAIL=/var/spool/mail/royhg
LOGNAME=royhg
PWD=/home/r/royhg
HOSTNAME=`/bin/hostname`=
MINICOM=-l -m -con -tmc
[royhg@bolt]$

In comp.os.linux.misc Barry Margolin <bar...@bbnplanet.com> wrote:

Did you try with any other metacharacters such as "."

I think you have discovered a hidden feature of that csh. Add it to the
man page and you're set.

Chris

--
n...@tsaris.com sends binaries to hell
tsa...@tsaris.com spams spammers when spam quota are reached.
kn...@tsaris.com sends unknown headers to /dev/null

That is indeed a strange behavior; one random thought which may
or may not be relevant is that the SunOs/Solaris systems have a
"true" csh installed as "csh", but Linux will have "csh" as an
alias (link, symbolic or hard) for what is really tcsh.  The
next question is: what version?  Try an "echo $version"; I do
not see the behavior that you are reporting when using:
  tcsh 6.06.00 (Cornell) 1995-05-13 (i386-intel-linux) options 8b,dl,al,rh

                --Ken Pizzini

What are you talking about?  His regexp is '^sql', with no asterisks at
all.  His command line is:

egrep '^sql' j*

The * only appears in a filename glob, not a regexp.

--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

junk2 contains the line 'sql'.  junk3 contains the line 'sql$'

        71 > cat junk2
        sql
        72 > cat junk3
        sql$
        73 > egrep 'sql$' junk2 junk3
        junk2:sql
        74 > egrep 'sql$' j*
        junk3:sql$
        75 >

As you can see, when the file names are explicitly (73), egrep gets it
right, finding the 'sql' pattern at the end of the line.  But when the file
name is specified with '*' (74), the results are incorrect.

On this Linux system, csh is not apparently linked to tcsh.

75 > ls -li csh tcsh
   2062 -rwxr-xr-x   1 root     root       104776 Feb 25  1996 csh
   2090 -rwxrwxr-x   1 root     root       252676 Feb 26  1996 tcsh

-- Roy

In comp.os.linux.misc Chris <tsa...@tsaris.com> wrote:

Very strange.  Somehow, it seems like it's running fgrep instead of egrep
when you use a wildcard.  This makes absolutely no sense to me.

What happens if you specify the full pathname of the egrep program, i.e.

/usr/bin/egrep 'sql$' j*

--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

71 > which egrep
/usr/bin/egrep
72 > ls -li `which egrep`
  43257 -rwxr-xr-x   1 root     root        58112 Feb 25  1996 /usr/bin/egrep
73 > /usr/bin/egrep 'sql$' junk2 junk3
junk2:sql
74 > /usr/bin/egrep 'sql$' j*
junk3:sql$
75 >

-- Roy

In comp.os.linux.misc Barry Margolin <bar...@bbnplanet.com> wrote:

This must be a quite old GNU grep.  The latest is version 2.4, and
2.0 seems to have been released around October 1996.  Have you tried
a newer version?  (Aside: GNU grep/egrep/fgrep has had some weirdness
around deciding which behavior to use, depending on how it is invoked.)

--
Paul Kimoto             <kim...@lightlink.com>

: This must be a quite old GNU grep.  The latest is version 2.4, and
: 2.0 seems to have been released around October 1996.  Have you tried
: a newer version?  (Aside: GNU grep/egrep/fgrep has had some weirdness
: around deciding which behavior to use, depending on how it is invoked.)

It's version 2.0, but egrep is not at fault. I have been able to
reproduce Roy's problem, and the version of csh he is using is behind
it.  The file size and date above, and the sizes and dates Roy gave
earlier for csh and tcsh agree with the Red Hat 3.0.3 (March 1996)
release.  My system had csh symlinked to tcsh, and didn't show the
anomalous behavior, but when I installed (today) csh-5.2.6-2.i386.rpm
from the 3.0.3 CD, I got the behavior Roy gets.

From the man page:

   AUTHOR
        William Joy.  Job control and directory stack features first
        implemented by J.E. Kulp of IIASA, Laxenburg, Austria, with
        different syntax than that used now.  File name completion
        code written by Ken Greer, HP Labs. Eight-bit implementation
        Christos S. Zoulas, Cornell University.
   4th Berkeley Distribution        June 7, 1991

--
John Wingate                                       wing...@worldpath.net

Is there a later version of Red Hat (or other linux) csh that doesn't
have this problem?

Or, should I just use tcsh?  Is it really, to quote its man page, a:

        completely compatible version of the Berkeley UNIX C shell, csh(1).

(I guess this may be a question for a different thread.)

-- Roy

In comp.os.linux.misc John Wingate <wing...@worldpath.net> wrote:

: Is there a later version of Red Hat (or other linux) csh that doesn't
: have this problem?

I dunno.  I use bash, and pretty much ignore csh.

: Or, should I just use tcsh?  Is it really, to quote its man page, a:

:       completely compatible version of the Berkeley UNIX C shell, csh(1).

Try it.  It's supposed to be an enhanced and improved csh.

: In comp.os.linux.misc John Wingate <wing...@worldpath.net> wrote:
:> In comp.os.linux.misc Paul Kimoto <kim...@lightlink.com> wrote:
:> : In article <qDBc4.1174$T01.38...@nuq-read.news.verio.net>, Roy Gordon wrote:
:> :>  43257 -rwxr-xr-x   1 root     root        58112 Feb 25  1996 /usr/bin/egrep

:> The file size and date above, and the sizes and dates Roy gave
:> earlier for csh and tcsh agree with the Red Hat 3.0.3 (March 1996)
:> release.  My system had csh symlinked to tcsh, and didn't show the
:> anomalous behavior, but when I installed (today) csh-5.2.6-2.i386.rpm
:> from the 3.0.3 CD, I got the behavior Roy gets.

The quoted string is handled differently when globbing is involved:

   $ csh -x
   [jww@olorin]$ grep '^asd' xxx1 xxx2
   grep ^asd xxx1 xxx2
   xxx1:asdf
   [jww@olorin]$ grep  '^asd' xxx*
   grep \^\a\s\d xxx1 xxx2
   xxx2:^asdf

Why this is done is not clear--perhaps to protect asterisks, etc., in the
quoted string from being expanded.  I'm taking a look at the source code,
but haven't found anything yet.  (I'm a slow reader of unfamiliar C.)

The README file accompanying the source code says it is a "port of BSD
C Shell (ver 5.26) from the 386BSD source tree".  The port was made by
Ken Clark.

--
John Wingate                                       wing...@worldpath.net

I don't mind doing it, but don't know where.

-- Roy

In comp.os.linux.misc John Wingate <wing...@worldpath.net> wrote: