On Fri, Mar 4, 2011 at 02:31, Duncan <1i5t5.duncan@xxxxxxx> wrote:
>> 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! =:^)
>
That's what I thought too: Why didn't I think of that?
>> 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. =:^(
>
> 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.)
>
I did not realise that I could use the bash help on that. Thanks, that
is enough to get me started.
> 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.
>
That is handy!
> 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...
>
I had never heard of disown, thanks.
> 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.
>
Oh my. Now we're getting complicated, let's see how long I can hold on.
> 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.
>
Whew. I'm still here. This post is a rodeo.
> 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.
>
I see.
> 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"! =:^)
>
If anything, I very much enjoy reading your detailed posts. They
elucidate so much information that I save them to read later, to keep
learning. Seriously, when you write the *nix book I'll be the first
in line to read it.
> 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.
>
I had all these shortcuts set up at one point but I'm not really sure
how they got lost. I distro-hop sometimes, I'm sure that has something
to do with it. I should probably dig them out of some backup.
> <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>).
>
!!!
--
Dotan Cohen
http://gibberish.co.il
http://what-is-what.com
___________________________________________________
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.
