[Pan-users] Re: VDQ : can I double Pan?

[Duncan]

Beartooth <address@hidden> posted
address@hidden, excerpted below, on  Mon, 07
Aug 2006 14:23:51 -0400:

> On Mon, 07 Aug 2006 17:24:19 +0000, Duncan wrote:
> 
>> [Charles said] set the environmental variable $PAN_HOME="path", to
>> different paths for each instance.  =8^)
> 
> [S]eems like something a real technoid could do in the dark [b]ut I'm no
> technoid at all. Environmental variables are one of those things that
> stymie me[.  Something like this as root, maybe?]
> 
>    % echo $SHELL
>    /bin/bash
>    % PAN_HOME=$HOME/.pan2-real ./pan
>    % PAN_HOME=$HOME/.pan2-weather ./pan

> It gives me the galloping fantods even to think of making up and then
> *doing* things as root. 

Good for you!  I wish a few more folks would be aware of "taking the name
of root in vain." =8^)  (BTW, "galloping fantods"?  Interesting imagery
there! <g>)
 
> So, instead of taking Charles's time from development, I'll ask [others]
> here -- can you put that into words of one syllable, that I can walk
> through? I sure would like to do it.

As Walt said, many different ways to do it.  Here, it's strictly a single
user preference/config issue, so a single user solution is most
appropriate.  Thus, you're in luck, no "root" needed! =8^)

As an aside, however, do note that on a typical single-human-user system,
or one where a single-human-user does most of the actual "using, even if
there are other human-user accounts, it can actually be as bad having
something mess up as that user as having them do it as root.  After all,
consider that most of the stuff root takes care of can simply be
reinstalled, and one should have backups elsewhere of system-specific
config files such as xorg.conf that might be hard to recreate out of the
blue if one doesn't understand them.  OTOH, it's quite likely that a fair
share of many user's documents and customized configurations are /not/
reliably backed up, and would take far longer to replace, if it's even
possible.  Thus, while a (do NOT try this!) rm -rf ~/.* as a user somewhere
in your home directory tree wouldn't kill the system, for many users on
many systems, it would be worse than killing the system while leaving the
home filesystem intact, because it would remove their entire home dir
subtree, with all their documents in it!  Just something to think about.

Back on topic...  for each "non-default" instance you want to run, create
a new text file with an appropriate name in an appropriate subdir of your
home-dir.  Walt's suggestion of "~/bin" as the subdir is the standard
location.  Here, however, I have "~/config/bin" for such things, keeping
as many things out of my "root" homedir as possible.

Since these text files are going to be shell scripts, I like to put
something in the first line making that plain.  Two additional lines
complete the script, one setting the variable, the other calling pan. 
Completed, the three-line script looks like this:

#!/bin/bash
export PAN_HOME="~/pan-gmane"
exec pan

A bit more explanation:  The first line is often referred to as a shebang.
It's a quite common convention telling many common parsers what executable
to use to interpret the script.  Another example, were the script written
in python, might be #!/bin/python, another would be #!/bin/perl.  Most
parsers including the three just mentioned will see the last line and hand
execution to the appropriate script parser, if it's not them.  Thus,
running the above script in python will still cause bash to be called to
run that script, since that's what the shebang says should be used.

The second line sets and exports the $PAN_HOME environmental variable.  If
it's not exported, bash would see and use the var in this script only --
pan wouldn't see it and that's our object, so we export it.  Note that
this does the same thing as the single-line script walt used, only it's
easier to follow since only one thing is done at a time.  The
double-quotes around the value ensure that the entire thing gets into the
variable.  Here it doesn't really matter, but if there was a space in the
path, say, it /would/ matter, as the path only upto the space would be set.

A hint when dealing with sh or bash variables:  When you set/write them,
you do NOT use the beginning $ symbol.  Any time they are referenced/read
(not written), you use the $.  That's why we don't say $PAN_HOME, because
we are writing the value here, not reading it.

The last line does something a bit different than walt's solution.  "exec"
is a bash internal command that tells bash to replace its own process
with that of the following command. If we had just said "pan", the script
would have run pan, then waited around until pan exited to read the next
line.  Since there is no next line, it would have then exited too, but the
thing is during the entire time that instance of pan was running, there'd
be additional resources being used in the form of the script, still
sticking around, waiting for pan to exit so it could continue the script
and itself exit.  The "exec" handles things differently, in that the bash
instance itself hands control over to pan -- if you a process lister and
it updates fast enough to catch bash while it's running, it'll show bash
as a new program with a new PID (process ID), then pan will start, using
the same PID, directly replacing the instance of bash, using the same
resources bash /was/ using.  Note that because we used exec, even if there
were additional lines in the script, they'd never get executed, because
the bash instance would be replaced with pan, so there'd be no bash left
to go back and finish the script after pan was done.

I just don't like stub scripts hanging around using resources for no
reason, when all they are going to do when that last command exits is exit
themselves.  In such cases, "exec" does exactly what I want.

A somewhat less resource efficient way of making the bash script exit
would be this line:

pan &

The "&" tells bash to execute that command in the "background", and once
launched, to continue with the script.  Here, that's less efficient,
because it executes pan as a /new/ process, rather than using the old one
which was just exiting anyway.  However, if you wanted to start a bunch of
stuff at once, you could use the "&" to background each thing as you
started it, so the script would go onto the next thing, without waiting
for the first to exit.  Again, since all we are doing here is exiting
anyway, it would still cause the bash script to exit instead of hanging
around waiting for pan to finish, but again, because it launches pan in a
/new/ process, it's slightly less efficient than simply reusing the old
process that's already launched and will just be exiting anyway.

The other difference here, as compared to Walt's version, is that I'm
assuming pan is on your default search path, so you don't have to specify
path directly.  It's slightly less efficient than specifying the absolute
path, but it's more flexible.  If you install pan from the tarballs, it'll
be located by default in /usr/local/bin/pan, whereas installing it from a
distribution's package management system will probably locate it at
/usr/bin/pan, and if you install it as a user not root, you might have it
at ~/bin/pan or something similar.  Just saying "pan" lets the shell use
its normal path mechanism to find pan, and will find all the above
locations, if they are in your path, while specifying the absolute path
will only work as long as pan is there.

Now that you have your scriptlet file, save it and change the permissions,
setting it executable for your user.

That brings us to the next step.  Now that you have your files, you
probably want them on your path, so you can just call them as "pan-gmane"
or whatever you called the script, instead of having to call it as
"~/bin/pan-gmane" or wherever you located it.  It's possible you already
have the chosen subdir on your path, particularly if you chose ~/bin/. 
Check with the following at your shell prompt:

echo $PATH

That should give you a colon delimited list of all the places checked by
default for a command that's invoked without a specified path.  If the
subdir you chose for the scripts is there, great, skip editing your path.

If you don't know how to change your path, it's pretty simple, actually. 
You should have a (hidden) file ~/.bashrc.  Open it, and add a line
with the path of your scripts similar to the following:

PATH="$PATH:~/bin"

That will add the bin subdir of your homedir to your path, at the END, so
it is searched AFTER the rest of your path.  This is significant if you
have two commands on your path of the same name, as it'll always find and
execute the one in the first location listed, and never reach the second. 
If you want your addition searched first, well, put it first, as so:

PATH="~/bin:$PATH"

BTW, there's three O'Reilly books, depending on your level, that should be
very helpful at learning bash scripting.  Running Linux is a general
text-book or tutorial like orientation to Linux, particularly Linux at the
command line and system level, in general.  Very good, and it has a
section on bash that covers the basics.  Linux in a Nutshell is more a
command reference book, with one of its appendices covering bash.  That's
the one I continually reach for, to verify the various condition switches
of the "test" command, for instance, long after I've attained a working
familiarity with bash.  I've read both of those, and continue to
repurchase updated editions periodically -- yes, they /are/ that good! 
The third one I haven't read and don't recall the exact name of ATM, but
it's an entire book dedicated to bash scripting.  It would obviously be
for those wanting something more in depth than the short coverage of the
previous two books can provide. I'm considering it, as I know there are
advanced techniques I have yet to master, and I'm sure it will help.

> Btw, being what I am, I'm holding off any upgrade until either the
> version number hits 1.0, or Fedora's yum update does it for me, or both.
> I use Pan much too heavily to risk anything beyond 0.14.2.91 just yet,
> and for things I can't go on without ...

Understood.  Betas aren't for everyone, particularly not if it's something
you are unprepared to have going wonky on you.  Until 0.105, I was
recommending that folks stick with 0.14.x even when 1.0 came out, unless
they really needed either the automated multi-server or better memory
scaling.  Charles surprised me and put some features into 0.105, however,
that he'd previously talked about delaying until the pre-1.1 1.90 or 1.900
series.  There's still some stuff that old-pan does better, particularly
for folks doing only or mostly text, but I think 1.0 should be as good or
better for most, including mainly/only text group users.  It WILL take a
bit of getting used to, and personal thinking and habit retraining,
however. There's no getting around that, as it's a pretty big change, but
I can honestly recommend it now.  I'm really looking forward to that 1.0
now, to the point I can almost taste it, one reason I'm recommending all
feature requests be considered for post-1.0 now.  Only real bugs should be
getting fixed now, or we'll be adding more.  Of course, sometimes, what's
a "real bug" can be opinion, of course.  I seriously dislike pan's current
smooth-scrolling behavior, for instance, as it induces a feeling very
similar to motion sickness (as previously posted).  However, some
(presumably those not so affected <g>) would consider an toggle for that a
feature rather than a bug.  I hope that option will make it into 1.0, but
I'll understand if it doesn't, and just continue avoiding "space" for
"read more" since the effect is so personally unpleasant.

-- 
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