Dotan Cohen posted on Thu, 03 Mar 2011 22:28:19 +0200 as excerpted:
> On Thu, Feb 24, 2011 at 06:37, Duncan <1i5t5.duncan@xxxxxxx> wrote:
>>> Like you, I prefer to launch with a keyboard launcher.
>> I believe part of the issue may be that krunner checks more than just
>> the shell-path.
> Thanks. The Firefox in the Lancelot menu is in fact ~/.bin/firefox.
> Disabling the "command line" in Krunner fixed it, it is now running
> ~/.bin/firefox. However, there are other wrappers in ~/.bin that are not
> in the menu and naturally stopped working. I'll just add them all to the
> menu.
Yeah, that kinda sux... but at least there's a workaround...
> Other than that, I learned a long time ago to disable Nepomuk in Krunner
> and the Nepomuk service.
=:^)
> No, just one with the gear icon. It points to /usr/bin/firefox. But you
> are right, I can simply tab over to the firefox with the kitty-titty
> icon and launch from that.
> http://www.humorhound.com/wp-content/uploads/2008/10/firefox-boob-cat.jpg
Interesting. =:^)
>> You have a couple choices to modify this (beyond turning off
>> unnecessary krunner plugins as mentioned above). ÂFirst, you can edit
>> your firefox menu entry
>> Second, you can either rename your ~/.bin/firefox entry to something
>> unique (firefx, fx, ffox, whatever), or create a uniquely named symlink
>> in the same dir to the existing firefox entry. ÂSuppose you choose
>> ffox. Hopefully, that won't conflict with anything else [so] typing
>> ffox in krunner will get you the desired ~/.bin/ override.
>>
> Editing ~/.bin/firefox to something else would quite defeat the purpose
> of a wrapper, but I could wrap the wrapper with a unique name.
That'd be what I'd probably do... and actually do do in other contexts.
For example, gentoo's portage has an "esync" (gentoo tends to use e* for
many of their gentoo-tools, including "emerge", the portage package
manager's main binary name) command that syncs the local package tree with
the remote. I've chosen the "esyn" (lacking the terminating "c") moniker
for my wrapper, which among other things, syncs overlays as well, and pre-
downloads the sources for the packages to be updated.
As most sysadmins, I tend to like short commands for stuff I'll be typing
a lot (thus the wrappers in the first place, since many of them simply
include a pre-cooked default command line), so ffox or ffx or simply fx
might well be the operational name on my wrapper. Occasionally, I even
check $0 in my shell-scripts and base the default command on what that is,
thus allowing me to create a whole host of different defaults, by simply
symlinking different command names. (Changing command personality based
on what it is run as, thus allowing different symlink/hardlink names to do
different things, is a not uncommon Unix trick; most definitely it's not
original to me.)
>> Try this (in krunner) to see what settings kde/krunner are actually
>> getting:
>>
>> env > ~/krunner.env
>>
>> Then open the file in a text editor to see the results.
> Nice thinking there!
I'd love to claim the credit, but IIRC it was Kevin Krammer that
originally posted that tip. I just filed it away for use whenever I
needed it, as I have a couple times since. =:^) Given that he's a kde
dev, I imagine it might be somewhat common knowledge among the devs, who
after all likely have various env settings they want to check from time to
time, as well.
Wherever it originated, seeing it posted immediately triggered one of
those "Duh! I should have figured that out!" moments that we all have from
time to time. It /is/ nice thinking! =:^)
> alas, it is not working as expected (krunner
> opens binaries in /usr/bin instead of ~/.bin even though the latter
> precedes the former in the PATH).
That's... frustrating, for sure.
>> I suspect it might well be working as it does here, because I login at
>> the CLI, then run "k" (actually, generally ". k", so it logs out the
>> existing CLI login after starting), a custom script which:
>>
> What does that dot do? I don't see how I could google that!
Unfortunately, there's some things google isn't too good with. =:^(
(Of course this is one of my secondary objections to the renaming of
kcontrol to systemsettings, as well, kcontrol is reasonably googlable,
systemsettings... not so much! IMO whoever came up with that rename
should have their memory of where to find kde's control options
cauterized, so they are forever forced to have to google systemsettings
and sort thru the mess they created to figure out how to set anything!
The same thing applies to ksysguard/systemmonitor, too!)
Enter "help ." at a shell (presuming bash here, I'm not sure whether the
"help" builtin is in POSIX sh or not). That gives you the "official"
version. (You can use "help <builtin>" for any bash builtin to get a
short explanation of the command, similar to the --help command line
option for most stand-alone commands.)
Perhaps more practically, a single . as a command, followed by whitespace
and another command, is a shortcut for the "source" builtin (the help
output is identical for both, save for the name, of course). "source"
simply means "run in the current shell" not as a child process, as would
normally be done. There are two primary reasons I use it, instead doing
the default child process thing.
First, because it executes the content of the called script in the
/current/ environment, it allows setting environmental variables, etc, in
the /current/ environment, whereas otherwise they'd disappear along with
the child process when it terminates. Thus, if I will be repeatedly using
a complex environment with a lot of shell variables, shell functions, etc,
but don't want to pollute my /normal/ shell environment with them, I can
set them up in a script, then when I want that environment, simply "source
<scriptname>" or using the shortcut ". <scriptname>" and "like magic" all
those shell vars/functions, etc, "appear" in my current environment, as if
I'd typed them all in manually. Without the ./source in front, the script
would be invoked as a child process and when it finished, the vars/
functions it setup would disappear with it -- nice when that's what you
want, but frustrating when the whole object is to get them in the
/current/ environment, without having to type them all in.
Second, and the reason I use it to call my kde launcher (simply "k", I
/said/ I liked short commands! =:^), for stuff that's going to be running
for awhile, it allows one to:
a) launch the long-term process in the background using "<command> &" (the
terminating "&" uses shell job control to launch the command in the
background).
That's what the "startx &" bit is doing, issuing the startx in the
background, so the script continues running instead of hanging around
waiting for startx to finish.
b) (sometimes necessary to avoid a termination race condition) sleep a few
seconds to let the backgrounded task actually start. I've found that if
the steps below happen too quickly, sometimes the script terminates before
the launch has actually properly occurred, and it doesn't happen.
Sleeping a couple seconds seems to allow the new process to properly
background before the below occurs, eliminating the race.
This would be accomplished with a "sleep 2" or some such. As it happens,
in this case it doesn't appear necessary on my system, so the script as I
posted it doesn't include the sleep.
c) call "disown -a" to "disown" the just backgrounded app. This prevents
the SIGHUP normally sent from the parent to its children when it exits
from terminating its backgrounded childen as well... Terminating what was
just launched along with the launcher rather defeats the purpose of a
launcher script! =:^)
Obviously, that's what the disown -a does...
d) explicitly exit the launcher script. Again, the disown above prevents
this from SIGHUP-terminating the children just launched. And of course,
the whole bit of the script beyond the backgrounded launch executes
immediately, instead of hanging around for the launched process to exit,
because the launched process was launched in the /background/. The
"explicitly" is important, see the next step.
The exit 0.
e) THE POINT OF USING the "."! =:^) Because I launch the script with ". "
aka "source ", it executes as part of the /existing/ shell, instead of as
a child. Thus, the explicit exit in step "d" above exits not JUST the
child, but ALSO the current shell which invoked the launcher.
Thus, the effect is as if I had manually run startx in the background (so
I get the shell prompt back), manually disowned it, then manually exited
my current CLI session.
So:
If I run it as ". k" it exits the CLI shell I logged in at, which is often
what I want it to do, if all I'm doing is starting X/KDE.
If instead I run it simply as "k", it runs in a child process, so the
explicit exit only applies to the child process, and I keep my CLI login
around.
The point is that this way, I get the choice, depending on whether I
prefix the "k" with ". " or not. If I'm just launching X/KDE, I'll use
". k" and exit the CLI login since it's just sitting there using extra
memory otherwise. If I'm testing/troubleshooting something (maybe a new
xorg.conf option, or an X that won't start because I updated xorg-server
to a new abi-incompatible version and forgot to rebuild the xf86-input-
evdev and xf86-video-ati drivers I use for the new abi, as happened
recently when I upgraded to xorg-server 1.10...), and expect to be back in
the CLI relatively quickly, I'll often run it without the ". " as simply
"k", so the current CLI login stays around, and I don't have to repeatedly
enter username and password again and again, testing X/KDE sessions likely
to last 3 minutes or less.
FWIW, similar to source/. is the "exec" builtin, which basically does the
same thing, except with any binary. So running "exec command" will
transfer control of the existing process to "command", instead of starting
"command" as a new child process. (The PID, process ID, of the script
before the call to exec will be inherited by the exec-ed command. In an
advanced script, therefore, one could use this handy bit of knowledge to
for instance pass the automatically set $BASHPID variable to some control
process, then exec the command that is intended to be controlled, so it
inherits $BASHPID as its PID as well. The control process could then do
its thing using the PID it was passed as $BASHPID, since that's now the PID
of the target that was exec-ed. ... Tho I've not actually needed to use
exec for that purpose, but it's nice to know that I can. I normally use
it simply for the slight resource conservation and speed, since exec
eliminates some of the new-process setup overhead.)
Thus, the two practical reasons I use ./source are (1) to allow me to
import a working environment setup in a script, and (2) to allow me to
exit the current shell when I exit the called script.
[Previously posted CLI-based kde start script, and discussion, omitted.]
> I'm not sure that I want to start messing with all that, especially as
> this clearly looks like a bug. And there is an easy workaround: wrap the
> wrapper. But it is good to know. Thanks.
>> As an aside, I've been sick a couple days. ÂI'm getting better now, but
>> am rather bored ... so I have more time to reply in depth than I usually
>> do.
Yeah, I knew that was a bit much as a solution. However, given that I had
several times mentioned that I start kde from a CLI login, using a script,
and I was as I explained bored and had the time... I figured someone
either now or coming across it later might find something useful therein...
And it /did/ provide the context for your question about source/. , so if
you or someone else finds that useful... there's the "something useful
therein"! =:^)
> Well, it did take me a week to get back to you, but I hope that you feel
> better. The wife was also sick last week. Hey...
/MUCH/ better now, thanks! =:^) Nothing like being sick for a few days to
make one SERIOUSLY appreciate the health they kind of take for granted
much of the time. =:^)
>> Since you mentioned a preference for keyboard launching...
>>
>> Have you tried kde's launch shortcuts?
> I did have this at one point (Tux-1 through Tux-0 for launching my top
> ten apps). But I happen to like launching by name. I plan on doing
> something else with those controls, such as macros or some such.
FWIW... Here, I use the Meta/Win/Tux key as my (X-)windows key. =:^)
Seriously. I use Win-End to... what else... end (close) a window, Win-
Insert to "insert" the window menu (normally alt-f3), Win-PgDn to
minimize, Win-PgUp to maximize.
... And for other window/window-manager (kwin) related shortcuts, Win-C
triggers the cube-desktop-switcher effect, Win-G the desktop-grid, Win-S
toggles desktop effects, Win-Ctrl triggers the mouse-finder stars, Win-
Ctrl-Up the ZoomIn effect, Win-Ctrl-Dn ZoomOut, Win-Ctrl-Left ZoomNormal...
I find mapping the Windows key to (X-)windows actions both intuitive and
far easier to remember than the rather arbitrary Ctrl-f11 type shortcuts
kde defaults to for some of these. Also, Ctrl and various fN keys can be
used for other purposes, thus creating conflicts, while the Windows/Meta/
Super/Tux/whatever key is traditionally system-reserved and not always
available, so is relatively unlikely to conflict with app-specific
shortcuts.
Of course, that's doable since I use the multi-key approach for my app-
launchers (and have several additional keys on my Logitech keyboard that I
use for the purpose). If I didn't have that, as was the case before I
setup my own scripted system for kde4 after kde4 killed the functionality
that worked so well for me in kde3, I'd be (and WAS!!) at a /terrible/
loss! Until I could find a workable solution for that, kde4's loss of
multikey hotkey launching was a GAME OVER as far as switching to kde4, for
me. Fortunately, I'm just stubborn and just bash-script-skilled enough to
hatch a workable solution, once I had that insight regarding multikey,
that what it was, was simply configuring the first as effectively a menu-
launcher for the second.
>> Meanwhile, my needs, based on kde3 khotkeys' ability to take multi-key
>> input (not available in kde4, I've referenced the bug many times here)
[snip, snip, snip...]
> This is quite the scroll you have compiled! I will have to reread that,
> but I see that there are some goodies in there that I want to learn
> from. Thanks, Duncan, your posts are always very informative.
> Informative enough to take me a full week to digest!
<g> Well, as I said, I was sick... and bored... so my usually /quite/
detailed replies became /very/ detailed indeed! =:^O But it solved the
boredom issue... and I've enough experience with my posting style by now
to know that often, way more people than simply the original poster find
my long replies at least moderately useful and informative (even when the
original poster doesn't), so ... I guess it's all good (even if I also
realize it drives certain others to absolute distraction... but then
that's what kill filters are for if they find it /that/ terrible to deal
with <shrug>).
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
