ste@cbnewsm.ATT.COM (Shaun T. Erickson) (08/21/89)
When I execute the "toolplaces" command, after setting up my sunview screen to my tastes, the line for mush reads as: mush -Wp 88 47 -Ws 703 761 -WP 584 588 -Wi -Wb 0 0 140 -Wf 255 130 0 -t -Wg This always worked in my setup file just fine, before I switched to the mushview version. Now mush blows up on this - complaining about invalid arguments - resulting in mush coming up in line mode, in compose mode, and asking for a subject for the letter which is addressed to all the command line arguments (except for the first argument, which it choked on). I have found that if I move the single mushview argument, the "-t", to be the first argument to mush, it works just fine, but this means I now have to manually edit my startup file - not very freindly, eh? Why is this broken now, and which should be fixed: mush, toolplaces, or me? 8-{)> -- ------------------------------------------------------------------------------ Shaun T. Erickson Contracted to AT&T Bell Labs, Allentown, Pennsylvania Internet: ste%hudson@aloft.att.com UUCP: ...!att!aloft!hudson!ste Standard Disclaimer. This space for rent.
schaefer@ogccse.ogc.edu (Barton E. Schaefer) (08/23/89)
In article <3002@cbnewsm.ATT.COM> ste%hudson@aloft.ATT.COM (Shaun T. Erickson) writes: } } mush -Wp 88 47 -Ws 703 761 -WP 584 588 -Wi -Wb 0 0 140 -Wf 255 130 0 -t -Wg } } This always worked in my setup file just fine, before I switched to the } mushview version. Now mush blows up on this - complaining about invalid } arguments - resulting in mush coming up in line mode, in compose mode, } and asking for a subject for the letter which is addressed to all the } command line arguments (except for the first argument, which it choked on). This results from a SunWindows and SunView incompatibility. Under SunWindows, the tool_parse_all() function could be called to remove the -W flags and their arguments whether the program was actually running under suntools or not. The equivalent window_create() call in SunView fails if there is not a base window in the environment. Mush's argument parser can't easily be taught to understand every possible -W flag and it's following parameters; therefore: } I have found that if I move the single mushview argument, the "-t", to be } the first argument to mush, it works just fine, but this means I now have } to manually edit my startup file - not very freindly, eh? This is documented. The -t must now be the first argument, otherwise mush is not able to detect that it should be starting as a tool and will not call window-create() to remove the -W flags. } Why is this broken now, and which should be fixed: mush, toolplaces, or me? When mush is installed with toolmode capability, there should always be a link to it, named "mushtool". If the "tool" suffix is present, mush will not bother looking for the -t argument and calls window_create() immediately. You should change your command to use "mushtool" instead of "mush" as the command name. I'm not familiar enough with "toolplaces" to tell you what needs to change to accomplish this. -- Bart Schaefer "And if you believe that, you'll believe anything." -- DangerMouse CSNET / Internet schaefer@cse.ogc.edu UUCP ...{sequent,tektronix,verdix}!ogccse!schaefer