[Leaplist] bash/tcsh questions

[Dan Cherry]

On Sunday 03 August 2008 10:54:58 pm John Simpson wrote:
> howdy all-
>
> today i did my first system install using the centos 5.2 cd. (before
> this i had been using 5.1 and then "yum upgrade" to bring it up to
> 5.2; i just hadn't had time to burn a set of cd's yet.) since my
> normal use for linux is on servers (as opposed to desktops, which need
> the GUI stuff) i have gotten into the habit of turning off every
> single package option in the installer, and then after the OS is
> installed, adding the specific packages i need for that machine.
>
> there are a few packages which centos 5.2 doesn't include in their
> "absolute minimum" configuration, which were in the 5.1 "absolute
> minimum" configuration... surprisingly, perl is one of them, as are
> tcsh, nano, lsof, and a few other commands which i consider to be
> absolute necessities on a server.
>
> of course it's not all bad... the only network socket open on an
> "absolute minimum" install is ssh, which is nice- until 5.1, centos
> was kind enough to activate a bunch of useless (to me) and potentially
> insecure things like portmap, nfslock, sendmail, and cups, even for
> machines where you told it you didn't want printing support at all.
>
> this message is going to focus on tcsh. i've been using tcsh since
> sometime around 1993, before bash ever existed. it has a lot of
> features i like, some of which i've never seen in any other shell-
> specifically, it can be configured to notify you whenever other users
> log into or out of the system.
>
> over the years, i've put a lot of time and effort into customizing the
> shell environment to match my work habits- certain aliases i'm used to
> having (such as "d" instead of "ls -laF"), custom prompts, and so forth.
>
> with centos 5.2 no longer installing tcsh by default, and phil telling
> me the other day that tcsh is now considered "deprecated" (i'm not
> sure by whom, but that's what he said) i think it's time to take a
> long hard look at bash as a replacement.
>
> the aliases and the prompts, i can handle (and for the most part, i
> already have.) however, the current versions of bash exhibit one
> behavior which i find extremely distracting- if you have a long
> command already typed, then you go back (using the arrow keys) into
> the command and change something, as soon as you start typing, bash
> visually blanks the rest of the line so you can't see the rest of the
> command.
>
> so if anybody on the list is good with bash, my questions are:
>
> (1) is this visual anomaly a bug, or is it a feature which was
> deliberately added sometime in the past year or two? i ask because i
> don't remember ever seeing bash do this before, and it's been a few
> years since i spent any time playing with it.
>
I don't know if the following will help or not, but I'm using bash 3.2.39(1) 
on kubuntu, and it does -not- truncate the remainder of any commands pulled 
from history when I start typing (behaves like an editor in INSERT mode) 
which matches your earlier recollections.  You might check your 'shopt' 
options, to make sure 'histappend', 'histreedit' and 'histverify' are all set 
to off, and 'extglob' and 'progcomp' are both set to on - though I'm not 
certain they will cause the truncation.  You might also take a look 
at .bashrc, to be sure bash_completion is being run.  That's another place 
where the command line gets hammered on pretty heavily.

> (2) is there a way to make bash do the same thing that "set watch" and
> "set who" do under tcsh- specifically, before printing a command
> prompt, show you any users who have logged in or out since the
> previous command prompt.
>
I googled this tidbit.  You might see if you can add it (or part of it) to 
your prompt???  The only problem with this, is someone could come and go, and 
if you didn't generate a prompt while they were logged in, you'd never know.

#!/bin/bash 
 (who|cut -d " " -f1|sort|uniq)>new 
 while (true) do 
 cp new old 
 (who|cut -d " " -f1|sort|uniq)>new 
 diff new old 
 done 

> (3) what's up with the whole "posix mode" thing, and why does it
> change how variable expansion within double quotes is handled? i'm
> finding a bunch of shell scripts that i've written and which have been
> working for me and others for several years, suddenly not working
> correctly for people using newer versions of bash, becasue variables
> aren't being expanded within double quotes.
>
> the first two items are holding me back from switching to bash as my
> interactive shell right now... and the third one is something which
> the bash(1) man page doesn't explain very well, and i'd like to
> understand.
>
> --------------------------------------------------------
>
> | John M. Simpson  --  KG4ZOW  --  Programmer At Large |
> | http://www.jms1.net/                 <jms1 at jms1.net> |
>
> --------------------------------------------------------
>
> |   Hope for America  --  http://www.ronpaul2008.com/  |
>
> --------------------------------------------------------



-- 
Dan
Finding a solution to a problem doesn't solve the problem...
Implementing the solution, solves the problem

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.