On Friday, June 15 at 02:25 PM, quoth Derek Martin:
It's not broken. The application developer has the right to use any exit status he wants. Mutt CAN NOT make assumptions about what the exit status means.
Now wait a minute, you're mixing standards here. Just as the application developer has the *right* to use any exit status he wants, mutt has the *right* to make whatever assumptions it feels like about what the exit status means. But whether you have the *right* to do something does not mean that you have an obligation to do it, and doesn't mean that it's even a good idea. You have the *right* to jab yourself in the eye with a fork, but it's probably unwise. In fact, mutt has the *right* to delete every file on your computer, but that's also unwise. If a program does things (that it has every *right* to do) that are irritating, useless, dangerous, or whatever, you as the user have the right to refuse to use them (or, in the OSS case, change that behavior).
For example, most shells (including /bin/sh, even when it's not an alias for bash) make the *assumption* that an exit status of 0 means success and that anything else means an error of some sort. Thus, when doing `command1 && command2`, the shell *assumes* that if command1 does not exit with a status of 0 then something (who knows what) has gone wrong and command2 will not be executed. I don't know if that's in the POSIX standard or where it might be defined, but its reasonable enough to have been consistent for at least the last decade. And aren't you glad that it is pretty consistent? I mean, imagine doing shell-scripting if the result ALWAYS depended on the program, the version, and the OS. Instructions like './configure && make && make install' suddenly become incredibly ugly:
./configure; ret=$?
if [ "$OS" = "Linux" ] ; then
if [ $ret -eq 0 ] ; then
make
if [ $? -eq 0 ] ; then
make install
fi
fi
elif [ "$OS" = "Solaris" ] ; then
if [ $ret -ne 100 ] ; then
make
if [ $? -eq 43 ] ; then
make install
fi
fi
fi
# When we support more OS's, add them here.
It seems to me that making the same assumption that every single major
shell makes (i.e. that a non-zero status code means that an error
occurred) is perfectly reasonable (and mutt of course has every
*right* to make that assumption). The question then becomes: what
should mutt DO with that assumption? The options are: something or
nothing. "Something" could be informing the user of the (assumed)
error, for example. And "nothing" would of course be similar to the
result of assuming that the exit code contains no useful information.
So which route should mutt take once it has made the assumption (that it has every right to make) about what the exit code of the editor means? Doing nothing is undesirable for some, and doing something is undesirable for others. It may be worthwhile to add a configure option to mutt that allows the user to specify whether their editor's exit status matches the de-facto standard shell semantics (and thus non-zero codes should be considered actionable errors) or whether their editor's exit status should be ignored.
The user is a USER. They should not have to write code to make Mutt behave sanely.
HEH. Depends on your definition of sanity, I guess. There's a wishlist as long as your arm for new features in mutt, and most of them approach things from the "email reading would be much more sane if mutt did X" perspective. You could say, for example, that using anything other than DR-DOS is "insane", but you'll have to write code to make mutt work there. Is making the same assumption about exit codes that bash, csh, tcsh, ksh, ash, dash, and others make to be considered "insane"? I guess it depends on who you ask---you would (apparently) say yes and I would say no.
~Kyle --Three things in human life are important. The first is to be kind. The second is to be kind. And the third is to be kind.
-- Henry James
Attachment:
pgpWTUUGDF0V9.pgp
Description: PGP signature