Re: Can I get a hint, please?
> http://lists.gnu.org/archive/html/bug-bash/2006-09/msg00068.html I gave it a quick try on Red Hat linux with the bash-3.2 release candidate, and ran `echo $MYPID' about 15 times without error. Chet Hi Chet, Cool. I'll have to get the up-to-date bash and give it a try. That's a problem here at home, though, 'cuz of dependencies I have to update the world. Oh, well. Thank you! I don't suppose I could convince you to go ahead and plug $MYPID into future bash releases? :) 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.) That got me thinking. csh/bash have this cute feature of giving hints when the tab key is pressed. Programs nowadays are elf and elf allows for arbitrary sections to be added into a binary that won't affect the execution. Suppose, for example, there were a section named, ".options" and it contained a magic number to ensure the right version of the right thing were being looked at. Now if someone presses "tab" after the command name you could actually emit real usage text. :) Further, in answer to David's auto-reordering suggestion, with that option the arguments can be scanned and you'll know if the ``-l'' flag takes an argument or not and, thus, be able to correctly reorder. I think it an amusing idea. I have the code for doing something like this: http://www.gnu.org/software/autogen/autoopts.html In the last decade, I've incompatably altered the option data structure once, about two years ago. It's fairly stable. So, I can piece something together. It'd be nice if it were a loadable module, but with needing hooks into command completion, I'm guessing it is unlikely. Before I start (and spend a couple of months fiddling with it -- time constraints), I would like to know if it would get tossed out-of-hand or not. I don't want to be wasting my time. Thanks! - Bruce ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Can I get a hint, please?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruce Korb on 10/7/2006 8:09 AM: > That got me thinking. csh/bash have this cute feature of giving > hints when the tab key is pressed. Programs nowadays are elf > and elf allows for arbitrary sections to be added into a binary > that won't affect the execution. Suppose, for example, there > were a section named, ".options" and it contained a magic number > to ensure the right version of the right thing were being looked > at. Now if someone presses "tab" after the command name you could > actually emit real usage text. :) Further, in answer to David's > auto-reordering suggestion, with that option the arguments can > be scanned and you'll know if the ``-l'' flag takes an argument > or not and, thus, be able to correctly reorder. Bash already has programmable tab completion, although I'm not sure if you would be able to hook argument reordering into it easily. But PLEASE don't assume the entire world is elf. Bash is ported to a number of non-elf platforms, such as PE-COFF of Windows. Hooking in a readline command that examines the command enough to know which options take arguments so that reordering will not change the semantics of the command sounds admirable, but doing so by parsing the target executable just does not sound like the right approach to me. We don't need to bloat bash by adding all of the binutils capabilities into it. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFJ91h84KuGfSFAYARAliSAJ0SMZxdF0APVQKolug34SiRr7S2NACeIJ9r b8TK6UyvYrZydJ7AuJwo2Lc= =iWgW -END PGP SIGNATURE- ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Can I get a hint, please?
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
