Re: env
[EMAIL PROTECTED] writes: > Except give it a different name, lest it be confused with the > command, mhpath. I'm not sure this is a real concern. All the MH environment variables that correspond to mh-profile parameters are named by upcasing the parameter name and prepending "MH", e.g. MHCONTEXT and MHPATH. It would be more damaging to deviate from this practice. -- Eric Gillespie <*> [EMAIL PROTECTED] Build a fire for a man, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -Terry Pratchett
Re: env
Jerrad Pierce <[EMAIL PROTECTED]> writes: > 1) The man pages seem to neglect to mention the various environment >variables used by nmh such as $MH. Eh? mh-profile(5) "Environment Variables" covering these (starting at line 574 in mh-profile.man). > 2) What about an environment variable MHPATH; equivalent to and higher >priority than Path: in a profile? >This way one could use a single profile >(and thusly not worry about keeping them synchronized) >to manage multiple message trees. Sounds like a good idea to me. -- Eric Gillespie <*> [EMAIL PROTECTED] Build a fire for a man, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -Terry Pratchett
Re: The continuing install-mh saga
Jon Steinhart <[EMAIL PROTECTED]> writes: > Also, I didn't mean to start a flame war with my questions > about the code. It's my opinion that nmh has about twice as > much code as is really needed to do the job. That excess > fluff makes the code harder to understand and maintain. So > I'm gonna trim it out whenever I see it. Not to show off, > but to make the code easier to deal with. If you want something to do as far as duplication reduction goes, check out mhbuildsbr.c and mhparse.c. Have a barf bag handy. -- Eric Gillespie <*> [EMAIL PROTECTED] Build a fire for a man, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -Terry Pratchett
Re: Working on the install-mh change questions
Eric Gillespie <[EMAIL PROTECTED]> writes: > I just checked Harbison & Steele, and according to them ISO C > does not allow calls to putenv to modify the getenv return > value, and as seen above, nor does POSIX (though the XSI > extension does). Maybe i'm just not very imaginative at this > late hour, but i don't see another way to implement the > environment without putenv modifying it, so i find it strange > that the two important standards don't allow for it. Just thought of one, though perhaps not the most obvious. POSIX and ISO C *do* mention static buffers; a getenv implementation can copy from the environment array into its own static buffer, extending it if necessary (subsequent getenv buffers may invalidate old ones, i.e. return addresses of newly allocated buffers). Then putenv calls wouldn't invalidate the getenv return value. -- Eric Gillespie <*> [EMAIL PROTECTED] Build a fire for a man, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -Terry Pratchett
Re: Working on the install-mh change questions
Greg Hudson <[EMAIL PROTECTED]> writes: > The return value of getenv() is a pointer into the environment; a future > getenv() call will not overwrite it. So it's safe not to copy it unless > you anticipate a putenv(). (And I think it's safe even in the face of a > putenv(), actually.) A judgement call. Not according to the new POSIX/SUSv3 (and i suspect the original POSIX): http://www.opengroup.org/onlinepubs/007904975/functions/getenv.html The return value from getenv() may point to static data which may be overwritten by subsequent calls to getenv(), [CX] [Option Start] setenv(), or unsetenv(). [Option End] [XSI] [Option Start] On XSI-conformant systems, the return value from getenv() may point to static data which may also be overwritten by subsequent calls to putenv(). [Option End] If you think about it, that makes sense. The environment is an array of pointers to character buffers, and since what putenv(3) stores for FOO is often larger than the size of the original FOO, it will need to get a larger buffer at a different address, invalidating the original returned address. I just checked Harbison & Steele, and according to them ISO C does not allow calls to putenv to modify the getenv return value, and as seen above, nor does POSIX (though the XSI extension does). Maybe i'm just not very imaginative at this late hour, but i don't see another way to implement the environment without putenv modifying it, so i find it strange that the two important standards don't allow for it. Bleh, i hope that made sense. sleep... -- Eric Gillespie <*> [EMAIL PROTECTED] Build a fire for a man, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -Terry Pratchett
Re: Working on the install-mh change questions
Jon Steinhart <[EMAIL PROTECTED]> writes: > This is one of those places where we'll have to respectfully disagree. I'm Respectfully? You imply i am not a professional. > but I think that programming is still something that should be done by > professionals. I don't want someone hacking on code that doesn't take the ti > me > to figure out what's going on first. Protecting against the really silly > mistakes allows such people to make really complex ones. As I said in my Give me a break. You want to pull the Real Man argument, fine, but don't call yourself a professional. Real Men make mistakes too, and don't tell me you've never slapped yourself on the head as you realize it was a tiny silly error all along. You come off sounding inexperienced more than anything else. It is this kind of idiocy that kept a debugger out of Linux for so many years: Linus is a Real Man and Real Men don't need debuggers. Aside from that, here's something you didn't think of. There *are* "unprofessional" programmers out there in the open source world. Hobbyists, i call them, since i don't go in for classism and value hobbyists as much as "professionals", not least because they're often less arrogant and more willing to learn than my fellow "professionals". What, you still want more? OK, there is the class i fall into. A "professional" who doesn't get to do much (if any) free software work at the job. When i come home i'm tired and much more likely to be tripped up by silly errors like the one i postulated. Would you rather do without my contributions? Too flamey? Possibly. Uncalled for? Absolutely not. I see this crap all the time and i am tired of it. But you know what really drives me up the wall? I deal with people like you every day in the "professional" world. Arrogant, stupid people who don't like any redundancy or "wasted" effort at all. The reductionist approach inevitably leads to mistakes. *It* is sloppy, not careful, explicit, *maintainable* code. Earlier today i was reminded of a quote from Londo Mollari, of Babylon 5. Hilarious that i was reminded of it today, in light of the drivel i am responding to now. "Ah! Arrogance and stupidity in the same package, how efficient of you!" > Oh, some details. Snipped because they are inconsequential to this follow-up. It appears you were correct in this specific case (i do not have the time to double-check you, but i trust you). It is the attitude you have that concerns me. -- Eric Gillespie <*> [EMAIL PROTECTED] Build a fire for a man, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -Terry Pratchett
Re: install-mh location
Jon Steinhart <[EMAIL PROTECTED]> writes: > By the way, should the manual page be changed from section 8 to section 1? Holy crap, yes. Even when it was in libexecdir the man page did not belong in section 8. -- Eric Gillespie <*> [EMAIL PROTECTED] Build a fire for a man, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -Terry Pratchett
Re: install-mh location
Neil W Rickert <[EMAIL PROTECTED]> writes: > >But, install-mh is not likely to be in the user's path; > >it's in the lib directory. Should I change the > >installation to move this to the bin directory or to > >make a link from the bin to the lib directory? > > Make a sym-link, or put in a shell script. Why? It's an obvious end-user program, especially now. It belongs in bindir. I doubt much if anything uses the old path (mh-e might, but note that it is still alive and kicking, arguably more so than nmh itself), so i say don't even bother with a backwards compatability symlink, but if you must have one the link goes in libexecdir. -- Eric Gillespie <*> [EMAIL PROTECTED] Build a fire for a man, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -Terry Pratchett
Re: Another working on the install-mh change question
Jon Steinhart <[EMAIL PROTECTED]> writes: > sbr/context_read does a complicated check for installation involving first > the MH environment variable and second the default profile. I was surprised > to discover that uip/install-mh does not perform identical tests. It just > looks for the default profile. This seems wrong to me. Should I fix it? Yes. -- Eric Gillespie <*> [EMAIL PROTECTED] Build a fire for a man, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -Terry Pratchett
Re: Working on the install-mh change questions
Jon Steinhart <[EMAIL PROTECTED]> writes: > 3.If the $HOME environment variable is set, mypath is copied from the > getenv return. Why? It's never changed. > > 4.If the $HOME environment variable is not set, mypath is copied from the > pw_dir member of the returned passwd structure. Now, I understand that > this is a static structure, but getpwuid is never called again so I > don't see why the copy is needed. > > 4.If the $HOME environment variable is not set, the pw_dir member of the > passwd structure returned by getpwuid() is checked for a NULL pointer. > This can never happen in a non-error return, which is already checked. > So why the superfluous check? These checks are not superflous, they are for maintainability. Two years from now someone will add a second getenv(3) call and waste their (probably volunteer) time trying to figure out how they busted the home dir variable. That is why, unless you are writing super-tight-must-be-the-best-performing-code-ever applications (which mh is not), it is necessary always to make a copy of the static buffer pointed to by the return values of such functions. -- Eric Gillespie <*> [EMAIL PROTECTED] Build a fire for a man, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -Terry Pratchett
Re: Appropriateness of new program/feature
Jon Steinhart <[EMAIL PROTECTED]> writes: > Howdy. I've been working on a companion mail reading system > for nmh. In short, this is a system that builds a database > from mail in folders, allowing it to be searched quickly. It > includes a ranking mechanism, and allows messages to be > searched by rank. This sounds very interesting. > Sort of like the current fad of Bayesian spam filters, but more > general. I would not call Bayesian filtering a fad. > But, there's one more sticky point. There's no good way to test whether > or not nmh is installed. When I set up my program, I want to fail with > an error message if the user hasn't set up a mail directory, etc. Is test -d `mhparam Path` sufficient for your needs? -- Eric Gillespie <*> [EMAIL PROTECTED] Build a fire for a man, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -Terry Pratchett
Re: [PATCH] Darwin/Mac OS X Support
Shantonu Sen <[EMAIL PROTECTED]> writes:
> The extra linker flags are neither necessary, nor appropriate. Two-level
> namespace is the one true way, especially for projects that don't
"one true way"? PLONK
> What cpp-precomp errors did you see? My build log shows no errors where it
> have to revert to the non-precomp cpp.
None, now that i take a closer look. You were correct about this
being a knee-jerk response; it was a problem with so many other
packages i try to build on OS X.
> doesn't compile. And in this case, nmh *does* compile cleanly on 10.1.3.
Apparently not; i have 10.1.3.
0 nmh% uname -a
Darwin argo.pretzelnet.org 5.3 Darwin Kernel Version 5.3: Thu Jan 24 22:06:02 PST
2002; root:xnu/xnu-201.19.obj~1/RELEASE_PPC Power Macintosh powerpc
> What problem are these patches solving?
See attached build logs.
--
Eric Gillespie <*> [EMAIL PROTECTED]
Conformity is a sin.
Script started on Fri May 3 11:52:56 2002
]2;epg@argo:/usr/local/src/nmh]2;epg@argo:/usr/local/src/nmh
[m[23m[24m[J[0;36m0 nmh%[0;0m [Kccat ../configure/nmh
#! /bin/sh
CFLAGS=-g
export CFLAGS
./configure --prefix=/usr/local \
--bindir=\${prefix}/bin/mh \
--libdir=\${prefix}/lib/nmh \
--sysconfdir=\${prefix}/etc/nmh \
--with-smtpservers=mail.pretzelnet.org
]2;epg@argo:/usr/local/src/nmh
[m[23m[24m[J[0;36m0 nmh%[0;0m
[K.../configure/nmh
creating cache ./config.cache
checking host system type... powerpc-apple-darwin5.3
checking target system type... powerpc-apple-darwin5.3
checking build system type... powerpc-apple-darwin5.3
configuring for nmh-1.0.4+dev
configuring for nmh dated 30 Dec 2000
checking for gcc... no
checking for cc... cc
checking whether the C compiler (cc -g ) works... yes
checking whether the C compiler (cc -g ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether cc accepts -g... yes
checking for working const... yes
checking whether make sets ${MAKE}... yes
checking for a BSD compatible install... /usr/bin/install -c
checking for ranlib... ranlib
checking for mawk... no
checking for gawk... no
checking for nawk... no
checking for awk... awk
checking for flex... flex
checking for yywrap in -lfl... no
checking for cut... /usr/bin/cut
checking for lclint... no
checking for lint... no
checking for libtool... libtool
checking for lorder... lorder
checking for tsort... tsort
checking whether tsort can deal with loops... yes
checking for ls... /bin/ls
checking how to get ls to show us the group ownership of a file... -l
checking for more... /usr/bin/more
checking for sendmail... /usr/sbin/sendmail
checking for vi... /usr/bin/vi
checking for broken vi... yes
checking where mail spool is located... /var/mail
checking whether the mail spool is world-writable... no
checking how to run the C preprocessor... cc -E -traditional-cpp
checking for lockfile.h... no
checking for dotlockfile... no
checking what group owns the mail spool... mail
checking for dirent.h that defines DIR... yes
checking for opendir in -ldir... no
checking for ANSI C header files... yes
checking whether time.h and sys/time.h may both be included... yes
checking for sys/wait.h that is POSIX.1 compatible... yes
checking whether stat file-mode macros are broken... no
checking for string.h... yes
checking for memory.h... yes
checking for stdlib.h... yes
checking for unistd.h... yes
checking for errno.h... yes
checking for fcntl.h... yes
checking for limits.h... yes
checking for crypt.h... no
checking for termcap.h... no
checking for termio.h... no
checking for termios.h... yes
checking for locale.h... yes
checking for netdb.h... yes
checking for sys/param.h... yes
checking for sys/time.h... yes
checking for sys/utsname.h... yes
checking for arpa/inet.h... yes
checking for arpa/ftp.h... yes
checking POSIX termios... yes
checking TIOCGWINSZ in termios.h... yes
checking for libio.h... no
checking for sys/ptem.h... no
checking for pid_t... yes
checking for vfork.h... no
checking for working vfork... yes
checking for mkstemp in -lmkstemp... no
checking for waitpid... yes
checking for wait3... yes
checking for sigaction... yes
checking for sigprocmask... yes
checking for sigblock... yes
checking for sigsetmask... yes
checking for sighold... no
checking for sigrelse... no
checking for writev... yes
checking for lstat... yes
checking for uname... yes
checking for tzset... yes
checking for killpg... yes
checking for mkstemp... yes
checking for sethostent... yes
checking for getutent... no
checking for gethostbyname... yes
checking for sigsetjmp... yes
checking for snprintf... yes
checking for strerror... yes
checking for strdup... yes
checking for modf... yes
checking for gethostbyname... (cached) yes
checking for socket... yes
checking for tgetent in -ltermcap... no
ch
[PATCH] Darwin/Mac OS X Support
Below is a patch necessary to support Mac OS X. -no-cpp-precomp is necessary to turn off Apple's broken header pre-compilation cpp and use standard gcc cpp instead. The extra LDFLAGS are necessary in order to avoid linking errors (libraries are much different in Darwin than on other operating systems). -- Eric Gillespie <*> [EMAIL PROTECTED] Conformity is a sin. Index: configure.in === RCS file: /cvs/nmh/configure.in,v retrieving revision 1.61 diff -a -u -r1.61 configure.in --- configure.in2001/03/17 11:28:28 1.61 +++ configure.in2002/04/28 07:35:30 @@ -798,6 +798,10 @@ dnl case "$target_os" in + darwin*) +CPPFLAGS="$CPPFLAGS -no-cpp-precomp" +LDFLAGS="$LDFLAGS -flat_namespace -undefined suppress" +;; solaris2*) AC_DEFINE(SYS5) AC_DEFINE(SVR4)
