Aborted unmodified message
Hi All, Hoping that you might help me with a slight problem. I've got a .muttrc file that was working fine on my work machine. When I copied the .muttrc over to my home box, I can fire up mutt fine, and can even download messages from my POP account, but when I try to create a message I get all the way through inputting the To: and Subject: fields and then I get the message Aborted unmodified message. Any ideas on where I should start? Is there an error logging function that I can turn on? thanks! -- Bren Smith [EMAIL PROTECTED] (via Pine!)
Re: Aborted unmodified message
bren [mutt-users] 27/06/01 21:17 -0700: Hoping that you might help me with a slight problem. I've got a .muttrc file that was working fine on my work machine. When I copied the .muttrc over to my home box, I can fire up mutt fine, and can even download messages from my POP account, but when I try to create a message I get all the way through inputting the To: and Subject: fields and then I get the message Aborted unmodified message. Any ideas on where I should start? Is there an error logging function that I can turn on? What's the path to your editor? Maybe vi (or vim) is at a different location? set editor=/usr/bin/vim -c ':0;/^Subject: ' edit that in your .muttrc -suresh
Re: Aborted unmodified message.
On Wed, Sep 27, 2000 at 18:42:38 -0400, David T-G wrote: Yep, that was what I meant. Did you try a simple :set shell=/sbin/sh from within mutt? Did you try :set ?shell to see what mutt thinks $shell is holding? The $shell variable is /only/ used for the shell-escape command (default bound to ! in all menus), so this is not relevant for this case. Check instead that EXECSHELL have an absolute path to a valid shell like this: $ mutt -v | grep EXECSHELL EXECSHELL="/bin/sh" $ EXECSHELL is used for caling all external programs (including the $shell shell when using the shell-escape command). It defaults to /bin/sh, but can be changed when mutt is configured with "./configure --with-exec-shell=EXECSHELL". Se the INSTALL file for reasons to do that. How interesting... With a valid $shell setting you can't even !ls This doesn't require a valid $shell (try to set $shell to some bad value and try it - it still works if it worked before), but it certainly require a valid EXECSHELL. -- Byrial http://home.worldonline.dk/~byrial/
Re: Aborted unmodified message.
Suresh Ramasubramanian ([EMAIL PROTECTED]) wrote: : I rather suspect that the path to vim is wrong in his .muttrc : Especially if he had an rpm install which would dump vim in /bin or /usr/bin - : and then compiled a new vim from a tarball, that'd put it into /usr/local/bin : : Use `which vim` to locate where the vim is on your box - and edit the editor : variable in your .muttrc to reflect the new location. That wasn't it. The ``path'' to vim was correct---It was using an alias. I explicitly set the path to where vim resides but that didn't work. Thanks. Regards, Marc van Dongen
Re: Aborted unmodified message.
Marc van Dongen proclaimed on mutt-users that: That's not the problem. Mutt doesn't seem to let me edit at all. With this setting, I can postpone a message for later, then recall it and use `e` to edit but mutt won't let me Then check if your tmpdir directory is set properly, or is over-full. Especially if your copy of vi makes backups of each post ... -- Suresh Ramasubramanian + Wallopus Malletus Indigenensis mallet @ cluestick.org + Lumber Cartel of India, tinlcI The meeting of two personalities is like the contact of two chemical substances: if there is any reaction, both are transformed. -- Carl Jung
Re: Aborted unmodified message.
Marc -- ...and then Marc van Dongen said... % David T-G ([EMAIL PROTECTED]) wrote: % % : % Aborted unmodified message. % : % % : % Any suggestions how to overcome this problem? % : % : You might start by checking your $editor setting in your muttrc and your % % My editor setting points to an existing vim which works. Hokay. That's a good start... % % : $EDITOR and $VISUAL settings in your shell; if they're still pointing to % % EDITOR=VISUAL= That shouldn't matter much if your $editor is explicit, but at least it's not confusing. % % : setting to "yes" instead of one of the other possibilities) so mutt will % : throw it away. % % I can see that. Good enough. % % : If you can't figure out what's up, try setting mutt's $editor to a % : quickie script which calls vim and then waits for a keypress before % : exiting so that you can see any error messages that go by. % % I changed the editor setting to a script that prints something, % reads a line and then starts to edit. It doesn't seem to be % called when I press `e.' I still get the `unmodified' message. No, make sure that you *first* call vim and you *then* wait. You need to see that vim is really called and see what messages, if any, it returns. % % So should I set EDITOR and VISUAL to something? I just upgraded % to a higher solaris 8. Maybe that has to do something with the % problem as well. Possbile, but not probable. I'm still betting on a vim config, though a full /tmp as already mentioned might be a good place to start (my vim tmpdir is $HOME/tmp; I forget about the defaults sometimes :-) % % Regards, HTH HAND % % % Marc van Dongen :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.bigfoot.com/~davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! The "new millennium" starts at the beginning of 2001. There was no year 0. Note: If bigfoot.com gives you fits, try sector13.org in its place. *sigh* PGP signature
Re: Aborted unmodified message.
David T-G ([EMAIL PROTECTED]) wrote: [snip] : % : If you can't figure out what's up, try setting mutt's $editor to a : % : quickie script which calls vim and then waits for a keypress before : % : exiting so that you can see any error messages that go by. : % : % I changed the editor setting to a script that prints something, : % reads a line and then starts to edit. It doesn't seem to be : % called when I press `e.' I still get the `unmodified' message. : : No, make sure that you *first* call vim and you *then* wait. You need to : see that vim is really called and see what messages, if any, it returns. I overlooked the purpose of you suggestion. It doesn't make any difference. The script doesn't get called. [snip] : Possbile, but not probable. I'm still betting on a vim config, though a : full /tmp as already mentioned might be a good place to start (my vim : tmpdir is $HOME/tmp; I forget about the defaults sometimes :-) I'll have a look at that. Thanks. Regards, Marc van Dongen
Re: Aborted unmodified message.
Marc -- ...and then Marc van Dongen said... % David T-G ([EMAIL PROTECTED]) wrote: % % [snip] % % : % : quickie script which calls vim and then waits for a keypress before % : % % : % I changed the editor setting to a script that prints something, % : % reads a line and then starts to edit. It doesn't seem to be % : % called when I press `e.' I still get the `unmodified' message. % : % : No, make sure that you *first* call vim and you *then* wait. You need to % : see that vim is really called and see what messages, if any, it returns. % % I overlooked the purpose of you suggestion. It doesn't % make any difference. The script doesn't get called. Oho; I see what you mean. Now *that* is an interesting one. That answer will require some thought :-) % % [snip] % % : Possbile, but not probable. I'm still betting on a vim config, though a % : full /tmp as already mentioned might be a good place to start (my vim % : tmpdir is $HOME/tmp; I forget about the defaults sometimes :-) % % I'll have a look at that. Thanks. Sure thing... % % % Regards, % % % Marc van Dongen :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.bigfoot.com/~davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! The "new millennium" starts at the beginning of 2001. There was no year 0. Note: If bigfoot.com gives you fits, try sector13.org in its place. *sigh* PGP signature
Re: Aborted unmodified message.
Marc van Dongen [EMAIL PROTECTED] wrote on Wed, 27 Sep 2000: I changed the editor setting to a script that prints something, reads a line and then starts to edit. It doesn't seem to be called when I press `e.' I still get the `unmodified' message. What doesn't get called when you press e, the script? (Just making sure I got that right..) One way to try to figure out things is to check the current $editor value from within Mut: :set ?editor This will give you the current editor setting, so you can verify it's correct. If it's correct, you can check that Mutt can execute it, with the ! command: !/path/to/your/editor/here You don't say what the values are, so something to try (if you haven't yet) is to put full paths into the settings. Maybe our PATH setting isn't set up the way you think it is, if you're launching Mutt via some graphical shell for instance. This shouldn't be a problem if it's started from a shell window though. Still worth a try... Hope this helps, Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy scifi, the Corrs / Any sufficiently advanced magic is indistinguishable from technology.
Re: Aborted unmodified message.
Mikko Hänninen ([EMAIL PROTECTED]) wrote: : Marc van Dongen [EMAIL PROTECTED] wrote on Wed, 27 Sep 2000: : I changed the editor setting to a script that prints something, : reads a line and then starts to edit. It doesn't seem to be : called when I press `e.' I still get the `unmodified' message. : : What doesn't get called when you press e, the script? (Just making : sure I got that right..) The script to which the editor setting in my .muttrc points doesn't get called. : correct. If it's correct, you can check that Mutt can execute it, with : the ! command: : : !/path/to/your/editor/here Good one. I hadn't thought of trying that. It fails Other shell commands fail as well : You don't say what the values are, so something to try (if you haven't : yet) is to put full paths into the settings. Maybe our PATH setting The path is set up properly. As a matter of fact, the editor setting in the .muttrc is an absolute pathname. : isn't set up the way you think it is, if you're launching Mutt via some : graphical shell for instance. This shouldn't be a problem if it's I'm launching mutt from the command-line prompt in a ``regular'' window. Thanks. Regards, Marc van Dongen
Re: Aborted unmodified message.
Marc van Dongen [EMAIL PROTECTED] wrote on Wed, 27 Sep 2000: : !/path/to/your/editor/here Good one. I hadn't thought of trying that. It fails Other shell commands fail as well Well, that's the "reason" then why your editor isn't getting called. I have no idea why you couldn't run any commands from within Mutt though, I've never heard of this kind of problem. Can you even start /bin/sh (or your own shell)? Regards, Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy scifi, the Corrs / Get a life? Well, once I nearly found one, but the link was broken.
Re: Aborted unmodified message.
Mikko Hänninen ([EMAIL PROTECTED]) wrote: [snip] : Good one. I hadn't thought of trying that. It fails : Other shell commands fail as well [snip] : I have no idea why you couldn't run any commands from within Mutt : though, I've never heard of this kind of problem. Can you even : start /bin/sh (or your own shell)? Nope. All commands fail. As I mentioned earlier on, I upgraded from sparc-sun-solaris-2.7 to sparc-sun-solaris-2.8 and rebuilt mutt from scratch. I did this before as well without serious problems. I haven't gor a clue what is going on here. Maybe this is an operating system related problem. I am using the CDE desktop at the moment but the problem also manifests itself if I use the openwindows desktop. Regards, Marc van Dongen
Re: Aborted unmodified message.
Marc van Dongen proclaimed on mutt-users that: Maybe this is an operating system related problem. I am using the CDE desktop at the moment but the problem also manifests itself if I use the openwindows desktop. Get out of both desktops into the sun shell... try mutt there. -- Suresh Ramasubramanian + Wallopus Malletus Indigenensis mallet @ cluestick.org + Lumber Cartel of India, tinlcI To avoid criticism, do nothing, say nothing, be nothing. -- Elbert Hubbard
Re: Aborted unmodified message.
Suresh Ramasubramanian ([EMAIL PROTECTED]) wrote: : Get out of both desktops into the sun shell... try mutt there. No success either:-( Regards, Marc van Dongen
Re: Aborted unmodified message.
On Wed, Sep 27, 2000 at 04:09:04PM +0100, Marc van Dongen wrote: Suresh Ramasubramanian ([EMAIL PROTECTED]) wrote: : Get out of both desktops into the sun shell... try mutt there. No success either:-( And what does :set ?shell return? -- - Bruce
Re: Aborted unmodified message.
Bruce DeVisser ([EMAIL PROTECTED]) wrote: : And what does :set ?shell return? shell="/usr/bin/bash" which is correct. Regards, Marc van Dongen
Re: Aborted unmodified message.
On 27, Sep, 2000 at 01:36:46PM +0100, Marc van Dongen wrote: David T-G ([EMAIL PROTECTED]) wrote: [snip] : % : If you can't figure out what's up, try setting mutt's $editor to a : % : quickie script which calls vim and then waits for a keypress before : % : exiting so that you can see any error messages that go by. : % : % I changed the editor setting to a script that prints something, : % reads a line and then starts to edit. It doesn't seem to be : % called when I press `e.' I still get the `unmodified' message. : : No, make sure that you *first* call vim and you *then* wait. You need to : see that vim is really called and see what messages, if any, it returns. I overlooked the purpose of you suggestion. It doesn't make any difference. The script doesn't get called. [snip] : Possbile, but not probable. I'm still betting on a vim config, though a : full /tmp as already mentioned might be a good place to start (my vim : tmpdir is $HOME/tmp; I forget about the defaults sometimes :-) I'll have a look at that. Thanks. This _is_ a long shot, but: what happens when you try to invoke vim from your shell? Just a thought I got reading this thread, and I know I myself has overlooked the blindingly obvious at times ... HTH, HAND Morten -- UNIX, reach out and grep someone!
Re: Aborted unmodified message.
Marc -- ...and then Marc van Dongen said... % Bruce DeVisser ([EMAIL PROTECTED]) wrote: % % : And what does :set ?shell return? % % shell="/usr/bin/bash" % % which is correct. It may be correct, but it isn't stock :-) Try settin $shell to /sbin/sh, which is guaranteed to be completely self-contained. If *that* works, then try using /bin/sh to see if your shared libs are all healthy. If *that* works, then it's all bash's fault. Note that I don't want to start a shell war; in fact, as much as I hate to admit it, I think I'm becoming a bash convert because of ksh limitations :-) % % Regards, HTH HAND % % % Marc van Dongen :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.bigfoot.com/~davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! The "new millennium" starts at the beginning of 2001. There was no year 0. Note: If bigfoot.com gives you fits, try sector13.org in its place. *sigh* PGP signature
Re: Aborted unmodified message.
Morten Liebach ([EMAIL PROTECTED]) wrote: [snip] : This _is_ a long shot, but: what happens when you try to invoke vim from : your shell? It works great! [snip] Regards, Marc van Dongen
Re: Aborted unmodified message.
David T-G ([EMAIL PROTECTED]) wrote: : It may be correct, but it isn't stock :-) Try settin $shell to /sbin/sh, : which is guaranteed to be completely self-contained. If *that* works, I am assuming you are asking me to write a wrapper script around mutt to set the shell. That didn't work. Now I am assuming you are asking me put a shell= line in my .muttrc. That didn't work either. : then try using /bin/sh to see if your shared libs are all healthy. : If *that* works, then it's all bash's fault. That didn't work for the wrapper nor for the shell= variant. : Note that I don't want to start a shell war; in fact, as much as I : hate to admit it, I think I'm becoming a bash convert because of ksh : limitations :-) Good lad! Thanks again. Regards, Marc van Dongen
Re: Aborted unmodified message.
Marc van Dongen [EMAIL PROTECTED] wrote on Wed, 27 Sep 2000: Bruce DeVisser ([EMAIL PROTECTED]) wrote: : And what does :set ?shell return? shell="/usr/bin/bash" which is correct. OK.. And you can get a shell (via a terminal window), so you know the binary is executable etc.? Marc van Dongen [EMAIL PROTECTED] wrote on Wed, 27 Sep 2000: : I have no idea why you couldn't run any commands from within Mutt : though, I've never heard of this kind of problem. Can you even : start /bin/sh (or your own shell)? Nope. All commands fail. Well, this is obviously the problem here. :-) Unfortunately it doesn't help yet that much in knowing the solution. But not being able to start any programs is Very Bad. As I mentioned earlier on, I upgraded from sparc-sun-solaris-2.7 to sparc-sun-solaris-2.8 and rebuilt mutt from scratch. I did this before as well without serious problems. I haven't gor a clue what is going on here. Maybe this is an operating system related problem. I don't know the exact details (haven't looked at the source), but I would guess that the way Mutt starts an external program is with the system() sytem-function-call. If your Mutt can't run programs this way, then something is Seriously Wrong in your setup. Trying to debug this gets quite hairy though. On Linux, I would run Mutt with strace and trace the syscalls it makes, in the hope that I could see what's the status of the system() function. For Sun, I don't know what the system call trace program is called -- truss maybe, or was that some other OS? It may not have one (installed). Like I said, if your Mutt can't start programs, things are Seriously Wrong, and because of it gets quite complex to try to figure out what is going wrong. I am using the CDE desktop at the moment but the problem also manifests itself if I use the openwindows desktop. Like someone else suggested, try getting a shell without a windowing environment, and then try with that. That way you can check the values of PATH etc., and know for sure it's not the windowing environment getting in the way. I don't actually think it is, however since weird things are happening I'd try to eliminate every potential source of confusion. Regards, Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy scifi, the Corrs / "The last good thing written in C was Franz Schubert's Symphony #9."
Re: Aborted unmodified message.
On Wed, Sep 27, 2000 at 10:57:14PM +0300, Mikko Hänninen wrote: I don't know the exact details (haven't looked at the source), but I would guess that the way Mutt starts an external program is with the system() sytem-function-call. If your Mutt can't run programs this way, then something is Seriously Wrong in your setup. The help doc mentions /bin/sh -c in relation to mime mailcap stuff... hopefully that is not a hard-coded path and if so hopefully only used in a limited place. I have not checked the source (obviously). -- - Bruce
Re: Aborted unmodified message.
Mikko Hänninen ([EMAIL PROTECTED]) wrote: : OK.. And you can get a shell (via a terminal window), so you know the : binary is executable etc.? I am not exactly sure what you mean. External programs, like knews can start vim as an external program to compose an email message. [snip] : Like someone else suggested, try getting a shell without a windowing : environment, and then try with that. That way you can check the values : of PATH etc., and know for sure it's not the windowing environment : getting in the way. I don't actually think it is, however since weird : things are happening I'd try to eliminate every potential source of : confusion. That doesn't work there either. Thanks. Regards, Marc van Dongen
Re: Aborted unmodified message.
Marc -- ...and then Marc van Dongen said... % David T-G ([EMAIL PROTECTED]) wrote: % % : It may be correct, but it isn't stock :-) Try settin $shell to /sbin/sh, % : which is guaranteed to be completely self-contained. If *that* works, % % I am assuming you are asking me to write a wrapper script around % mutt to set the shell. That didn't work. Nope, that wasn't it. % % Now I am assuming you are asking me put a shell= line in my .muttrc. % That didn't work either. Yep, that was what I meant. Did you try a simple :set shell=/sbin/sh from within mutt? Did you try :set ?shell to see what mutt thinks $shell is holding? % % : then try using /bin/sh to see if your shared libs are all healthy. % : If *that* works, then it's all bash's fault. % % That didn't work for the wrapper nor for the shell= variant. How interesting... With a valid $shell setting you can't even !ls manually, eh? Still more thinking on my part :-) % % : Note that I don't want to start a shell war; in fact, as much as I % : hate to admit it, I think I'm becoming a bash convert because of ksh % : limitations :-) % % Good lad! *grin* % % Thanks again. HTH HAND % % Regards, % % % Marc van Dongen :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.bigfoot.com/~davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! The "new millennium" starts at the beginning of 2001. There was no year 0. Note: If bigfoot.com gives you fits, try sector13.org in its place. *sigh* PGP signature
Re: Aborted unmodified message.
On Wed, Sep 27, 2000 at 22:57:14 +0300, Mikko Hänninen wrote: I don't know the exact details (haven't looked at the source), but I would guess that the way Mutt starts an external program is with the system() sytem-function-call. Mutt has its own implementaion of system() to have better control on signal handling and redirection. It uses execl() like this to execute a program: execl (EXECSHELL, "sh", "-c", cmd, NULL); EXECSHELL can be set with the configure script, and the compiled-in value can be seen with "mutt -v". I advise to check this as a bad value for EXECSHELL can prevent Mutt from executing any external program. -- Byrial http://home.worldonline.dk/~byrial/
Re: Aborted unmodified message.
At 22:57 +0300 27 Sep 2000, Mikko Hänninen [EMAIL PROTECTED] wrote: For Sun, I don't know what the system call trace program is called -- truss maybe, or was that some other OS? It may not have one (installed). truss is correct. I'd probably use: truss -o /tmp/mutt.truss -f -t exec mutt -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ C makes it easy for you to shoot yourself in the foot. C++ makes that harder, but when you do, it blows away your whole leg. -- Bjarne Stroustrup
Aborted unmodified message.
Hi there, I just re-installed vim on my system. When I now try to compose a message after I enter the name of the recipient mutt does not allow me to write a message. Istead it displays a Aborted unmodified message. message. Any suggestions how to overcome this problem? Thanks in advance. Marc van Dongen -- Marc van Dongen, CS Dept | phone: +353 21 4903578 University College Cork, NUIC | Fax:+353 21 4903113 College Road, Cork, Ireland | Email: [EMAIL PROTECTED] PS: This message was sent by a different mutt from a different machine.
Re: Aborted unmodified message.
On 2000.09.26, in [EMAIL PROTECTED], "Marc van Dongen" [EMAIL PROTECTED] wrote: Hi there, I just re-installed vim on my system. When I now try to compose a message after I enter the name of the recipient mutt does not allow me to write a message. Istead it displays a Aborted unmodified message. message. set abort_unmodified=ask-no Wow, two questions in a row I'm dealing with as they roll in. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Aborted unmodified message.
Hey, I'm having some trouble with mutt. I'm using mutt-1.2.2i, compiled with the --enable-pop, running on FreeBSD 4.0 Stable. I can check my mail fine, but when I try to send mail, it doesn't work. First, I hit "m", for new mail, then type in the address on the "to:" line, and hit enter. Then it just says, "Aborted unmodified message.". I can send mail using other muas just fine, and I've checked all ther permissions. Can someone help me out? Jeff (Please reply directly, I'm not on the list)
Re: Aborted unmodified message.
User Jasapp [EMAIL PROTECTED] wrote on Wed, 05 Jul 2000: First, I hit "m", for new mail, then type in the address on the "to:" line, and hit enter. Then it just says, "Aborted unmodified message.". Sounds like the execution of your editor fails. That is, after Mutt has created a template email file (with your signature and possibly any quoted text from an email you're replying to), it's running your editor on that file, but the command fails. What editor are you using? Do you have the environment variables VISUAL and/or EDITOR defined? You can check what Mutt thinks the editor command is by doing: :set ?editor ... within Mutt. You can also set the editor to some command, with: :set editor=/path/to/my/editor (leave out the : from the beginning if you're putting that command in the .muttrc file) Hope this helps, Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy scifi, the Corrs / We're not surrounded, we're in a target-rich environment!
Re: Aborted unmodified message.
User Jasapp proclaimed on mutt-users that: First, I hit "m", for new mail, then type in the address on the "to:" line, and hit enter. Then it just says, "Aborted unmodified message.". I can send mail using other muas just fine, and I've checked all ther permissions. Can someone help me out? vi (or vim) is the default editor - put this in your .muttrc set editor="/path/to/vim" (usually /usr/bin/vim or /usr/local/bin/vim). Of course, feel free to use whatever other editor you want (say /path/to/pico -t -z" if you want to be sacrilegeous) :) To find out where your editor is, do $ which vim (or pico or joe or ...) -- Suresh Ramasubramanian + [EMAIL PROTECTED] Universe, n.: The problem.
