Re: sh -c answers thanks!
On Wed, May 30, 2001 at 09:51:52PM -0400, Kyle Donaldson wrote: On Wed, 30 May 2001, Jeff Raven wrote: D) Provide two menu items, say [exec] and [cexec]; the first would just use sh, the second sh -c. rootCommand would still use sh -c. For the most part this would make things work like they used to before the exec code was changed. E) Provide two menu items, say [exec] and [sexec]; the first using sh -c and the second using sh. rootCommand would still use sh -c. Umm... As far as I can tell (and I just tested it) 'sh command' will NOT work, unless command is a shell script. 'sh -c command' tells sh execute this command without entering interactive mode. 'sh command' says execute this shell script using the shell. Yes, quite right... lately I've been misremembering command line options left and right (this is what comes of pondering alternatives without access to manpages...). Replace the sh above with do some form of parsing and call exec* ourselves. Also, was my execute semi-patch totally ignored? (http://www.mail-archive.com/blackbox@trolltech.com/msg02459.html) I haven't had the time to do a correct patch, because I've been working on some new software that has been a total PITA to write/debug/smash with sledgehammer. Since my memory is starting to go (see above), I looked back over the old execution code. It basically ran things through /bin/sh -c with an 'exec' prepended to the command (which is why compound commands didn't really work). Which makes me lean towards the just tell people to use 'exec foo' instead of 'foo' option. If I were to go with the launch-it-ourselves route, I'd want to avoid parsing for anything other than arguments -- but then there's the whole matter of quoting, and people asking why their `'s, ?'s and *'s aren't working, etc. All in all it seems like a whole lot of trouble. But I'll have two weeks to think about it (and the whole malicious rootCommand thing). Has anyone tried the smart-placement patch I put up a little while back? It seems to work fine here, but I don't know how much of an improvement it actually is, since I've got a pretty fast box here. Intuition says it should be a change for the better, though. Off to vacation, Jeff Raven (Oh, and yes, I'm aiming for the next version of blackbox to have key-navigable menus, but only when they are popped up using the keyboard.)
Re: sh -c answers thanks!
(Oh, and yes, I'm aiming for the next version of blackbox to have key-navigable menus, but only when they are popped up using the keyboard.) Two questions, 1: any idea on a possible timeline for this? 2: (more of a comment) once we have them only on the keyboard, it wouldn't be a far stretch for someone else to make them avail even if the mouse started the event, would it? DC
Re: sh -c answers thanks!
Sorry for jumping into the discussion so late, but I was away getting hitched. I'll be heading off in a day or so for a two week vacation, but I was curious what solution folks would prefer : A) None. Just encourage people to use exec or in their menu items. (Or force everyone to use bash :) B) Eliminate the ability to run compound commands in menu items and rootCommands. C) Eliminate the ability to run compound commands in menu items, but leave it in for rootCommands. D) Provide two menu items, say [exec] and [cexec]; the first would just use sh, the second sh -c. rootCommand would still use sh -c. For the most part this would make things work like they used to before the exec code was changed. E) Provide two menu items, say [exec] and [sexec]; the first using sh -c and the second using sh. rootCommand would still use sh -c. My impression is that people mostly use compound commands in their rootCommands, in which case I would favor C... (also, I haven't checked if cexec or sexec would cause conflicts in the parsing code). Jeff Raven
Re: sh -c answers thanks!
C) Eliminate the ability to run compound commands in menu items, but leave it in for rootCommands. D) Provide two menu items, say [exec] and [cexec]; the first would just use sh, the second sh -c. rootCommand would still use sh -c. For the most part this would make things work like they used to before the exec code was changed. either of these, weighted towards C.
Re: sh -c answers thanks!
umm, and why can't we leave it as is?
On Wed, 30 May 2001 10:01:22 Sean 'Shaleh' Perry wrote:
C) Eliminate the ability to run compound commands in menu
items, but leave it in for rootCommands.
D) Provide two menu items, say [exec] and [cexec]; the first
would just use sh, the second sh -c. rootCommand would
still use sh -c. For the most part this would make things
work like they used to before the exec code was changed.
either of these, weighted towards C.
--
%--%
Jason Kasper (vanRijn)
Systems Engineer
bash$ :(){ :|:};:
VORFA
Re: sh -c answers thanks!
On 30-May-2001 Jason vanRijn Kasper wrote: umm, and why can't we leave it as is? 1219 ?S 0:00 /bin/sh -c /usr/bin/X11/xfmail 1220 ?S 0:11 /usr/bin/X11/xfmail 1269 ?S 0:00 /bin/sh -c rxvt 1270 ?S 0:00 rxvt Having two processes per process is annoying.
Re: sh -c answers thanks!
In the gothic chambers of the underworld on Wed 30 May 2001 at 10:45 -0400, Jeff Raven muttered darkly: A) None. Just encourage people to use exec or in their menu items. (Or force everyone to use bash :) B) Eliminate the ability to run compound commands in menu items and rootCommands. C) Eliminate the ability to run compound commands in menu items, but leave it in for rootCommands. D) Provide two menu items, say [exec] and [cexec]; the first would just use sh, the second sh -c. rootCommand would still use sh -c. For the most part this would make things work like they used to before the exec code was changed. E) Provide two menu items, say [exec] and [sexec]; the first using sh -c and the second using sh. rootCommand would still use sh -c. My impression is that people mostly use compound commands in their rootCommands, in which case I would favor C... i use compound menu commands. i think they're helpful for things like setting the working directory and redirecting output. so i vote for d. t. -- 4.0k -rw-rw-r--1 zork zork 17 Apr 4 17:38 .signature
Re: sh -c answers thanks!
On 30 May 2001, at 8:14, Sean 'Shaleh' Perry wrote: On 30-May-2001 Jason vanRijn Kasper wrote: umm, and why can't we leave it as is? 1219 ?S 0:00 /bin/sh -c /usr/bin/X11/xfmail 1220 ?S 0:11 /usr/bin/X11/xfmail 1269 ?S 0:00 /bin/sh -c rxvt 1270 ?S 0:00 rxvt Having two processes per process is annoying. Well, as I understood the discussion, this problem can be fixed by solution 'A': A) None. Just encourage people to use exec or in their menu items. If that is true, 'A' is the most lightweight and easiest solution; just a little of docu needs to be added in the default menu-file to make people aware of this thing. So, my vote is 'A'. No unnecessary code in the wm, no loss of speed or memory, developers can focus on other interesting fields (like the 'make menus keyboard-navigable'-discussion) gm --- [EMAIL PROTECTED]
Re: sh -c answers thanks!
Yes... I agree! (all I want is to acess menus whith the keyboard and 'walk arround' them with keys...) Pepe On 30-May-2001 Markus Ottenbacher wrote: If that is true, 'A' is the most lightweight and easiest solution; just a little of docu needs to be added in the default menu-file to make people aware of this thing. So, my vote is 'A'. No unnecessary code in the wm, no loss of speed or memory, developers can focus on other interesting fields (like the 'make menus keyboard-navigable'-discussion) gm --- [EMAIL PROTECTED] -- João Pedro Franco e Silva Wireless Development Team Quadriga, SA Av. Gen. Norton de Matos, 59A - 1C Miraflores, 1495-148 Algés Tel. 214135670, Fax 214135678
Re: sh -c answers thanks!
Hi! A) None. Just encourage people to use exec or in their menu items. (Or force everyone to use bash :) B) Eliminate the ability to run compound commands in menu items and rootCommands. C) Eliminate the ability to run compound commands in menu items, but leave it in for rootCommands. D) Provide two menu items, say [exec] and [cexec]; the first would just use sh, the second sh -c. rootCommand would still use sh -c. For the most part this would make things work like they used to before the exec code was changed. E) Provide two menu items, say [exec] and [sexec]; the first using sh -c and the second using sh. rootCommand would still use sh -c. I vote for A: maximum functionality with minimum work. My second choice goes to D and E: preserve the functionality. And me too, I would love keyboard-navigable menus. Regards, Edgar. -- Edgar Bonet Tel :+1 607 255-9349 LASSP -- Cornell University Fax :+1 607 255-6428 Clark Hall e-mail : [EMAIL PROTECTED] Ithaca, NY 14853, USA web :www.edgar-bonet.org
Re: sh -c answers thanks!
On Wed, 30 May 2001, Jeff Raven wrote: A) None. Just encourage people to use exec or in their menu items. (Or force everyone to use bash :) No. Using exec or still starts the initial /bin/sh. Even though it eventually closes this is a waste. D) Provide two menu items, say [exec] and [cexec]; the first would just use sh, the second sh -c. rootCommand would still use sh -c. For the most part this would make things work like they used to before the exec code was changed. E) Provide two menu items, say [exec] and [sexec]; the first using sh -c and the second using sh. rootCommand would still use sh -c. But what about not using any /bin/sh? I prefer F) F) Provide two menu items, say [shexec] and [exec]; the first using sh -c and the second not using any sh. rootCommand would still use sh -c. (If users want old behaviour, they would need to change their [exec] menu entries to [shexec].) (I am sure you saw it, but I did provide a patch that works for me the past week.) Jeremy C. Reed BSD software, documentation, resources, news... http://bsd.reedmedia.net/
Re: sh -c answers thanks!
But what about not using any /bin/sh? I prefer F) F) Provide two menu items, say [shexec] and [exec]; the first using sh -c and the second not using any sh. rootCommand would still use sh -c. (If users want old behaviour, they would need to change their [exec] menu entries to [shexec].) (I am sure you saw it, but I did provide a patch that works for me the past week.) this would definately be appreciated.
Re: sh -c answers thanks!
On Wed, 30 May 2001, Sean 'Shaleh' Perry wrote: But what about not using any /bin/sh? I prefer F) F) Provide two menu items, say [shexec] and [exec]; the first using sh -c and the second not using any sh. rootCommand would still use sh -c. (If users want old behaviour, they would need to change their [exec] menu entries to [shexec].) (I am sure you saw it, but I did provide a patch that works for me the past week.) this would definately be appreciated. http://www.mail-archive.com/blackbox@trolltech.com/msg02458.html http://www.reedmedia.net/misc/blackbox/patches/shexec-patch Jeremy C. Reed BSD software, documentation, resources, news... http://bsd.reedmedia.net/
Re: sh -c answers thanks!
On Wed, 30 May 2001, Jeff Raven wrote: D) Provide two menu items, say [exec] and [cexec]; the first would just use sh, the second sh -c. rootCommand would still use sh -c. For the most part this would make things work like they used to before the exec code was changed. E) Provide two menu items, say [exec] and [sexec]; the first using sh -c and the second using sh. rootCommand would still use sh -c. Umm... As far as I can tell (and I just tested it) 'sh command' will NOT work, unless command is a shell script. 'sh -c command' tells sh execute this command without entering interactive mode. 'sh command' says execute this shell script using the shell. Also, was my execute semi-patch totally ignored? (http://www.mail-archive.com/blackbox@trolltech.com/msg02459.html) I haven't had the time to do a correct patch, because I've been working on some new software that has been a total PITA to write/debug/smash with sledgehammer. --gile -- Anyone can be a winner, unless there's a second entry.
sh -c answers thanks!
Thanks to all who replied, using either the exec or the before and after an application in the menu eliminates the sh -c processes. They occurred using zsh, ksh and bash on sunos/sparc. -- Scott --- Kirk to Enterprise -- beam down yeoman Rand and a six-pack. -- Kirk, The Corbomite Maneuver, stardate 1514.0
