Bruce Korb wrote:
> As long as I'm being chatty, there has been a discussion recently
> on the Austin Group reflector titled, "Re: USG Guideline 9"
> that had to do with the handling of misordered command line options.
> David Korn et al. were speculating on the possibility of making
> the shell have an option of auto-correcting argument order so that
> the command itself would never have to mess with reordering its
> own arguments. (This is a problem because various GNU utilities
> like "ls" are not POSIX compliant because they do things that
> a conforming application (shell script) would not expect.)
I've read the discussion. I don't favor David's proposal. Its
primary advantage is that it's a little less undesirable than the
alternative, which I've seen best articulated as "Posix needs to
standardize the Linux behavior or risk irrelevance."
If we agree that there will always be exceptions (find, ssh, su, etc.)
so that no solution is going to be perfect, and that the GNU `getopt'
does mostly the right thing reordering arguments, a design suggests
itself.
Bash already allows a keystroke to be bound to an arbitrary executable
or shell function. The disadvantage of the current implementation is
that it does not provide the hooks into readline that programmable
completion does (COMP_LINE, COMP_WORDS, etc., and the ability to replace
part or all of the current edit line). That could be fixed, which leads
to the following:
The "special keystroke" is bound to an executable or shell function
that incorporates (executable) or calls a small program (shell function)
that simply invokes GNU getopt to reorder the arguments and prints them to
the standard output. The editing `glue' that's needed is a mechanism
to essentially create a keyboard macro on the fly: erase the current
line and insert the text output by this program.
I'm not suggesting that this is a complete workable design, but that not
all of it needs to go into the shell. It doesn't assume the universality
of ELF (my primary development platforms are not ELF), it doesn't require
augmenting the executable format, it doesn't require changing the
toolchain, and it doesn't require all the code to understand this to be
stuffed into the shell.
I'm not committing to do anything like this, of course. :-) But while
I'm thinking about it, it sounds like an interesting extension to make
to the key binding mechanisms that bash already adds to readline.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Live Strong. No day but today.
Chet Ramey, ITS, CWRU [EMAIL PROTECTED] http://cnswww.cns.cwru.edu/~chet/
_______________________________________________
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
