A semi-annual poke about progress
Hi. Seems like we've had a 1.1 release candidate sitting for a long time. Can we make it a release yet? It would be nice to have something newer than 1.0.4 going into things like Linux distributions. Jon
Re: A semi-annual poke about progress
Are you still sheparding this project? I remembered to look at http://savannah.nongnu.org/projects/nmh I noticed that there are outstanding bugs - I haven't had a chance to look at the reports. Do you need help with them?
Re: A semi-annual poke about progress
Please let's do it!! I've been using nmh-1.1-RC1.tar.gz since Nov 18, 2002. It works. I give it my blessing (for whatever that's worth!). I've forgotten who had put it together and where it's hosted - does anyone remember??
Re: A semi-annual poke about progress
>Are you still sheparding this project? I remembered to look at Rather poorly, but yes (well, I just got back from a two week vacation in Europe). >http://savannah.nongnu.org/projects/nmh > >I noticed that there are outstanding bugs - I haven't had a chance to look >at the reports. Do you need help with them? Yes, please. If you want to sign up as an nmh developer, I will gladly add you to the project right after you tell me your savannah userid :-) --Ken
Re: A semi-annual poke about progress
>Hi. Seems like we've had a 1.1 release candidate sitting for a long >time. Can we make it a release yet? It would be nice to have something >newer than 1.0.4 going into things like Linux distributions. Hm, well ... how about everyone (including me) makes sure what's on the 1.1 branch compiles on all of the major platforms that they have access to, and if the answer is "yes", then we call the head of the 1.1 branch "1.1 final" ? --Ken
Re: A semi-annual poke about progress
I have it working on Solaris (albeit an old 2.6) and Linux RH9. > >Hi. Seems like we've had a 1.1 release candidate sitting for a long > >time. Can we make it a release yet? It would be nice to have something > >newer than 1.0.4 going into things like Linux distributions. > > Hm, well ... how about everyone (including me) makes sure what's on the > 1.1 branch compiles on all of the major platforms that they have access > to, and if the answer is "yes", then we call the head of the 1.1 branch > "1.1 final" ? > > --Ken
Re: A semi-annual poke about progress
On Monday 02 June 2003 04:40 pm, you wrote: > >Hi. Seems like we've had a 1.1 release candidate sitting for a long > >time. Can we make it a release yet? It would be nice to have something > >newer than 1.0.4 going into things like Linux distributions. > > Hm, well ... how about everyone (including me) makes sure what's on the > 1.1 branch compiles on all of the major platforms that they have access > to, and if the answer is "yes", then we call the head of the 1.1 branch > "1.1 final" ? > > --Ken A quick check: SunOS (yes, I run a department of Computer Antiquities) fails, many functions missing from the libraries (strerror, vnsprintf, snprintf). I suggest that this be ignored. Mandrake Linux 8.1 - no problems (and I've been using it since Aug 2002). Mandrake Linux 9.1 - the ndbm.h file has been moved to /usr/include/gdbm, so the compile of slocal.c bombs; the link of slocal needs -lgdbm added. No other problems after correcting location of include files and referencing the library. This should be able to be fixed in the configure script. Solaris 8 - test for broken 'vi' hangs in execution of 'ex', when package SMCvim (vim-6.0-sol8-sparc-local) from SunFreeware is installed. Required installation of autoconf-2.13 and m4-1.4 for make to start. Compiles until the 'man' directory, and then: make: Fatal error in reader: Makefile, line 75: Unexpected end of line seen Current working directory /export/home/glenn/nmh-1.1-RC1/man 15 secs of looking at line 75 of the makefile doesn't reveal much to me: MAN5 := $(MAN5SRC:.=.$(manext5)) Do I have to test it on all these platforms, too? (just kidding...) You have waited to long to release this stuff. Now we have to fix it... Clues on what the test for 'broken vi' does are solicited.
Re: A semi-annual poke about progress
Glenn Burkhardt <[EMAIL PROTECTED]> wrote: >Clues on what the test for 'broken vi' does are solicited. The "vi" on some systems (including solaris) returns a non-zero exit status if any command at all failed during the vi session. Presumably this makes sense if vi is running in the background from a response file. Anyway, nmh ignores vi exit codes on such systems. -NWR
Solaris 8 build
The makefile in the 'man' directory works with GNU make, but not Sun make (/usr/ccs/bin/make). What's the preferred solution here? Require GNU make? If so, shouldn't the configure script check for its presence, and set execution paths accordingly?
Solaris 'vim' configure bug
If vim 6.0 is installed on a Solaris system, the 'ex' program included with vim 6.0 goes into an infinite loop when this statement in 'configure' is executed: if echo 'r /nonexist-file q' | ex > /dev/null 2>&1 It seems wrong to me to include a newline in the string this way. It could be re-written as: echo 'r /nonexist-file\nq' | ex > /dev/null 2>&1 This works with vim 6.0 and both bash and the Solaris release of 'sh'. Should 'configure.in' be changed this way to make it work?
Re: Solaris 'vim' configure bug
Sorry, spoke too soon. The real problem has to do with output redirection. if echo 'r /nonexist-file q' | ex works but if echo 'r /nonexist-file q' | ex > /dev/null 2>&1 hangs. Redirecting just standard output cause no problem. But there doesn't seem any output to redirect anyway...
Re: Solaris 'vim' configure bug
On 2 June 2003 at 22:13, Glenn Burkhardt <[EMAIL PROTECTED]> wrote: > if echo 'r /nonexist-file > q' | ex > /dev/null 2>&1 > > It seems wrong to me to include a newline in the string this way. It could be > re-written as: > > echo 'r /nonexist-file\nq' | ex > /dev/null 2>&1 Unless I'm missing something, both make exactly the same output: $ echo 'r /nonexist-file q' | od -c 000 r / n o n e x i s t - f i l e 020 \n q \n 023 $ echo 'r /nonexist-file\nq' | od -c 000 r / n o n e x i s t - f i l e 020 \n q \n 023 And the first one has the advantage that it should work on *all* Bourne shells and all systems, whether the particular version of echo will translate \n to a newline or not. Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
Re: Solaris 'vim' configure bug
>echo 'r /nonexist-file\nq' | ex > /dev/null 2>&1 > >This works with vim 6.0 and both bash and the Solaris release of 'sh'. >Should 'configure.in' be changed this way to make it work? When I last tried something like that (in something else), I discovered that "\n" wasn't portable. Perhaps the best thing is something like: cat <<'EOC' | ex > /dev/null 2>&1 r /nonexist-file q EOC or perhaps (echo 'r /nonexist-file'; echo 'q') | ex > /dev/null 2>&1 --Ken
Re: Solaris 'vim' configure bug
Hi, > if echo 'r /nonexist-file > q' | ex > > works but > > if echo 'r /nonexist-file > q' | ex > /dev/null 2>&1 > > hangs. > > Redirecting just standard output cause no problem. But there doesn't > seem any output to redirect anyway... Can you use strace on Solaris to see what ex is actually doing? Cheers, Ralph.
Re: Solaris 'vim' configure bug
Date:Mon, 2 Jun 2003 22:23:17 -0400 From:Glenn Burkhardt <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | Redirecting just standard output cause no problem. But there doesn't | seem any output to redirect anyway... On NetBSD Error: script, 1: /nonexist-file: No such file or directory gets sent to stdout, so the stdout redirection is needed. All versions of "ex" should generate some kind of error (unless of course you just happen to have a "/nonexist-file" in your filesys). I can imagine the output being on stderr on some systems, perhaps. kre
