gonzo@opal.cs.tu-berlin.de (SfR.) (06/14/91)
hallo I am not going to use NeXT mail any more. Does anybody know if elm is available in source or NeXT binaries anywhere on the ftp hosts? Thanks SfR -- gonzo@tub.uucp gonzo@tub.cs.tu-berlin.de
eps@toaster.SFSU.EDU (Eric P. Scott) (06/15/91)
In article <3749@opal.cs.tu-berlin.de> gonzo@tub.cs.tu-berlin.de (SfR.) writes: > Does anybody know if elm is available in source > or NeXT binaries anywhere on the ftp hosts? elm has a Configure script ==> choices made here are frozen in the compiled code. You don't want binaries. Note that the current official elm release (2.3PL11) will not compile "out of the box" on NeXT computers. So far, the ELM Development Group has REFUSED to fix their distribution, claiming that everyone's hopes, wishes, desires, etc. will be answered by the 2.4 release--which has been delayed until the fall. So, I'm once again posting the attached set of UNOFFICIAL patches, which are applicable to ALL machines running elm--not just NeXTs. The "patch" utility can be obtained from archive sites; a NeXT binary is available from sutro.sfsu.edu [130.212.15.230] in pub/patch.Z; this is a compressed executable compiled under 1.0 and linked with shared libraries, so it will work on 1.0-2.1 systems. -=EPS=- ------- This is a reposting, updated for NeXT 2.0/2.1 users. The following unofficial patch is for ELM 2.3PL11 Fix: From rn, say "| patch -p -N -d DIR" where DIR is your elm source directory. Outside of rn, say "cd DIR; patch -p -N <thisarticle" Priority (NONE) . Change default sort order for compatibility with other MUAs (MED) . Fix ~v to properly invoke vi when elm is configured to use "builtin" or "none" as the default editor (MED) . Even if already_has_text is true, if the alternate_editor is "builtin" or "none" don't try to shell to it (HIGH) . Eliminate conflict with NeXT shared library (LOW) . Avoid creating extraneous process from ~! shell escape I strongly encourage the Elm Development Group to incorporate the last four parts in the next official patch. The first is purely a site preference. This does not include fixes to Configure for NeXT workstations. When running Configure on a NeXT... ...on 1.0/1.0a systems: For "Any additional cc flags?" specify -bsd For "Any additional libraries?" specify -lsys_s At "If you need to edit config.sh, do it as a shell escape here:" Change d_voidsig from 'define' to 'undef' Change passcat from 'cat /etc/passwd' to 'nidump passwd /' if you're not using YP/NIS, and don't have more than two levels of NetInfo hierarchy. (Consult a NeXTpert otherwise!) ...on 2.0/2.1 systems: same as above, except For "Any additional libraries?" just hit RETURN For "What is the full name of your C library?" specify /lib/libsys_s.a -=EPS=- ------- Index: hdrs/elm.h Prereq: 4.1.1.1 *** hdrs/elm.h.orig --- hdrs/elm.h *************** *** 142,148 **** int prompt_for_cc = 1; /* flag: ask user for "cc:" value? */ int sig_dashes = 1; /* flag: include dashes above sigs? */ ! int sortby = REVERSE SENT_DATE; /* how to sort incoming mail... */ long timeout = 600L; /* timeout (secs) on main prompt */ --- 142,148 ---- int prompt_for_cc = 1; /* flag: ask user for "cc:" value? */ int sig_dashes = 1; /* flag: include dashes above sigs? */ ! int sortby = MAILBOX_ORDER; /* how to sort incoming mail... */ long timeout = 600L; /* timeout (secs) on main prompt */ Index: hdrs/sysdefs.SH Prereq: 4.1.1.3 *** hdrs/sysdefs.SH.orig --- hdrs/sysdefs.SH *************** *** 100,105 **** --- 100,106 ---- #define readmsg_file ".elm/readmsg" #define emacs_editor "$emacs" + #define vi_editor "$vi" #define default_editor "$defeditor" #define mailhome "$maildir/" Index: src/editmsg.c Prereq: 4.1.1.4 *** src/editmsg.c.orig --- src/editmsg.c *************** *** 76,82 **** buffer[0] = '\0'; if (strcmp(editor, "builtin") == 0 || strcmp(editor, "none") == 0) { ! if (already_has_text) sprintf(buffer, "%s %s", alternative_editor, filename); else return(no_editor_edit_the_message(filename)); --- 76,83 ---- buffer[0] = '\0'; if (strcmp(editor, "builtin") == 0 || strcmp(editor, "none") == 0) { ! if (already_has_text && strcmp(alternative_editor, "builtin") && ! strcmp(alternative_editor, "none")) sprintf(buffer, "%s %s", alternative_editor, filename); else return(no_editor_edit_the_message(filename)); *************** *** 255,261 **** case 'v' : NewLine(); strcpy(buffer, editor); ! strcpy(editor, default_editor); fclose(edit_fd); (void) edit_the_message(filename,0); strcpy(editor, buffer); --- 256,262 ---- case 'v' : NewLine(); strcpy(buffer, editor); ! strcpy(editor, vi_editor); fclose(edit_fd); (void) edit_the_message(filename,0); strcpy(editor, buffer); *************** *** 305,311 **** if (( old_raw = RawState()) == ON) Raw(OFF); if (strlen(buffer) < 3) ! (void) system_call(shell, USER_SHELL, TRUE, TRUE); else (void) system_call((char *) buffer+2, USER_SHELL, TRUE, TRUE); if (old_raw == ON) --- 306,312 ---- if (( old_raw = RawState()) == ON) Raw(OFF); if (strlen(buffer) < 3) ! (void) system_call((char *)NULL, USER_SHELL, TRUE, TRUE); else (void) system_call((char *) buffer+2, USER_SHELL, TRUE, TRUE); if (old_raw == ON) Index: src/opt_utils.c Prereq: 4.1 *** opt_utils.c.orig --- opt_utils.c Fri *************** *** 186,192 **** #endif ! #if defined(BSD) && !defined(_POSIX_SOURCE) /** some supplementary string functions for Berkeley Unix systems **/ --- 186,192 ---- #endif ! #if defined(BSD) && !defined(_POSIX_SOURCE) && !defined(NeXT) /** some supplementary string functions for Berkeley Unix systems **/ Index: sys/syscall.c Prereq: 4.1.1.4 *** src/syscall.c.orig --- src/syscall.c *************** *** 218,224 **** #endif /* Go for it. */ ! execl(sh, argv_zero(sh), "-c", string, (char *) 0); /* If exec fails, we write a byte to the pipe before exiting. */ perror(sh); --- 218,225 ---- #endif /* Go for it. */ ! if (string) execl(sh, argv_zero(sh), "-c", string, (char *) 0); ! else execl(sh, argv_zero(sh), (char *) 0); /* If exec fails, we write a byte to the pipe before exiting. */ perror(sh);
syd@DSI.COM (Syd Weinstein) (06/15/91)
eps@toaster.SFSU.EDU (Eric P. Scott) writes: >Note that the current official elm release (2.3PL11) will not >compile "out of the box" on NeXT computers. That is a surprise to many of those on NeXT's who are running the copy right out of the box with no changes at all. >So far, the ELM >Development Group has REFUSED to fix their distribution, claiming >that everyone's hopes, wishes, desires, etc. will be answered by >the 2.4 release--which has been delayed until the fall. So, I'm >once again posting the attached set of UNOFFICIAL patches, which >are applicable to ALL machines running elm--not just NeXTs. Please note that some of his patches, are personal choices, not necessarly bugs. And yes, I, have made the decision, not to release any more fixes to Elm (unless there is a catastrophic problem that causes Elm to loose mail) until the 2.4 release. And I highly doubt "that everyone's hopes, wishes, desires, etc will be answered by the 2.4 release." I am sure that most peoples desires will not. I will note, that he had sent us this patch before for our reference and we did look into things in it for the 2.4 release. -- ===================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator Datacomp Systems, Inc. Voice: (215) 947-9900 syd@DSI.COM or dsinc!syd FAX: (215) 938-0235
eps@toaster.SFSU.EDU (Eric P. Scott) (06/16/91)
In article <1991Jun15.150250.16883@DSI.COM> syd@DSI.COM writes: >That is a surprise to many of those on NeXT's who are running the >copy right out of the box with no changes at all. They're not running 2.0/2.1. It doesn't link. >Please note that some of his patches, are personal choices, >not necessarly bugs. Which I have so indicated. > And yes, I, have made the decision, not >to release any more fixes to Elm (unless there is a catastrophic >problem that causes Elm to loose mail) until the 2.4 release. >I will note, that he had sent us this patch before for our reference >and we did look into things in it for the 2.4 release. Which is still months away. Some of us like elm, want to run it now, but are stymied by a distribution that doesn't work. My fixes have been tested on a variety of platforms, and have been in production for several months; they don't break anything, and they enable some who couldn't otherwise use the package to enjoy it. I don't understand your reluctance to maximize elm's acceptance. (Tacit NeXT-bashing?) -=EPS=-