Re: Shell games

2000-04-18 Thread Jamie Howard

On Tue, 18 Apr 2000, Brian Somers wrote:

  I don't get a lot of time to pay attention to the lists, so this might
  have been asked before.  Does the csh-tcsh move imply that sh-ksh will
  be happening soon?  Didn't NetBSD do that a while ago?
 
 *groan*  shame on you !  Everyone went a step further and targeted 
 the sh - bash war !

I thought I would try to be reasonable ;)

Anyway, someone pointed out the -arch discussions about it.  I'll slink
away now :)



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re:Re: Code

1999-12-24 Thread Jamie Howard

On Wed, 22 Dec 1999, Kip Macy wrote:

 Typically it refers to moving a process and all its associated attributes
 from one machine to another. There are a lot of problems with it, to
 the best of my knowledge the only OS that ever managed to get it right was
 Berkeley's Elf which was designed with it in mind from the beginning.
 Osterhout, the professor heading the group, said afterwords that the costs
 exceeded the gains.

Was Elf related to Sprite?

Jamie



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: getopt.h

1999-10-20 Thread Jamie Howard

On Wed, 20 Oct 1999, Jeroen Ruigrok/Asmodai wrote:

 Well I searched the mailinglists and didn't really got further than
 discovering that unistd.h goes a little way to provide functionality
 which getopt.h from glibc provides.  And seeing that a question of Bill
 early 1999 never got answered correctly.  I cc:'d Bruce on this since I
 value his stylistic mindset on this issue.

Speaking of which, are we ever going to get a getopt_long()?

NetBSD's compiles and runs fine if you hack out your own getopt.h, which
looks a whole lot like the one at the end of the original message.  :)

Jamie



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: A new package fetching utility, pkg_get

1999-09-24 Thread Jamie Howard

On Fri, 24 Sep 1999, Jordan K. Hubbard wrote:

 You bet!  And we haven't even gotten to the topic of the interactive
 package selection menu yet! :-)

A friend of mine is working on an X/Java version of that.  I have no idea
how far he has gotten.  I reviewed his notes, it looks like a great
concept though.  I CC'd him on this.

Jamie



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: setting up -STABLE for hack contest

1999-08-20 Thread Jamie Howard

On Fri, 20 Aug 1999, Lauri Laupmaa wrote:

 I would like to know how to change login screen and make it difficult to
 guess what operating system is running, etc.

Change the "default" entry in /etc/gettytab.

On a 3.2-STABLEsustem (from the 19990812 snapshot), the default line looks
like:

default:\
:cb:ce:ck:lc:fd#1000:im=\r\n%s/%m (%h) (%t)\r\n\r\n:sp#1200:

You can change it to something like this for fun:

default:\
:cb:ce:ck:lc:fd#1000:im=\r\nOpenVMS\r\n\r\n:sp#1200:

It is also trivial to hack login(1) to say "Username:" to instead of
"login:".  As you might have guessed, I did this to a FreeBSD 3.0 system
about nine months ago.

Jamie



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: setting up -STABLE for hack contest

1999-08-20 Thread Jamie Howard
On Fri, 20 Aug 1999, Lauri Laupmaa wrote:

 I would like to know how to change login screen and make it difficult to
 guess what operating system is running, etc.

Change the default entry in /etc/gettytab.

On a 3.2-STABLEsustem (from the 19990812 snapshot), the default line looks
like:

default:\
:cb:ce:ck:lc:fd#1000:im=\r\n%s/%m (%h) (%t)\r\n\r\n:sp#1200:

You can change it to something like this for fun:

default:\
:cb:ce:ck:lc:fd#1000:im=\r\nOpenVMS\r\n\r\n:sp#1200:

It is also trivial to hack login(1) to say Username: to instead of
login:.  As you might have guessed, I did this to a FreeBSD 3.0 system
about nine months ago.

Jamie



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: libcompat proposition

1999-08-13 Thread Jamie Howard

On Fri, 13 Aug 1999, Sheldon Hearn wrote:

 Close, but what I said was more along the lines that following NetBSD's
 footsteps on issues relating to portability is _seldom_ a bad idea.

I was close enough that you know the exact quote so I think I did alright.

Back to the point, just stick it in libc :)

Jamie



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: libcompat proposition

1999-08-13 Thread Jamie Howard
On Thu, 12 Aug 1999, Jamie Howard wrote:

 How would those functions which also exist in libc (or possibly other
 libraries, I don't know) be handled?

Just following up to myself here, NetBSD has a getopt_long() in libc

ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/lib/libc/stdlib/

I saw someone say that anything NetBSD did in the name of portability must
be right (in the test thread).  :)

Jamie



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: libcompat proposition

1999-08-13 Thread Jamie Howard
On Fri, 13 Aug 1999, Sheldon Hearn wrote:

 Close, but what I said was more along the lines that following NetBSD's
 footsteps on issues relating to portability is _seldom_ a bad idea.

I was close enough that you know the exact quote so I think I did alright.

Back to the point, just stick it in libc :)

Jamie



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: libcompat proposition

1999-08-12 Thread Jamie Howard

On Thu, 12 Aug 1999, Tim Vanderhoek wrote:

 src/lib/libgnucompat seems to be the best suggestion so far.  I wonder
 where the line between libgnucompat and libfreebsdextension is,
 though.

I've only been active here a few weeks but I've grown used to the "go
ahead and do it" I know I'm about to get...

Why not call it src/lib/libiberty and create a fully compatable version
which is truly free?  Quickly glancing through binutils-2.9's libiberty
directory on gnudist.gnu.org (this is the cannonical version as near as I
can tell) most of it is implemented in libc and quite a few files are PD.

How would those functions which also exist in libc (or possibly other
libraries, I don't know) be handled?

Jamie



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: libcompat proposition

1999-08-12 Thread Jamie Howard
On Thu, 12 Aug 1999, Tim Vanderhoek wrote:

 src/lib/libgnucompat seems to be the best suggestion so far.  I wonder
 where the line between libgnucompat and libfreebsdextension is,
 though.

I've only been active here a few weeks but I've grown used to the go
ahead and do it I know I'm about to get...

Why not call it src/lib/libiberty and create a fully compatable version
which is truly free?  Quickly glancing through binutils-2.9's libiberty
directory on gnudist.gnu.org (this is the cannonical version as near as I
can tell) most of it is implemented in libc and quite a few files are PD.

How would those functions which also exist in libc (or possibly other
libraries, I don't know) be handled?

Jamie



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: BSD XFS Port BSD VFS Rewrite

1999-08-10 Thread Jamie Howard

On Tue, 10 Aug 1999, Chris Csanady wrote:

 I don't know, but I came across this at SGI:
 
   http://oss.sgi.com/projects/xfs/
 
 It looks as though they plan to release it under the GPL. :(

This is why people should start emailing asking for a dual-license that
would support incorporation into FreeBSD.  If I remember my history
right[1], SGI based Irix on BSD extensively and became the first POSIX
compatable BSD.  See if you can play off some sense of loyalty.  Explain
to them that using a dual license would permit even further use of the
product.

Is there a stock "Please use a BSD license instead" letter that is kept
around for these purposes?

Jamie

[1]  This is always questionable.  And when the history doesn't fit what I
need it to say, I change it anyway:)



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: BSD XFS Port BSD VFS Rewrite

1999-08-10 Thread Jamie Howard
On Tue, 10 Aug 1999, Chris Csanady wrote:

 I don't know, but I came across this at SGI:
 
   http://oss.sgi.com/projects/xfs/
 
 It looks as though they plan to release it under the GPL. :(

This is why people should start emailing asking for a dual-license that
would support incorporation into FreeBSD.  If I remember my history
right[1], SGI based Irix on BSD extensively and became the first POSIX
compatable BSD.  See if you can play off some sense of loyalty.  Explain
to them that using a dual license would permit even further use of the
product.

Is there a stock Please use a BSD license instead letter that is kept
around for these purposes?

Jamie

[1]  This is always questionable.  And when the history doesn't fit what I
need it to say, I change it anyway:)



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: Was someone looking for a BSD licensed stat(1)?

1999-08-01 Thread Jamie Howard

On Sun, 1 Aug 1999, Keith Stevenson wrote:

 the features that were requested.  I honestly haven't figured out how to
 implement the display of selected fields yet.  I realize that this isn't a

Attached is a diff that takes care of that.  Basically, the user can
specify a format that looks like "%f\t%U\t%A" to get the files name, the
username of the owner, and the last access time seperated by tabs
followed by a new line. All of the supported format specifiers are
documented in the man page. I looked around for another version of stat
that does this but could not locate one; therefore the format specifiers
are what made sense to me.  There is also limited support for C-style
escape sequences (no \nnn).

Have a nice day!

Jamie




diff -c stat/stat.1 stat-jph/stat.1
*** stat/stat.1 Sun Aug  1 23:18:48 1999
--- stat-jph/stat.1 Sun Aug  1 23:50:31 1999
***
*** 42,71 
  The options are as follows:
  .Bl -tag -width Fl
  .It Fl d
! dereference symlinks
  .It Fl f
! read filenames to be stat-ed from file ( - means stdin)
  .It Fl g
! show time elements in GMT time zone.  (implies -s)
  .It Fl h
! print usage summary
  .It Fl i
! ignore errors
  .It Fl l
! display one element per line
  .It Fl s
! print mode, uid, gid, and times as strings
  .It Fl t
! terse output
  .It Fl o Ar opts
! output only selected elements of struct stat
  .It Fl f Ar file
! read filenames to be stat-ed from file ( - means stdin)
  .El
  .Sh EXAMPLES
  An example or two will go here
  .Pp
  .Sh SEE ALSO
  .Xr stat 2
  .Rs
  .Sh AUTHORS
--- 42,107 
  The options are as follows:
  .Bl -tag -width Fl
  .It Fl d
! Follow symbolic links.
  .It Fl f
! Read filenames to be stat-ed from file ( - means stdin).
  .It Fl g
! Show time elements in GMT time zone.  (implies -s)
  .It Fl h
! Print usage summary.
  .It Fl i
! Ignore errors.
  .It Fl l
! Display one element per line.
  .It Fl s
! Print mode, uid, gid, and times as strings.
  .It Fl t
! Terse output.
  .It Fl o Ar opts
! Output only selected elements of struct stat.  The following
! formatting tags are permitted:
! .Bl -tag -width Fl
! .It Ar %A
! last access time
! .It Ar %C
! file creation time
! .It Ar %G
! file group (group name)
! .It Ar %M
! last modify time
! .It Ar %P
! file permission mode (symbolic)
! .It Ar %U
! file owner (username)
! .It Ar %b
! blocks allocated for file
! .It Ar %d
! device file is on
! .It Ar %f 
! file name
! .It Ar %g
! file group (gid)
! .It Ar %i
! inode
! .It Ar %l
! number of hard links to file
! .It Ar %p
! file permission mode (octal)
! .It Ar %s
! file size in blocks 
! .It Ar %t 
! type of file
! .It Ar %u
! file owner (uid)
! .El
  .It Fl f Ar file
! Read filenames to be stat-ed from file ( - means stdin).
  .El
  .Sh EXAMPLES
  An example or two will go here
  .Pp
  .Sh SEE ALSO
+ .Xr ls 1 ,
  .Xr stat 2
  .Rs
  .Sh AUTHORS
***
*** 73,76 
  .Sh DIAGNOSTICS
  Most errors are the result of bad filenames.
  .Sh BUGS
! Some features (-f, -i,  -o) are currently unimplemented
--- 109,112 
  .Sh DIAGNOSTICS
  Most errors are the result of bad filenames.
  .Sh BUGS
! Some features (-f and -i) are currently unimplemented
diff -c stat/stat.c stat-jph/stat.c
*** stat/stat.c Sun Aug  1 23:17:14 1999
--- stat-jph/stat.c Sun Aug  1 23:34:29 1999
***
*** 57,62 
--- 57,65 
  void terseprint(const char*, const char*, const char*, const char*,
struct stat*, struct group*, struct passwd*, struct tm*,
struct tm*, struct tm*, int);
+ void customprint(const char *, const char*, const char*, const char*, 
+const char*, struct stat*, struct group*, struct passwd*, 
+struct tm*, struct tm*, struct tm*, int);
  int vstat(const char*, struct stat*, int);
  
  
***
*** 78,85 
struct stat inode;
struct tm   *atime, *mtime, *ctime;
  
!   extern char *optarg;
!   extern int  optind;
  
  
/* flags */
--- 81,87 
struct stat inode;
struct tm   *atime, *mtime, *ctime;
  
!   char *oformat;
  
  
/* flags */
***
*** 113,122 
f_listout = 1;
break;
case 'o':
-   printf("Unimplemented.\n");
-   exit(EX_OK);
f_customout = 1;
f_listout = 1;
break;
case 's':
f_stringout = 1;
--- 115,123 
f_listout = 1;
break;
case 'o':
f_customout = 1;
f_listout = 1;
+   oformat = optarg;
break;
case 's':

Re: Was someone looking for a BSD licensed stat(1)?

1999-08-01 Thread Jamie Howard
On Sun, 1 Aug 1999, Keith Stevenson wrote:

 the features that were requested.  I honestly haven't figured out how to
 implement the display of selected fields yet.  I realize that this isn't a

Attached is a diff that takes care of that.  Basically, the user can
specify a format that looks like %f\t%U\t%A to get the files name, the
username of the owner, and the last access time seperated by tabs
followed by a new line. All of the supported format specifiers are
documented in the man page. I looked around for another version of stat
that does this but could not locate one; therefore the format specifiers
are what made sense to me.  There is also limited support for C-style
escape sequences (no \nnn).

Have a nice day!

Jamie




diff -c stat/stat.1 stat-jph/stat.1
*** stat/stat.1 Sun Aug  1 23:18:48 1999
--- stat-jph/stat.1 Sun Aug  1 23:50:31 1999
***
*** 42,71 
  The options are as follows:
  .Bl -tag -width Fl
  .It Fl d
! dereference symlinks
  .It Fl f
! read filenames to be stat-ed from file ( - means stdin)
  .It Fl g
! show time elements in GMT time zone.  (implies -s)
  .It Fl h
! print usage summary
  .It Fl i
! ignore errors
  .It Fl l
! display one element per line
  .It Fl s
! print mode, uid, gid, and times as strings
  .It Fl t
! terse output
  .It Fl o Ar opts
! output only selected elements of struct stat
  .It Fl f Ar file
! read filenames to be stat-ed from file ( - means stdin)
  .El
  .Sh EXAMPLES
  An example or two will go here
  .Pp
  .Sh SEE ALSO
  .Xr stat 2
  .Rs
  .Sh AUTHORS
--- 42,107 
  The options are as follows:
  .Bl -tag -width Fl
  .It Fl d
! Follow symbolic links.
  .It Fl f
! Read filenames to be stat-ed from file ( - means stdin).
  .It Fl g
! Show time elements in GMT time zone.  (implies -s)
  .It Fl h
! Print usage summary.
  .It Fl i
! Ignore errors.
  .It Fl l
! Display one element per line.
  .It Fl s
! Print mode, uid, gid, and times as strings.
  .It Fl t
! Terse output.
  .It Fl o Ar opts
! Output only selected elements of struct stat.  The following
! formatting tags are permitted:
! .Bl -tag -width Fl
! .It Ar %A
! last access time
! .It Ar %C
! file creation time
! .It Ar %G
! file group (group name)
! .It Ar %M
! last modify time
! .It Ar %P
! file permission mode (symbolic)
! .It Ar %U
! file owner (username)
! .It Ar %b
! blocks allocated for file
! .It Ar %d
! device file is on
! .It Ar %f 
! file name
! .It Ar %g
! file group (gid)
! .It Ar %i
! inode
! .It Ar %l
! number of hard links to file
! .It Ar %p
! file permission mode (octal)
! .It Ar %s
! file size in blocks 
! .It Ar %t 
! type of file
! .It Ar %u
! file owner (uid)
! .El
  .It Fl f Ar file
! Read filenames to be stat-ed from file ( - means stdin).
  .El
  .Sh EXAMPLES
  An example or two will go here
  .Pp
  .Sh SEE ALSO
+ .Xr ls 1 ,
  .Xr stat 2
  .Rs
  .Sh AUTHORS
***
*** 73,76 
  .Sh DIAGNOSTICS
  Most errors are the result of bad filenames.
  .Sh BUGS
! Some features (-f, -i,  -o) are currently unimplemented
--- 109,112 
  .Sh DIAGNOSTICS
  Most errors are the result of bad filenames.
  .Sh BUGS
! Some features (-f and -i) are currently unimplemented
diff -c stat/stat.c stat-jph/stat.c
*** stat/stat.c Sun Aug  1 23:17:14 1999
--- stat-jph/stat.c Sun Aug  1 23:34:29 1999
***
*** 57,62 
--- 57,65 
  void terseprint(const char*, const char*, const char*, const char*,
struct stat*, struct group*, struct passwd*, struct tm*,
struct tm*, struct tm*, int);
+ void customprint(const char *, const char*, const char*, const char*, 
+const char*, struct stat*, struct group*, struct passwd*, 
+struct tm*, struct tm*, struct tm*, int);
  int vstat(const char*, struct stat*, int);
  
  
***
*** 78,85 
struct stat inode;
struct tm   *atime, *mtime, *ctime;
  
!   extern char *optarg;
!   extern int  optind;
  
  
/* flags */
--- 81,87 
struct stat inode;
struct tm   *atime, *mtime, *ctime;
  
!   char *oformat;
  
  
/* flags */
***
*** 113,122 
f_listout = 1;
break;
case 'o':
-   printf(Unimplemented.\n);
-   exit(EX_OK);
f_customout = 1;
f_listout = 1;
break;
case 's':
f_stringout = 1;
--- 115,123 
f_listout = 1;
break;
case 'o':
f_customout = 1;
f_listout = 1;
+   oformat = optarg;
break;
case 's':
 

Re: replacing grep(1)

1999-07-27 Thread Jamie Howard

On Tue, 27 Jul 1999, Nickolay N. Dudorov wrote:

   After making it on the CURRENT system I can only
 see:
 
   grep: filename: Undefined error: 0
 
 for every filename.

Every file?

 
   This caused by very "unusual" return values for
 'grep_open' (and other '..._open') function which is declared
 as 'int' (and return int result) and compared with NULL ;-(
 
   I prefer not to include the patch for this because
 I am uncompatible with such trics as:
 
   return ((f = fopen(path, mode)) != NULL) - 1;

This was done this way because the gzopen and fopen both return pointers
of different types.  Maybe the best thing would be to have grep_open()
return a void pointer since procfile() doesn't keep track of what files
are open and not.  This is ugly and not very reusable, but then again how
many programs need transparent access to both gzip'd and plaintext files?

Jamie



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: replacing grep(1)

1999-07-27 Thread Jamie Howard

On Tue, 27 Jul 1999, Doug wrote:

   First, I'm all for this idea, and applaud you and Jamie for taking
 it on. I do have a few questions. Does POSIX say anything about grep, and
 if so, is this version compliant? Also, I'd like to put in another vote
 for full GNU grep feature compliance, since while having our own code is a
 good thing, I am against introducing gratuitous differences since I have
 enough of those to deal with already.

I do not have a copy of POSIX, but I do have Unix98 which is a superset of
POSIX.  Right now, excluding bugs, it is Unix 98 and therefore POSIX
compliant except for -e.  -e should permit multiple patterns and it never
occured to me that anyone would want to do this.  When used with -F,
multiple patterns are accepted.
 
   I use grep heavily in day to day administration tasks so I look
 forward to giving this a try.

Cool, d/l it and post a bug-list :)

Jamie



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: replacing grep(1)

1999-07-27 Thread Jamie Howard
On Tue, 27 Jul 1999, Nickolay N. Dudorov wrote:

   After making it on the CURRENT system I can only
 see:
 
   grep: filename: Undefined error: 0
 
 for every filename.

Every file?

 
   This caused by very unusual return values for
 'grep_open' (and other '..._open') function which is declared
 as 'int' (and return int result) and compared with NULL ;-(
 
   I prefer not to include the patch for this because
 I am uncompatible with such trics as:
 
   return ((f = fopen(path, mode)) != NULL) - 1;

This was done this way because the gzopen and fopen both return pointers
of different types.  Maybe the best thing would be to have grep_open()
return a void pointer since procfile() doesn't keep track of what files
are open and not.  This is ugly and not very reusable, but then again how
many programs need transparent access to both gzip'd and plaintext files?

Jamie



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: replacing grep(1)

1999-07-27 Thread Jamie Howard
On Tue, 27 Jul 1999, Brian F. Feldman wrote:

 That's true. I'd like to see the replacement grep do mmaping of the
 input files if it doesn't already, as that would speed it up. Anyway,

It does not use mmap right now.  And this causes a significant perforamce
hit on larger files.  An older version (I'm thinking .4) would give
equivalent performance on smaller files, 75k or so, occassionally faster.
However, larger files really drag it down, often slower by 900%.

 I haven't tried it out yet because I haven't seen it hit 1.0 :) The
 only good pre-1.0 software I've seen has been the GIMP, XRacer, and
 some little utilities (like a program called stat(1)).
 
 That reminds me. I'd like to see something like stat(1) go into the source
 tree, but only if it were freely licensed, not GPL-infected. I could do
 it in a day, I suppose, if it were worth it. Worth it is here defined as
 would be accepted to go in usr.bin.

I once saw a version of stat that carried a public domain statement on an
HP-UX software archive, I'll see if I can dig that up for you.

Jamie



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: replacing grep(1)

1999-07-27 Thread Jamie Howard
On Tue, 27 Jul 1999, Doug wrote:

   First, I'm all for this idea, and applaud you and Jamie for taking
 it on. I do have a few questions. Does POSIX say anything about grep, and
 if so, is this version compliant? Also, I'd like to put in another vote
 for full GNU grep feature compliance, since while having our own code is a
 good thing, I am against introducing gratuitous differences since I have
 enough of those to deal with already.

I do not have a copy of POSIX, but I do have Unix98 which is a superset of
POSIX.  Right now, excluding bugs, it is Unix 98 and therefore POSIX
compliant except for -e.  -e should permit multiple patterns and it never
occured to me that anyone would want to do this.  When used with -F,
multiple patterns are accepted.
 
   I use grep heavily in day to day administration tasks so I look
 forward to giving this a try.

Cool, d/l it and post a bug-list :)

Jamie



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



m68k Support in FreeBSD

1999-07-19 Thread Jamie Howard
A week or so ago there was some discussion of someone who ported FreeBSD
to 68k-based Macintosh systems on EFNet.  There was also a reference to a
website (http://www.freebsd.org/~green/FreeBSD-68k.txt).  In about two
weeks I'll have a spare Macintosh IIsi and would like to have a run at
FreeBSD on it.  So, to the point, where can I get it? :)

Jamie



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: Replacement for grep(1) (part 2)

1999-07-07 Thread Jamie Howard

On 7 Jul 1999, Dag-Erling Smorgrav wrote:

 BTW, I assume you've read this:
 
URL:http://www.opengroup.org/onlinepubs/007908799/xcu/grep.html

Of course, my copy of the printout is all marked up.  :)
 
 I see you switched to using extended regexps by default, and made -E a
 no-op; this breaks the ports collection, so I changed it back.

The FreeBSD, NetBSD, and OpenBSD manpage for grep says this:

Grep understands two different versions of regular expression
syntax: ``basic''  and  ``extended.''   In  GNU grep, there  is
no  difference in available functionality using either syntax.   

Is this inaccurate or am I reading it wrong?

 Sort your switch cases.
 
 Don't use err() indiscriminately after a malloc() failure; malloc()
 doesn't set errno.

Shouldn't malloc be fixed?  :)



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Repalcement for grep(1)

1999-07-07 Thread Jamie Howard

On 7 Jul 1999, Dag-Erling Smorgrav wrote:

 Jamie Howard [EMAIL PROTECTED] writes:
  On Sun, 4 Jul 1999, Archie Cobbs wrote:
  There are two special cases- of bracket  expressions:  the
  bracket expressions `[[::]]' and `[[::]]' match the null
  string at the beginning and end of a word respectively.
   Perhaps this will help with -w?
  Yes, I received a patch from Simon Burge which implements this.  It also
  beats using [^A-Za-z] and [A-Za-z$] as I was and GNU grep does.
 
 No, because there are scripts out there (e.g. ports/Mk/bsd.port.mk)
 which rely on this behaviour.

I just knocked this down to just freebsd-hackers because this only applies
here (so far).

I am not the internationalization expert, but doesn't [^A-Za-z] and
[A-Xa-z$] limit you to just English and other Roman languages?  Won't
[[::]] and [[::]] be languages independent, presuming regex supports
it?

Jamie



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Replacement for grep(1) (part 2)

1999-07-07 Thread Jamie Howard
On 7 Jul 1999, Dag-Erling Smorgrav wrote:

 BTW, I assume you've read this:
 
URL:http://www.opengroup.org/onlinepubs/007908799/xcu/grep.html

Of course, my copy of the printout is all marked up.  :)
 
 I see you switched to using extended regexps by default, and made -E a
 no-op; this breaks the ports collection, so I changed it back.

The FreeBSD, NetBSD, and OpenBSD manpage for grep says this:

Grep understands two different versions of regular expression
syntax: ``basic''  and  ``extended.''   In  GNU grep, there  is
no  difference in available functionality using either syntax.   

Is this inaccurate or am I reading it wrong?

 Sort your switch cases.
 
 Don't use err() indiscriminately after a malloc() failure; malloc()
 doesn't set errno.

Shouldn't malloc be fixed?  :)



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: Repalcement for grep(1)

1999-07-07 Thread Jamie Howard
On 7 Jul 1999, Dag-Erling Smorgrav wrote:

 Jamie Howard howar...@wam.umd.edu writes:
  On Sun, 4 Jul 1999, Archie Cobbs wrote:
  There are two special cases- of bracket  expressions:  the
  bracket expressions `[[::]]' and `[[::]]' match the null
  string at the beginning and end of a word respectively.
   Perhaps this will help with -w?
  Yes, I received a patch from Simon Burge which implements this.  It also
  beats using [^A-Za-z] and [A-Za-z$] as I was and GNU grep does.
 
 No, because there are scripts out there (e.g. ports/Mk/bsd.port.mk)
 which rely on this behaviour.

I just knocked this down to just freebsd-hackers because this only applies
here (so far).

I am not the internationalization expert, but doesn't [^A-Za-z] and
[A-Xa-z$] limit you to just English and other Roman languages?  Won't
[[::]] and [[::]] be languages independent, presuming regex supports
it?

Jamie



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: Replacement for grep(1) (part 2)

1999-07-06 Thread Jamie Howard

On Tue, 6 Jul 1999, Sheldon Hearn wrote:

 The reason I'm suggesting using a port rather than having the code
 imported into the base system is that it allows people to "opt in" to
 testing it, rather than forcing it down people's throats. The idea is
 that, when it's proved itself as a port, enough people will clamor for
 its inclusion in the base system for that to become a reality.
 
 Trying to get software imported directly into the base system without a
 trial run as a port is almost always a painful exercise (and I'm not
 talking about technical issues here).

Ahh, this is a good idea.  I have not yet replaced GNU grep on my system
with this so it has not yet occurred to me that there might be issues with
that.

I noticed Jake Burkholder put together a simple port.  I'll go ahead and
make sure that stays updated.

Jamie



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Replacement for grep(1) (part 2)

1999-07-06 Thread Jamie Howard
On Tue, 6 Jul 1999, Sheldon Hearn wrote:

 The reason I'm suggesting using a port rather than having the code
 imported into the base system is that it allows people to opt in to
 testing it, rather than forcing it down people's throats. The idea is
 that, when it's proved itself as a port, enough people will clamor for
 its inclusion in the base system for that to become a reality.
 
 Trying to get software imported directly into the base system without a
 trial run as a port is almost always a painful exercise (and I'm not
 talking about technical issues here).

Ahh, this is a good idea.  I have not yet replaced GNU grep on my system
with this so it has not yet occurred to me that there might be issues with
that.

I noticed Jake Burkholder put together a simple port.  I'll go ahead and
make sure that stays updated.

Jamie



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: Repalcement for grep(1)

1999-07-05 Thread Jamie Howard

On Mon, 5 Jul 1999, Archie Cobbs wrote:

 Are you sure you're stripping out the newline and carriage return?

You know, that did it. 

I'l put together another version tonight incorporating all the bug fixes
and suggestions I have received over the past few days.  More on that
shortly.

Jamie



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Replacement for grep(1) (part 2)

1999-07-05 Thread Jamie Howard

Due to the number of fixes I have received over the past few days, I
decided to put together a new release of grep.  It was either this or 
watch _Titanic_ on Cinemax.

I incorporated a huge patch from Dag-Erling Smorgrav which as he put it
"cleaned it up to make it conform to FreeBSD's coding style standards. I
also removed a bunch of unused or unnecessary variables, fixed one or two
minor bugs, and made a few entirely subjective cosmetic improvements."  He
also modified the Makefile to generate links for fgrep and egrep as well.
All things I was going to worry with when it was done.  :)  I added the
links for zgrep.  I changed the sample length in the binary checker from
64 bytes to 32 at his suggestion.  This is the same as how GNU grep
handles it.

I changed it so that even when called as grep or with -G, it treats the
pattern as an extended regular expression.  GNU grep behaves the same way.

Simon Burge sent code to enable -w as well as several smaller code fixes
and clean ups.

I changed bin_file() and seekable() to operate on a pointer to a FILE
rather than on an integer file descriptor.

Due to popular demand, I added support for searching gzip compressed
files.  GNU grep only supports searching gzip compressed files.  It did
not bloat my code as much as I expected; I vapor locked and forgot about
libz, which did all the hard work for me.  It would be trivial to add
support for bzip and bzip2 files for those OSes that have libbz2.

Archie Cobbs dropped the hint needed to solve the problems with -x.  Right
now, I wrap the pattern with "^(" and ")$".  I know GNU grep does this,
but is this correct?

Now, as it stands, I beleive this implementation is identical to GNU grep,
except for the added -o option, and the -A num, -B num, -C, and -num
family of options.  Despite what I said before, I will implement them.
Another popular demand thing.  So I will take care of that over the next
few days.

It would be really swank if someone were to go over what I have and make
sure it is correct.  I know I was blowing $ before, and I think that is
correct now.

Due to problems with the previous download site (it is down as I type
this), I will place this file in two locations:

ftp://dragon.ham.muohio.edu/pub/howardjp/grep-0.3.tar.gz
ftp://ftp.wam.umd.edu/pub/howardjp/grep-0.3.tar.gz

It will probably be slow to hit the second, as it may be down until
tomorrow morning.

Thank you everyone who helped,
Jamie



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Repalcement for grep(1)

1999-07-05 Thread Jamie Howard
On Mon, 5 Jul 1999, Archie Cobbs wrote:

 Are you sure you're stripping out the newline and carriage return?

You know, that did it. 

I'l put together another version tonight incorporating all the bug fixes
and suggestions I have received over the past few days.  More on that
shortly.

Jamie



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: Replacement for grep(1) (part 2)

1999-07-05 Thread Jamie Howard
Due to the number of fixes I have received over the past few days, I
decided to put together a new release of grep.  It was either this or 
watch _Titanic_ on Cinemax.

I incorporated a huge patch from Dag-Erling Smorgrav which as he put it
cleaned it up to make it conform to FreeBSD's coding style standards. I
also removed a bunch of unused or unnecessary variables, fixed one or two
minor bugs, and made a few entirely subjective cosmetic improvements.  He
also modified the Makefile to generate links for fgrep and egrep as well.
All things I was going to worry with when it was done.  :)  I added the
links for zgrep.  I changed the sample length in the binary checker from
64 bytes to 32 at his suggestion.  This is the same as how GNU grep
handles it.

I changed it so that even when called as grep or with -G, it treats the
pattern as an extended regular expression.  GNU grep behaves the same way.

Simon Burge sent code to enable -w as well as several smaller code fixes
and clean ups.

I changed bin_file() and seekable() to operate on a pointer to a FILE
rather than on an integer file descriptor.

Due to popular demand, I added support for searching gzip compressed
files.  GNU grep only supports searching gzip compressed files.  It did
not bloat my code as much as I expected; I vapor locked and forgot about
libz, which did all the hard work for me.  It would be trivial to add
support for bzip and bzip2 files for those OSes that have libbz2.

Archie Cobbs dropped the hint needed to solve the problems with -x.  Right
now, I wrap the pattern with ^( and )$.  I know GNU grep does this,
but is this correct?

Now, as it stands, I beleive this implementation is identical to GNU grep,
except for the added -o option, and the -A num, -B num, -C, and -num
family of options.  Despite what I said before, I will implement them.
Another popular demand thing.  So I will take care of that over the next
few days.

It would be really swank if someone were to go over what I have and make
sure it is correct.  I know I was blowing $ before, and I think that is
correct now.

Due to problems with the previous download site (it is down as I type
this), I will place this file in two locations:

ftp://dragon.ham.muohio.edu/pub/howardjp/grep-0.3.tar.gz
ftp://ftp.wam.umd.edu/pub/howardjp/grep-0.3.tar.gz

It will probably be slow to hit the second, as it may be down until
tomorrow morning.

Thank you everyone who helped,
Jamie



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: Repalcement for grep(1)

1999-07-04 Thread Jamie Howard
On Sun, 4 Jul 1999, Archie Cobbs wrote:

There are two special cases- of bracket  expressions:  the
bracket expressions `[[::]]' and `[[::]]' match the null
string at the beginning and end of a word respectively.  A
word  is defined as a sequence of word characters which is
neither preceded nor followed by word characters.  A  word
character  is  an alnum character (as defined by ctype(3))
or an underscore.  This is an extension,  compatible  with
but not specified by POSIX 1003.2, and should be used with
caution in software intended to be portable to other  sys-
tems.
 
 Perhaps this will help with -w?

Yes, I received a patch from Simon Burge which implements this.  It also
beats using [^A-Za-z] and [A-Za-z$] as I was and GNU grep does.   I am
still having trouble with -x though.  It turns out that even if I specify
a commandline with a pattern of the form ^pattern$, it fails.  If I
specify ^pattern it works.  If I specify pattern$ it does not.  I have
yet to find a case where my version will sucessfully match when a $ is at
the end.  Has anyone encountered anything like this before?

Jamie



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Repalcement for grep(1)

1999-07-03 Thread Jamie Howard
I have used FreeBSD for a couple years now.  It is the only OS on my
desktop.  I have learnt many things from its source.  I felt it was time
to give something back.  A few minutes later I decided to offer it to all
BSDs.  I also will offer it to the DaemonLinux group, Apple, the  Darwin
group, and Tenon Systems, after public acceptence.  If there is anyone
else out there using a BSD base and GNU grep, they can have it too.

Looking aroud, I thought it would be great to try to replace one of the
GNU utilites included in the base with a version which is freely
redistributable.  I figured a compiler was beyond me, but a a couple of
the simpler utilities caught my eye.  Grep was first.

All of the code is original except for binary.c.  It is used with the -a
option to prevent searching binary files.  binary.c is extricated from
less-332's binary checking code.  I was just that lazy.

I made the version in FreeBSD 4.0 my target except for -A num, -B num, -C,
-num, and -Z.  These are not required by the Single Unix Specification or
POSIX and I felt they would bloat my code too significantly.  

I added the -o option from 4.4BSD-Lite2's implementation of egrep.  I also
stole it's man page.

One of the primary concerns was simplicity.  Looking through the code, you
should nobody should have any difficuly understanding the code.  Regex
does all the heavy work.  The object code is about 16% of the size of GNU 
grep.  I also do not use mmap(), I treat the file as a simple stream
instead.  My code is also a bit slower on larger files, but a bit faster
on smaller files.  Sometimes I am an order of magnitude slower.  I am
never that much faster.  I think not using mmap is the reason, but I do
not know for certain.

Now, I am having a problem though.  I cannot figure out how to implement
-w and -x.  For -x, I tried modifying the regular expression (foo) into
^(foo)$ before compiling, but that did not work.  I intended to do
something similar with -w.  Anyway, I am probably missing the obvious, but
does anyone have any ideas regarding how I should implement -w and -x?

If anyone can help with the -w and -x problems, would like to test, or has
any other comments, let me know.  I'd also like advice on the speed
issue.  Also, since I am at it, if you want anything added, lay it on me,
either code or ideas.  :)

The source code can be found at 

ftp://ftp.wam.umd.edu/pub/howardjp/grep-0.2.tar.gz

The source was written and tested on a FreeBSD 3.2 system.  I have also
compiled under BSDi 3.1.  It should work on any BSD and most any Unix.
The Makefile is written in the style of the rest of the FreeBSD utilites
so that it can be dropped right into /usr/src/usr.bin someday.  Only minor
modifications should be needed for BSDi, NetBSD, and OpenBSD.  I have not
built this on either NetBSD or OpenBSD but expect no problems.  If anyone
does have problems please let me know.  Fixes are even better. 

Thank you everyone, Jamie




To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message



Re: A way to crash system (3.1 3.2) with floppy

1999-06-28 Thread Jamie Howard
On Mon, 28 Jun 1999, Zhihui Zhang wrote:

 Suppose you have a *write-protected* DOS floppy and you do:
 
 # mount -t msdos /dev/fd0 /floppy  -- this is OK
 
 # cp somefile /floppy  -- a lot of error messages
 
 # umount /floppy   -- crash
 
 Now the system tries to sync the dirty buffers and fails.  You have to
 press a key to reboot. 
 
 Is there anything wrong here or FreeBSD simply does not handle this in a
 more elegant way? 
 
 Thanks for any help.

I had this happen to me the other day on my 3.2 system.  I thought it was
just me because I had mounted the disk several days before and figured I
had swapped it out.  I also had to reformat the floppy on a Win95 system
to make it usable again.

Jamie



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message