Re: Mail. Mail! Mail?
Bernard Leak <[EMAIL PROTECTED]> writes: > To submit the output of a gcc test run to the relevant mailing list, > I'm enjoined to run an obfuscated script and pipe the output to sh. > Fine - but then it tells me (actually, the docs said this already) > that I need "the Mail program" in my path. Not wanting to be > obstructive or anything, but ... wot? This program should have been included with your operating system (I am assuming you are using a Unix variant). Not having it indicates a monumental error in the packaging or installation of your OS. To quote the Debian policy manual: If the expectation is that an experienced Unix person who found [a program] missing would say "What on earth is going on, where is 'foo'?", it must be an important package. and indeed the Debian package that provides /usr/bin/Mail, 'mailx', is priority important. I shall also quote its description: mailx is the traditional command-line-mode mail user agent. Even if you don't use it it may be required by other programs. Now, GNU Mailutils does provide an implementation of the program that the test-result script is looking for, so you're good there. ... > Now it wants 'sendmail'. ExCUSE me! I need to have *sendmail* > installed in order to submit a test report? Perhaps more to the > point, am I required to have *configured* it? Yes, and yes. However, this doesn't mean what you probably think. There are two different things called "sendmail". There is the (in)famous program written by Eric Allman, with the write-only configuration file, formerly used by almost everyone for mail transport. There is also the standard Unix low-level interface for sending mail, /usr/sbin/sendmail. That interface is implemented by Allman's sendmail, but also by many other alternatives, many of which are considered to be better, or at least to have less painful configuration files. Examples include exim, postfix, and qmail. The gcc test result script (via Mail) expects the /usr/sbin/sendmail interface, but not Allman's implementation. You can install whatever mail transport agent you prefer. Again, not having an MTA installed indicates a monumental error in the packaging or installation of your OS. You should have gotten all this stuff automatically, and the installation sequence should have prompted you for mail information and then set up the MTA for you. zw
Re: Mail. Mail! Mail?
Zack Weinberg wrote: > Bernard Leak <[EMAIL PROTECTED]> writes: > > Fine - but then it tells me (actually, the docs said this already) > > that I need "the Mail program" in my path. Not wanting to be > > obstructive or anything, but ... wot? > > This program should have been included with your operating system (I > am assuming you are using a Unix variant). Not having it indicates a > monumental error in the packaging or installation of your OS. > mailx is the traditional command-line-mode mail user agent. > Even if you don't use it it may be required by other programs. Just to add to Zack's fine answer and to tie some of these things together. In the old, old days the program /bin/mail was a simple command line mail program. Functional. But very stark. No way to specify a -s "subject string" on the command line for example. BSD added to this program and many others. They called their mail program "mail" as well and installed it in /usr/ucb/mail IIRC. Having the same program names worried others. So the program was also called called "Mail" to differentiate it from "/bin/mail". The 1994 Makefile installs the program as both "mail" and "Mail". http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/mail/Makefile?rev=1.1&content-type=text/x-cvsweb-markup But having a program name which only differed by case bothered AT&T and so in SysV they called the program "mailx". This was distributed to most of the commercial unix systems of the day such as HP-UX where mailx is found but Mail is not. In the old days (old, not old old) everyone used either Mail or mailx depending on whether they were running a BSD or a SysV flavor system. Mail/mailx was vastly superior to /bin/mail. I used mailx for years. I know people who still only use mailx for mail. Habits die hard. POSIX has generally favored SysV and standardized on the "mailx" name and functionality. POSIX standard system are required to supply a "mailx" program. http://www.opengroup.org/onlinepubs/009695399/utilities/mailx.html In response the *BSD generally include a symlink to all three "mail", "Mail" and "mailx" for compatibility. Debian supplies both for compatibility to either too. However RH only supplies Mail and do not supply mailx and miss on POSIX compatibility. And the reverse compatibility with BSD when HP-UX supplies only mailx and does not supply a Mail program. So you may have to switch from one to the other name for this functionality because it is used by a lot of scripts and programs. > > Now it wants 'sendmail'. ExCUSE me! I need to have *sendmail* > > installed in order to submit a test report? Perhaps more to the > > point, am I required to have *configured* it? > [...] > There is also the standard Unix low-level interface for sending > mail, /usr/sbin/sendmail. Agreed. /usr/sbin/sendmail is a defacto standard interface to a generic Mail Transport Agent for sending mail. Also used by a lot of scripts and programs. > Again, not having an MTA installed indicates a monumental error in the > packaging or installation of your OS. You should have gotten all this > stuff automatically, and the installation sequence should have > prompted you for mail information and then set up the MTA for you. Agreed. However if you are working in some port environment you may be trying to bootstrap these things along and may want/need gcc to get other components bootstrapped. You may not have a working system to begin with. If you are trying to make progress regardless of the system problems you can probably replicate the Mail/mailx functionality. It reads standard input. It mails the contents to the address provided on the command line. The "-s" option sets the subject. I do not think any other options are used. As long as you do that then you can fake things out with a replicant. Bob
Re: Mail. Mail! Mail?
[EMAIL PROTECTED] (Bob Proulx) writes: > However if you are working in some port environment you may be > trying to bootstrap these things along and may want/need gcc to get > other components bootstrapped. You may not have a working system to > begin with. This is true, and we could improve the test-summary script to make life easier for people in limited environments. One obvious improvement would be to have a mode where the script simply dumps the summary to a file, without the shell goo surrounding it. The human doing the testing can then copy it into their preferred mail client (which may well be on a different system). Another possible improvement would be to invoke sendmail directly, instead of indirecting through Mail, thus reducing by one the number of functional programs required for the script to work. zw
Re: Mail. Mail! Mail?
References: <427E8378.1010309 at brenda-arkle dot demon dot co dot uk><873bsxbclc.fsf at codesourcery dot com><20050508225133.GA2890 at dementia dot proulx dot com><87r7gh9tmq.fsf at codesourcery dot com> Apologies if this has lost its "References" field - it shouldn't have done, but off-hand I can't work out how to verify it. Hence the line above (with mildly obfuscated addresses) My system has developed, for hysterical reasons, as a minimal installation of GNU/Linux on a P4. Minimal really was minimal - no networking, no X... Everything else has been added on demand. I managed to get my networking running with no problems without ever encountering mail, Mail, mailx, or any version of sendmail. Don't blame the distribution - but surely I'm not alone in my position? Nice as it is to know that "mailx" is what I wanted, and it is easily available, the docs didn't say "mailx", they said "Mail". "Mail" was unhelpful (I wasn't helped), and "mail" would not have been better. And, yes, I was misconstruing "sendmail" as referring to the Configuration Monster from Hell. Doubtless "an experienced Unix person" would not have been in this position, but that's not a great deal of help to me. Zack and Bob, however, *have* been helpful (thanks to both of you!), and in my darker and more cynical moments I suspect them of being experienced Unix persons themselves. The mere absence of Mail/sendmail wasn't the essence of my problem. A solution "by hand" was still possible. When feeding the script output to `sh' failed, I could (and did) spool it to a file instead, from which I could extract the inline data. The difficulty was rather that I couldn't find what executables I was expected to be using. This in turn introduced an unnecessary element of guesswork into the solution "by hand", which was bothering me. I didn't want to be sending junk to the mailing list. Now I know what I'm supposed to have been doing, the rest is relatively straightforward. Special system restrictions may make it impracticable to install the expected tools, but this is really a red herring. Can something be done to make the problem less obstructive? It's not obvious that the script should try to be too clever and work out which name to use. Mail looks as useful as any name it can have hard-coded. However, a comment could be added to the script *output*; something like if ! [ -x "`which Mail`" ]; then echo Modify the script, or set up a symlink, to use \`mailx\' echo if \`Mail\' doesn\'t exist: mailx and \`Mail\' should be echo synonyms. If neither is present, \`mail\' might work. echo mail from GNU mailtools should work. exit fi if ! [ -x /usr/sbin/sendmail ]; then echo This script may fail if \`/usr/sbin/sendmail\' is not available, echo depending on the version of \`Mail\' being used. echo This is NOT the very large MTA whose home is at echo http://www.sendmail.org. echo You may need to set up a symlink to an equivalent program. echo mail.remote from GNU mailtools should work. fi and it can be mentioned in the docs: something like You must have Mail in your path: Mail is (or can be made to be) an alias for mailx, which you should have. This requires /usr/sbin/sendmail, which is NOT the huge MTA from http://www.sendmail.org but something much smaller. GNU mailutils include versions of both, which will need to be renamed/linked. -- "Before they made me, they broke the mould" Bernard Leak
Re: Mail. Mail! Mail?
Bernard Leak wrote: [in reply to why by default an MTA should be installed in order to be able to send reports in the usual way] Special system restrictions may make it impracticable to install the expected tools, but this is really a red herring. Hmm... Installing an MTA, whatever its size may be, has the potential of introducing more work, more open ports, more firewall building, more following the associated securitiy advisories absent a firewall or not absent a firewall, more ... The optimistic (wrt opennes of the network) default installation settings of GNU/Linux distributions for example do not always reflect the default installation policy in every network. But typical mail sending programs can speak SMTP themselves, without the help of a local MTA. As much as I like to assume that GNUnix comes with (send)mail, an installation might thus have left them out for good reasons. In this case a hint like "c&p the report into a plain text message" or somesuch might really be helpful. Or a WWW report collector with a file upload input field? -- Georg
Re: Mail. Mail! Mail?
Georg Bauhaus <[EMAIL PROTECTED]> writes: > Installing an MTA, whatever its size may be, has the potential > of introducing more work, more open ports, more firewall building, > more following the associated securitiy advisories absent a firewall > or not absent a firewall, more ... Not at all. All modern MTAs can be configured, quite easily, in a 'dumb client' mode where they accept mail only from the local host -- they don't even open a network socket -- and forward all that mail to a designated 'smart hub'. (Terminology varies.) There are even programs, such as sSMTP and nullmailer, which have *only* this functionality. zw
Re: Mail. Mail! Mail?
Bernard Leak <[EMAIL PROTECTED]> writes: > My system has developed, for hysterical reasons, as a minimal > installation of GNU/Linux on a P4. Minimal really was minimal - no > networking, no X... Everything else has been added on demand. I > managed to get my networking running with no problems without ever > encountering mail, Mail, mailx, or any version of sendmail. Don't > blame the distribution - but surely I'm not alone in my position? Interesting. I would have expected you to have trouble with cron, which likes sending mail - or maybe you skipped it, too? > Zack and Bob, however, *have* been helpful (thanks to both of you!), > and in my darker and more cynical moments I suspect them of being > experienced Unix persons themselves. Aheh, yes, you could say that. > Can something be done to make the problem less obstructive? > It's not obvious that the script should try to be too clever and > work out which name to use. Mail looks as useful as any name > it can have hard-coded. However, a comment could be added > to the script *output* [... more useful suggestions ...] This is where I quietly mention that patches are welcome. zw
Re: Mail. Mail! Mail?
Zack Weinberg wrote: All modern MTAs can be configured, quite easily, in a 'dumb client' mode where they accept mail only from the local host -- Well, "easily" is arguable if you aren't a Unix sysadmin, and depending on the MTA... There are even programs, such as sSMTP which, not a month ago had bugs causing overflow vulnerability. ;-) and nullmailer, which have *only* this functionality. Good Thing, and improving. However, be sure to add a procedure to your network monitoring setup to inform you of risky bugs in network related software. And this is where work starts to be caused by the assumption that e.g. a GCC shell script can send reports using the Mail program using an MTA possibly involving inetd, ... -- Georg
Re: Mail. Mail! Mail?
Zack Weinberg wrote: > The gcc test result script (via Mail) expects the /usr/sbin/sendmail > interface, but not Allman's implementation. You can install whatever > mail transport agent you prefer. > Again, not having an MTA installed indicates a monumental error in the > packaging or installation of your OS. There is at least one serious distribution which has considered having no /usr/sbin/sendmail (or mailx) in a default installation: http://lists.ubuntu.com/archives/ubuntu-devel/2005-February/004207.html -M-
Re: Mail. Mail! Mail?
Matthew Woodcraft <[EMAIL PROTECTED]> writes: > There is at least one serious distribution which has considered having no > /usr/sbin/sendmail (or mailx) in a default installation: > > http://lists.ubuntu.com/archives/ubuntu-devel/2005-February/004207.html What a horrible idea. It's not just about LSB compliance - programs shouldn't have to implement their own SMTP senders, they should be able to rely on /usr/sbin/sendmail. (I personally go even farther, and consider any program [other than a dedicated MTA] which contains its own SMTP sender, rather than relying on /usr/sbin/sendmail, to be buggy.) This is no longer on-topic for gcc@, though. zw
Re: Mail. Mail! Mail?
Georg Bauhaus <[EMAIL PROTECTED]> writes: > Good Thing, and improving. However, be sure to add a procedure > to your network monitoring setup to inform you of risky bugs in network > related software. And this is where work starts to be caused by > the assumption that e.g. a GCC shell script can send reports > using the Mail program using an MTA possibly involving inetd, ... If you prefer you can do telnet relay smtp instead. :-) Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
RE: Mail. Mail! Mail?
Original Message >From: Zack Weinberg >Sent: 09 May 2005 19:38 > Bernard Leak writes: >> Can something be done to make the problem less obstructive? >> It's not obvious that the script should try to be too clever and >> work out which name to use. Mail looks as useful as any name >> it can have hard-coded. However, a comment could be added >> to the script *output* > [... more useful suggestions ...] > > This is where I quietly mention that patches are welcome. > > zw How about an option to format the output suitable for piping straight into "telnet mail.gnu.org 25"? cheers, DaveK -- Can't think of a witty .sigline today
RE: Mail. Mail! Mail?
On Tue, 2005-05-10 at 10:14 +0100, Dave Korn wrote: > Original Message > >From: Zack Weinberg > >Sent: 09 May 2005 19:38 > > > Bernard Leak writes: > > >> Can something be done to make the problem less obstructive? > >> It's not obvious that the script should try to be too clever and > >> work out which name to use. Mail looks as useful as any name > >> it can have hard-coded. However, a comment could be added > >> to the script *output* > > [... more useful suggestions ...] > > > > This is where I quietly mention that patches are welcome. > > > > zw > > > How about an option to format the output suitable for piping straight into > "telnet mail.gnu.org 25"? > At this point, you might as well rewrite it in Perl and require Mail::Mailer, or rewrite it in python, and use smtplib (which is in the python standard lib)
RE: Mail. Mail! Mail?
Original Message >From: Daniel Berlin >Sent: 10 May 2005 14:07 > On Tue, 2005-05-10 at 10:14 +0100, Dave Korn wrote: >> Original Message >>> From: Zack Weinberg >>> Sent: 09 May 2005 19:38 >> >>> Bernard Leak writes: >> Can something be done to make the problem less obstructive? It's not obvious that the script should try to be too clever and work out which name to use. Mail looks as useful as any name it can have hard-coded. However, a comment could be added to the script *output* >>> [... more useful suggestions ...] >>> >>> This is where I quietly mention that patches are welcome. >>> >>> zw >> >> >> How about an option to format the output suitable for piping straight >> into "telnet mail.gnu.org 25"? >> > > > At this point, you might as well rewrite it in Perl and require > Mail::Mailer, or rewrite it in python, and use smtplib (which is in the > python standard lib) I don't think that's a valid comparison. I would venture to suggest that telnet clients are far more universally installed than Mail::Mailer, or Python, or Perl, or quite likely even Mail. cheers, DaveK -- Can't think of a witty .sigline today
Re: Mail. Mail! Mail?
Dear List,
Firstly, thanks to Bob Proulx for the helpful pointer to the Debian
search widget. This is a genuinely useful-looking tool. How pleasing!
But unless he thinks this is another thing I should "just know about",
it's worth documenting *somewhere*. I don't suggest that the GCC
documentation should necessarily mention the Debian web-site
(indeed, it is surely better not to): but the GCC documentation left
me stuck over "Mail". with nowhere to go.
I think I haven't explained myself enough to Bob. I find myself wondering
how much would be "enough", and deeply, sincerely hope that this will be,
because I don't intend to add any more explanation!
I tried quite hard to find out the answers I needed before I first posted
my question. I don't see why this has to be construed as a proud terror
of exposing my ignorance. I didn't want to take up other people's time,
and solicit their help, merely from laziness - especially as other people
had obviously not experienced so much difficulty. I have not complained
that my difficulties should have been eliminated before I encountered
them. I am saying that I don't want anyone else to have them. Drawing a
complete blank would have been merely annoying. In fact, I came up with
useless false positives requiring tedious work to eliminate, and then I was
completely stuck. I wasted a significant amount of time not finding out
what I needed to know.
How difficult does it have to be to find something out before adding it
to the documentation looks like a benefit to other people? Is forcing me
(and any others in the same position later) to ask an unnecessary
question something to be encouraged, as an exercise in communal
living, or something? Do you all have too much time on your hands?
Is there any information you would like to delete from the documentation
on the same principle?
I'm not asking anyone to guess at things I might possibly not know and
explain them in the documentation. I am asking for two *specific* things
(which in fact I did not know) to be explained in the documentation,
because brute-force searching in "the obvious places" doesn't produce
the Right Thing, but can and does throw up misleading clues to the Wrong
Thing. "Mail" in particular is not the name of a GNU utility, but "mail"
is. The results submission script uses "Mail". My distribution has
"mailx", which completes the set of three! How confusing and inconsistent
does it have to be before it seems like a candidate for documentation?
Why is it overkill to note (if "Mail" is not found) that another name might
work instead? That was my suggestion: what's the objection? That it's
too helpful? Do you rot13 all your man pages?
I saw no reason to mention in my first posting that I'd already tried to
find "Mail" in the desktop command reference I happen to have to
hand ("Linux in a Nutshell", 4th Edition). I have now gone back to
check: the documentation for "mail" mentions neither "Mail" nor "mailx",
and I found no references to "Mail" or "mailx" in the index. I have
now gone over the "sendmail" documentation (apparently for Big
Sendmail). Zack Weinberger's first reply to me is still the only
indication I've ever noticed that there is more than one thing called
"sendmail".
If you have a lot of time to waste you might try finding "Mail" in
the Linux Documentation Project tree. You do have a lot of time
to waste, don't you? I mean, it *might* be in there. Somewhere.
Yes, I tried this at length before I gave up and made my posting.
Again, I didn't think there was much point in mentioning it.
Does Bob think that if I don't know that "Mail" = "mail" I am roughly
equally likely not to know about "cat" or "grep"? If so, he is clearly
looking down on me from a position of such altitude as to be quite
unable to recognise the problems the rest of us have. With grinding
explicitness: even if I mysteriously knew about neither, I would not
have needed to post a question to the mailing list. Leaving aside
"Linux in a Nutshell" - which of course documents both "cat" and
"grep" - I set myself an exercise this morning of trying to find
these widgets by name, with nothing but the name (and the fact
that they are commands of some sort found on UN*X-type systems).
"grep" was easy - the top-level reference page for GNU grep was
the first non-sponsored match from AltaVista. "cat" required a bit
more sloshing around, to separate it from references to furry
Superior Beings, but not much. But all this is besides the point.
If you think that there is a better place for the needed information,
by all means suggest it. If you think it's already documented
somewhere accessible, please tell me (and maybe refer to it in
the GCC documentation!). "Grope around in the Debian
distribution using their search tool" is a usable solution, but
not what I would call adequate documentation. "Run and find out"
is a good response in many cases, but this does not apply to "Mail",
because (go back to Start, do not pas
Re: Mail. Mail! Mail?
On Tue, May 10, 2005 at 03:37:13PM +0100, Bernard Leak wrote:
> Dear List,
>
> Firstly, thanks to Bob Proulx for the helpful pointer to the Debian
> search widget. This is a genuinely useful-looking tool. How pleasing!
> But unless he thinks this is another thing I should "just know about",
> it's worth documenting *somewhere*. I don't suggest that the GCC
> documentation should necessarily mention the Debian web-site
> (indeed, it is surely better not to): but the GCC documentation left
> me stuck over "Mail". with nowhere to go.
Patches are welcome.
> How difficult does it have to be to find something out before adding it
> to the documentation looks like a benefit to other people? Is forcing me
> (and any others in the same position later) to ask an unnecessary
> question something to be encouraged, as an exercise in communal
> living, or something? Do you all have too much time on your hands?
No, that's why a patch from you would help, even if it's only a starting
point for someone else to improve on. Many of us are volunteers, so if
something isn't a problem to us then getting round to fixing it doesn't
always seem appealing. Send a patch to help us out.
I sometimes make changes to the docs when I see something that could be
improved, but currently I'm busy working on other things which cause me
real problems.
> Is there any information you would like to delete from the documentation
> on the same principle?
Probably. Patches welcome.
> I'm not asking anyone to guess at things I might possibly not know and
> explain them in the documentation. I am asking for two *specific* things
> (which in fact I did not know) to be explained in the documentation,
> because brute-force searching in "the obvious places" doesn't produce
> the Right Thing, but can and does throw up misleading clues to the Wrong
> Thing. "Mail" in particular is not the name of a GNU utility, but "mail"
> is. The results submission script uses "Mail". My distribution has
> "mailx", which completes the set of three! How confusing and inconsistent
> does it have to be before it seems like a candidate for documentation?
Send a patch, it might get more attention than a request without a
patch.
> hand ("Linux in a Nutshell", 4th Edition). I have now gone back to
> check: the documentation for "mail" mentions neither "Mail" nor "mailx",
> and I found no references to "Mail" or "mailx" in the index. I have
> now gone over the "sendmail" documentation (apparently for Big
> Sendmail). Zack Weinberger's first reply to me is still the only
> indication I've ever noticed that there is more than one thing called
> "sendmail".
Search rpmfind.net for /usr/sbin/sendmail, you'll see lots of
non-sendmail packages provide that executable.
> If you have a lot of time to waste you might try finding "Mail" in
> the Linux Documentation Project tree. You do have a lot of time
> to waste, don't you? I mean, it *might* be in there. Somewhere.
> Yes, I tried this at length before I gave up and made my posting.
> Again, I didn't think there was much point in mentioning it.
This isn't GCC's problem. Send a patch :-)
jon
--
I don't pretend to be an expert on intellectual property law, but I do
know one thing. If a music industry executive claims I should agree with
their agenda because it will make me more money, I put my hand on my wallet
... and check it after they leave, just to make sure nothing's missing.
- Janis Ian
Re: Mail. Mail! Mail?
Bernard Leak wrote: > Firstly, thanks to Bob Proulx for the helpful pointer to the Debian > search widget. This is a genuinely useful-looking tool. How pleasing! Not wanting to take credit inappropriately, it was Zack who suggested the Debian package search page. I was the mailx history rant! :-) > But unless he thinks this is another thing I should "just know about", You have to draw the line somewhere. Take for example the contrived problem of documenting fully the process of waking up and going to work in the morning. Spend no more than 25 words describing how to tie your shoes. Is it sufficient for someone who has never seen shoelaces before to replicate the task and learn to tie their shoes? Probably not. True story. One of my friends was picking up his and the neighbor's kids in the car one day. My friend has an older car with crank windows. The neighbor kids had never seen that before and very politely (I was impressed) asked how could they please put the window down? It surprised me, but they had not ever seen a crank window before and eventually needed to ask for help. Those are the types of scenes I think about when I and others ask for help. > I tried quite hard to find out the answers I needed before I first posted > my question. And we appreciate that. I often spend a huge amount of time searching and creating test cases and then posting a note only to find that I missed something very simple. Oh well. One has to do the research first just the same. But then once done don't fear asking for help. Not having made an effort will show. As it will also show having made an honest effort to figure things out. > How difficult does it have to be to find something out before adding it > to the documentation looks like a benefit to other people? I don't think I have ever heard of anyone else having this particular problem before. Mind you there are a *lot* of potential problems. If you are forcing me to state an opinion I would say I think something needs to be asked three times before it becomes a frequently asked question. So no, I actually don't think this is a big deal and would not do anything taking huge effort to make sure it did not happen again. But if the problem did appear a few times or by judgement someone thought that it would be likely to happen then it would be useful to work to avoid. > If you have a lot of time to waste you might try finding "Mail" in > the Linux Documentation Project tree. You do have a lot of time > to waste, don't you? I mean, it *might* be in there. Somewhere. > Yes, I tried this at length before I gave up and made my posting. > Again, I didn't think there was much point in mentioning it. The name is an unfortunately common word. I like the "links" browser. It has some really nice features. But one of the worst things about it is the fact that the name cannot be searched for with any reasonable success. (For those interested look at the extended project "Elinks", as in 'apt-get install elinks', successful because you can search for that name.) Picking an unsearchable project name is a bad thing that we know is a bad thing today. But back when Mail was created, who knew? > Does Bob think that if I don't know that "Mail" = "mail" I am roughly > equally likely not to know about "cat" or "grep"? If so, he is clearly > looking down on me from a position of such altitude as to be quite > unable to recognise the problems the rest of us have. I am sorry my treatise on the history of mailx disturbed you so greatly. It was not my intention. I was really only working from the premise of, "See one, do one, teach one." The reason I shared that essay was that if you don't know about it that it will make no sense. But if you do know about it then many things make sense. I often learn great things from the people who work hard to share their knowledge. In that same spirit I try to give it back when I can. Bob
Re: Mail. Mail! Mail?
Dear List, Jonathan Wakely wants me to send a patch (or more than one). >Send a patch. Will do, after some further digging and sanity-testing, along the lines I have already indicated. Did you expect it already? I have to consider that not all builds of GCC are on UN*X-type boxes. The existing machinery for submitting test results is rather non-portable: I don't want to do anything to make it worse. >This isn't GCC's problem. No it (was) mine - but it was a problem with GCC. I'm considering how GCC can be modified to help, so it doesn't become somebody else's problem. Most of the difficulty is not best dealt with in GCC, but I think some of it is. >Send a patch I've already sent a suggestion to O'Reilly fpr the next edition of "Linux in a Nutshell". I'm thinking what can be done by way of producing a one-stop shop for nasty aliases and homonyms (libxml=gnome-xml and all the others) to go in the LDP. Any other bright ideas? Or can someone point me to where it has all been done before? Bernard Leak -- "Before they made me, they broke the mould"
Re: Mail. Mail! Mail?
On Tue, May 10, 2005 at 04:58:03PM +0100, Bernard Leak wrote: > Dear List, > > Jonathan Wakely wants me to send a patch (or more than one). :-) > >Send a patch. > Will do, after some further digging and sanity-testing, along the lines > I have already indicated. Did you expect it already? I have to > consider that not all builds of GCC are on UN*X-type boxes. The > existing machinery for submitting test results is rather non-portable: > I don't want to do anything to make it worse. Cool. I'm sure plenty of people will be glad to look over it and verify anything you're not sure about, just mention if you think a certain bit needs extra attention. > I've already sent a suggestion to O'Reilly fpr the next edition > of "Linux in a Nutshell". I'm thinking what can be done by way > of producing a one-stop shop for nasty aliases and homonyms > (libxml=gnome-xml and all the others) to go in the LDP. Any > other bright ideas? Or can someone point me to where it has > all been done before? That sounds like a very good idea to me. Here's one that bothers me when I move between different machines: soffice / ooffice jon
