Beartooth <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 _______________________________________________ Pan-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/pan-users
