So far I would say that most of us have seen the bbs shell. I know of the C Shell and the Bourne Shell from the initial newuser stuff. What are these shells and how would we switch to them if we've already gotten setup with bbs?143 responses total.
I used to use bbs shell, but of late I use csh. I changed it by asking
popcoror remmers to do it for me. The thing I like about it is the alias
commands... which are useful.
if ($?prompt) then
set history=200
alias hi history
alias so source
alias p bbs
alias z elm
alias a logout
alias hi history
alias g backgammon
alias tset '/usr/ucb/tset -s \!* >/tmp/ts.$$ ; source /tmp/ts.$$ ; rm
/tmp/ts.$$'
endif
this is what I use for my commandsthey are easy, and quick.
You can also change your shell using the chsh command. Just type !chsh at any Picospan prompt (or just chsh at a Unix prompt), and enter a new shell. Valid shells are: /bin/sh - the Bourne shell /bin/csh - the c shell <---- My personal favourite /usr/local/bin/tcsh - an improved c shell /b - Picospan If you're interested for a decent .login file for csh to get you started on your own, look at mine: ~power/.login.
This response has been erased.
This response has been erased.
But the tip about gripe or help IDs has many other possible applications.
Hmm... Maybe we ought to put a wrapper around chsh that automatically creates default initialization files for people. Shouldn't be too hard to do.
#6: If someone does create a wrapper that checks and makes default init files, make sure it checks for pre-existing ones! It would be pretty vexing to have my .login file overwriten because I switch to sh for a few minutes and then back to csh... Also, for you silly IBMers out there, a Unix shell is something like a DOS prompt (as in the C:\ prompt). If you're competant with DOS, DOS is basically a ripoff combining CP/M and Unix, so Unix should be fairly easy to pick up.
This response has been erased.
Heh...good point. I've got my csh going now, but for a day I was locked out of the bbs. Still not sure what all I want in .cshrc and .login, but for now it's working... Apparently chsh totally wipes out your old .login.
You can always try out a shell, just by typing ! by itself. This will stick you into a Bourne shell, I believe. This is, of course, meant to be typed coming from PicoSpan.
Hm. I'd assumed it gave you your own default shell. (I use sh, so the difference was not apparent.)
You're right, it gives you your standard shell. (It gives me csh.)
This response has been erased.
Could be...my .profile is okay, so maybe I just didn't have much in .login. Definitely didn't have a search path; I wonder why chsh doesn't putin some sort of generic search path? Anyway, it's working now thanks to popcorn's help. Time to explore the wonderful world of Unix...
Forgive me if I'm being dense, but I'd like
to see a step-by-step procedure for setting up a
unix shell. I know something about unix,
but I wish to learn more, and I think it's time for
me to start using a unix shell rather than the bbs shell. So what
do I have to do in order to set up a shell. Which shell
should I use? (What that means is: what benefits
are there in the different unix shells?)
Chris
This response has been erased.
As Roger Rabbit would say: "P-P-P-P-P-P-Please!"
About all I can sayis that there are 4 shells here; bbs, C-shell,
Bourne Shell and Korn Shell. There are probably others. bbs shell
"seems" to be the easiest to use, it immediately pops you into
a "something" rather than a "nothing."
You can "shell out" to any of the others (maybe you can create
your own) and use the associated commands. About the only difference
I can detect (and I'm *really* new at Unix) is that there are
more commands and easier syntax in C-shell.
Quoting from _Unix in a Nutshell_ (O'Reilly and Associates, 2nd Ed,
(c) 1992) ISBN: 1-56592-001-5; "There are three main uses for
the shell: Interactive use; Customization of your UNIX session; and
Programming."
"A UNIX shell defines variables to control the behavior of your UNIX
session. ... Some variables are preset by the system, ... others
you define ... in start-up when you login."
A reference to DOS Batch files is made (and is accurate).
"This quick reference describes the three most popular shells:
The Bourne (or standaared) shell, the most compact but also
the simplest.
The Korn shell, a superset of the Bourne shell that lets you
editthe command line.
The C Shell, which uses C syntax and has many conveniences."
My perception, as primitive as it may be, is that unless you are
involved in some seriously intensive programming, the shell you
use is not all that relevant, objections welcome.
It's almost the same as editor "wars," what you grew up on is what
you know best and, conswquently, prefer. Vi, Emacs, Jove, Ed, Ex, and
Marcus's Bbs editor all function well, within their parameters.
UNIX is a fairly "wild west" territory accessible to tons more
people than earlier Operating Systems, i.e. DOS, CP-M,
main-frame OS's from main-frame maunfactureres, or micro-computer
Operating systems from Amiga, Apple, Macintosh, Atari, Etc ....
In summary, (geeze, have I typed THAT much), buy every O'Reilly
book you can find (and I <unfortunately> own NO stock).
If you are comming from DOS, a book entitled, _DOS meets UNIX_ is
someplace to start.
Quoting from a friend of mine, UNIX is " a multi-tasking, multi-user,
interactive Operating System," which to me means a main-frame in
the palm of as many users as there are tty ports connected.
Personally I found sh syntax easy to master, & every time I've tried to use csh I've gotten tangled up. Obviously a matter of taste and background. (For the Unix I've worked with most there's a command-line editor available for sh, removing my single largest temptation to tackle that learning curve.) Whatever shell you use, expect to spend time hunting through the man until you learn all the things you need to use regularly.
The history mechanism and job control capabilities of the C shell are plusses for interactive use. It's nice to be able to re-execute a recently entered command without typing it in again from scratch. And it's convenient to be able to suspend a task, go do something else, and then resume the suspended task from the point you left off. But the C shell has too many syntactic exceptions and inconsistencies for my taste. Too many things that should work but don't because you're bumping into some "feature". The Bourne shell is much cleaner in this respect, so I greatly prefer it to the C shell for programming. The Korn shell combines the best of both, and if Grex had it I'd probably use it as my login shell.
It sounds like the Bourne shell is the one I'm
most familiar with. John, is it similar to the
shell on EMUNIX?
I've actually used UNIX before, so what I need is
the how-to on setting up Bourne as my
login shell. Sorry, I wasn't
clear.
Chris
To permanently change your default shell, enter "chsh". It will prompt you for a new shell; give it sh or csh or whatever. You can really tangle yourself up if you do this wrong! I believe that chsh checks that the program you specify exists and that you have execute permission for it, but it's not guaranteed to be anything that will actually work as a login shell. To *temporarily* change your shell: If you're at a Unix shell prompt, just enter the program name of the new shell. exit (or something appropriate - it's exit for sh and csh) will take you back where you were. If you're at a Picospan prompt, you have to prefix the new shell's name with ! (as usual). If you make sh or csh your default shell, you can bring up Picospan on top of it (as a new shell) by entering "bbs". This takes an optional conference name as a parameter. If, say, you wanted Info as the conference you see first (instead of Agora), you could enter "bbs info".
Re #21: The default shell on emunix is csh. In everyday interactive use -- simple commands, pipelines, input-output redirection -- there's little difference between the two shells. I prefer the C shell to Bourne for interactive use because of its history mechanism and job control. In the more complex situations encountered in programming, I prefer the Bourne shell because it is much cleaner.
So, if I use sh as my login shell, I can then edit a file called .login, putting UNIX commands in it to give me a custom setup right?
No, .login is for csh, the C shell. With the Bourne shell sh, the equivalent file is .profile.
Ok, I'm ready to make the leap from sh to csh. How do I make the chage
permanent? What differences am I going to find other than the prompt? Will
I have to make any changes in my various .*rc files?
Chris, the fearfully ambitious.
Before you try it permanently, I'd suggest just running csh & trying stuff to make sure you know what you're doing enough to get by. Assuming you've done that, the chsh command will let you change your login shell (stored in /etc/passwd, the password file). You can run it interactively by just saying chsh at a shell prompt (or !chsh from a bbs prompt). Or you can give it a username (yours) and a shell on the command line, as: chsh cwb csh (though I think probably it had better be /bin/csh, as that's what a quick scan of /etc/passwd shows for everyone else). I *think* few if any of your *rc files should need changing; these are commands local to a specific program, and to the extent that they give shell commands they'd be mostly specifying other programs. What I don't know about (since I've stuck with sh, myself) is how you should set up control files such as .login and .cshrc and .logout. I believe .login runs instead of the .profile that runs for sh users, but it may be *in addition to* .profile I'm sure someone will say something about these, but you can (make that should) also find a few people around who use csh and look at theirs.
This response has been erased.
Ummmmmm, I just scribbled the above, pending a quick accuracy check from a couple other folks ... When/if it gets put back in, it SHOULD provide directions for a relatively painless, trouble free, (in Unix ... ha!) method and specific directions for making the switch, he said ...
Csh runs .cshrc every time it starts up, login shell or not. After running .cshrc, it runs .login if and only if it's running as a login shell. To change your shell, just type "chsh". It will say, "Changing shell for <username>", print out your old shell, and let you enter a new shell. Type "/bin/csh" for csh, or "/usr/local/bin/tcsh" for tcsh, or "/bin/sh" for sh.
Well, no one replied to the email so just go for it and if it works by establishing those necessary files, fine. If not, create a new ID and email staff ..........
What is the difference between /bin/sh and /usr/bin/sh ?
I want to change my shell to one which uses .profile rather
than .login (this may change later) and would like some help
determining my route. Thanks!
No difference at all - they are in fact the same physical file under two names.
However, if they're not both on your path, your .profile may be non-portable.
I've used the "change" program, but this is the first I've heard of chsh. Is there anything to the change program besides a call to chsh?
And what is the meaning of "portable" within the context of #34?
I'm interested in that, too, John.
I meant that if you exploit the fact that /usr/bin and /bin are the same directory, by putting only one of them in your path, and then try to install your .login or .profile on some other Unix system, you'd be lacking some commands if /usr/bin and /bin are different (which they often are).
Ahh. In other words, a rather simply repairable potential problem. Thanks.
You're welcome. If there's anything further I can do for you, please let me know.
Now that I have /bin/sh as my shell, how can I invoke the bbs command "check" from outside picospan? This is so I can determine whether or not I want to use the bbs at that time...
That's a Picospan command, not a unix command. You can probably come up with some reasonable way to simulate it without running Picospan, but it would be a lot of work (I think). But you can do: echo 'check;abort' | bbs to run the bbs for this one command. Should be reasonably quick. You could also put that into a script & just run the script.
I *could* put it into a script and run the script, if I had a clue as to how
to do that. But, I don't.
I'll try the echo cmd. Thanks.
Simplest thing would be to make it an alias, provided you're using
a shell that supports aliases. In .cshrc you'd put the line
alias check "echo 'check;abort' | bbs"
In .profile, same thing but with an = after the alias name.
I didn't know alias was a valid sh command.
It isn't in sh, but it is in bash.
I'm a newbie who's wondering how the .cshrc and .login files get set up in the first place...I poked around in my files in csh and see that I have a .profile file. How would I get these other files going so that I can use (*try* to use!) the Unix level instead of Picospan? I read somewhere in here that there are default files for newusers but aren't sure how to find mine. Thanks for any help you can offer!
I use the csh for my shell and I pretty much like it. I don't know how
the .cshrc,.login and .profile are created, but I would gather that
one creates thses when you log in. You can get to these files by
using an editor ssuch as vi or jove. (type vi <filename>) at your
shell prompt or !vi <filename> at the ok: (note: dont use the brackets
unless it appears in the filename.
you can change your shell by typing !change or !chsh at the ok: prompt
or withoutb the bang at the %csh prompt.
if you mess up your files, mail root, and they will help,
.profile is set up initially by the newuser program when you first create your account. It is done that way if you select bbs or sh as your shell. If, on the other hand, you chose csh or tcsh, then it would set up a .cshrc and .login file for you. Therefore if you decide to change your login shell the unix way, by running the chsh program (type !chsh at the OK:) this could leave you without the proper configuration files. For that reason (as I understand it) a program was created to run chsh for you, and thus change your shell, but also create these needed configuration files. This program is called change or modify (they're the same). You need to use a ! from the OK: prompt. I have not used this program but I believe it represents the answer to your question, Jan. The author of 'change' is popcorn, and she's the expert in this area.
I thought Marc Unangst (mju) was the author of "change". That's not to say that Valerie isn't an expert, of course.
In what directory do the default .login and .cshrc reside? Knowing that woudl be another route around the problem. OTOH, you could always do what I did when I changed shells, and write your own. It only took me about a month and a half to make grex work well for me again, and I learned a lot about Unix in the process.
The initial .login, .cshrc, and .profile all live in the same file: /usr/local/noton/nu/protos.
Thanks for the help ... I elected to try the "change" program, and it certainly changed my shell, but it didn't create any of the needed files. Being in csh with no .cshrc is no fun!! I'm going to go snoop out the default files if I can find'em.
That's what "change" did to me, when I tried to change to tcsh in the middle of the night. What a mess. I was able to mail srw, who was on, and he helped get me untangled. I cannot explain it all, but "change" put me in tcsh without environment variables (I think).
Just to clarify, "change" does not attempt to give you .cshrc/.login/whatever files, since whatever it gave you would almost certainly be wrong. It's assumed that if you're switching to a non-PicoSpan shell, you'll be able to figure out how to create your own initialization files. (Perhaps this is a poor assumption.) You can snag copies, more or less, of what newuser gives you from /usr/local/grexdoc. You'll almost certainly have to edit them to customize your editor, termcap, stty keys, etc.
Re 55: its a poor assumption. When a newuser has learned a little about files - editing, transfering, etc, it seems logical to login to a unix shell, rather than Picospan. Maybe it *isn't* logical, but it seemed so to me. "Change" was very friendly - menus and all: no warnings for the dummies. Then the lights went out (metaphor). The only way to learn unix here is to experiment, so I would recommend that more things that the inexperienced might find, be made more experimentation friendly (eventually....).
Your shell should still work okay without .login/.cshrc/.profile files; your termtype may not be set correctly, but you should still be able to log in. The problem is that there's no way to give the user a good set of defaults that won't screw up in some situations.
It would be useful to at least set the path in that. When I changed my shell the biggest problem I had was that I could not execute many of the commands I had been used to being able to do.
Re 57: The newuser program seems to have no trouble coming up with reasonable /.login/.cshrc/.login so why not have change run part, but not all of newuser?
That would be fairly difficult and represent a nontrivial amount of work. For one, change is written in Perl and newuser is written in C. Newuser is also not written in a very modular manner.
OK, but if you know how newuser creates the files in question, could you write a similar routine to create them in change?
Marc, would it be that much trouble to pull a version of the default stuff out of the newuser source, if and only if the user doesn't already have the relevant files? (I don't know Perl & don't off hand know where the source is.) Jeff, one definite problem is that the user has (maybe) customized the .profile, and it would not be too good to just ignore that - but parsing it & recognizing what needs translating & translating it to csh or something is not going to be trivial. OTOH, even just ignoring it might be better than what happens now.
Um, ignoring it *is* what happens now. Newuser creates the files in question by pulling prototype versions out of /usr/noton/nu/protos and doing substitutions on them for the user's specified interrupt/erase/kill characters, terminal type, etc. I suppose the existing code in "change" to parse that information could be used to supply default values for the new .login/.cshrc/.profile. Unfortunately I don't have time to make changes to "change" right now, and there are some other more pressing bugs in "change" that should be dealt with first (like the fact that the terminal-type module tends to mangle your .login/.profile if you're using one that looks like the newuser default). I've extracted the .cshrc, .login, and .profile that newuser uses and put copies into /usr/local/grexdoc. Since I had to pick defaults for editor, termtype, and intr/erase/kill, I picked Pico, vt100, and ^C/^H/^U. If you copy these files, you may need to change those defaults.
I snooped out the .login and .cshrc files for myself from the location recommended earlier (/usr/local/noton/nu/protos) and I *couldn't* get them to run no matter what I tweaked. I confess to entering someone else's director and snitching theirs. It's clear (even to a unix moron like myself) what needs to be modified regarding editor, termtype, etc., in these files, but trying to figure out why these default versions wouldn't work at *all* was a bit beyond me. I'm up & running now, though. :)
You did realize that the lines beginning with commas are comments, right? If you take the lines for the proper shells/files, you'd have to replace things of the form ~(tset) and ~(term) with appropriate literal values (such as /usr/ucb/tset and vt100 respectively) to make it work, but otherwise I think it should be OK. (Those comments with leading commas should *not* be included.)
What's the advantage of running a shell ovver running Pico, other than not having to type a ! before the commands?
If I am not mistaken, the bang(!) implies starting a shell, right?
I think he means some other shell as a login shell as opposed to Picospan as one's login shell. Tom (bubbles), it depends on what you want to do, for the most part. If you basically run Picospan & occasionally want to call a Unix command, you have little reason to have a different login shell. If you are used to Unix and used to running a mailer, doing file transfers or compiling programs, say, and you want to do these things and also use the bbs, you may find it more natural to use sh or csh or whatever you're used to and run Picospan when you want to. There's some cost (quite small, I think) to bringing up Picospan on top of one of the shells. There's similarly a cost to calling the shell on top of Picospan.
Picospan shell is really a script that runs under sh and runs bbs. So there's not cost of running the bbs command on top of the sh shell.
Right, in this case, since it does an exec when it runs Picospan. (But in general, running any script brings up a shell to interpret it, and unless you do an exec, that shell hangs around when your script calls a command.)
This response has been erased.
This response has been erased.
Yes, they're working fine now ... stole 'em, as I said earlier. :) I've now got a Unix book big enough to sink a boat, so maybe I'll be able to learnomething about how to customize these further. Thanks!
I have a radical suggestion: Why not have newuser create copies of *both* kinds of initialization files, i.e. .profile *and* .login/.cshrc, regardless of what login shell they choose? That way, if a user changes shells later, at least they'd be reasonably likely to have working initialization files. Even if they need to customize them, they'd have a model to start from rather than having to create them out of whole cloth.
This response has been erased.
Um, *that* probably means rewriting newuser, from what Marc said. I presume we *do* have the source for the current version?
This response has been erased.
In fact, now that I think & look at it, this could easily be done without changing the newuser program at all, I think. Slight modifications of the lines beginning ,f in /usr/noton/nu/protos should take care of it.
But we would then be depriving the shell changers of a very effective and stressful Unix learning experience.
Yeah I remember rescuing a very distressed user once. ;-)
And I remember being a very distressed rescuee 8-{
I think if we're going to provide a user-friendly interface like "change" to assist a user in changing their environment, I think we should make some effort to minimize the liklihood that it will screw people up. Having newuser provide both kinds of login files is the simplest way I can think of to effect this in the case of changing login shells.
At least for the most part, those adept enough to customize their .profile will be able to then customize their .login & .cshrc, I should think. It seems like a really good way to do it.
Does anyone know how to change the prompt in bash?
PS1="the-prompt-that-you-want"
Thank you, remmers. Of course, the user who asked me this has changed to a different shell, but hey, the next time someone asks me, I'll know. >8)
This item has gotten too long to find clear, simple answers. So: Please explain (again?) when .login and/or .profile are called, when one should have one or the other or both, and whether there can be conflicts between them, if one has both.
Normally they shouldn't both be necessary. .profile is used by sh (and by the bbs, if that's your login shell), and is executed once when you log in. .login is used by csh (and, I think, tcsh), and is executed once when you log in. .profile should contain sh commands, .login should contain csh commands. If you use csh or tcsh, you should also have a file, .cshrc, which is executed whenever a new shell comes up (which may happen more often than you think). I'm not sure what bash and any other odd shells we may have floating around use. (Oh, and for tcsh, I think there can also be a .tcshrc - which probably gets sourced instead of .cshrc if it exists - but don't quote me on this.)
And those users with menu or lynx as their startup shell will have .cshrc and .login. Basically, they're running csh, with commands in their .login to put them in menu or lynx and log them out when they finish.
Where is it specified which will be the login shell?
Um, in the passwd file, I believe.
Yes, your login shell is a field in /etc/passwd. You can shange that by running the chsh command, but you should check out your new .profile, or.login beforehand, by running one shell under the other, so as to avoid hosing your account beyond belief
Please explain "running one shell under the other". I am guiding a user in changing shells (which I hope isn't the blind leading the blind), and he now has a .login file, will get (borrow) a .cshrc, but also has a .profile with different term. I'm suggesting rm the .profile, and then run change (modify - should chsh be used instead?). How'm I doing?
Pretty good, but there's no need to remove the .profile, unless you're REALLY concerned about disk space. >8) For now, I'd leave it, in case he wants to change back later. The change program is now capable of chaning shells again, so he/she should go ahead and use that. "Running one shell from another" means that, from the csh prompt, I can type "sh" and will end up in the sh shell. I can then type tcsh, and wind up in a tcsh shell, all three shells stacked up on each other in the computer's memory.
The idea is that you can at least check out your .cshrc by invoking csh. You can also then source .login to look out for egregious bombs there. But if you do this on top of sh before you officially change your login shell, you have two advantages. First, you have some time to learn before you find yourself faced with an unfamiliar shell every time you log in. This is a small advantage. Much more important: if you change your login shell but have errors or the wrong things in your .cshrc or .login (assuming you're going to csh), you can wind up unable to log in or to do anything. If it's merely a matter of your path or something, you can probably work around it *if you know how*; but if it errors in a way that logs you out, how do you fix it? (There are ways, but don't let it happen.)
That's what I was trying to say. Thanks Dave.
Just out of curiosity's sake, how many people have done any sort of scripting in a unix shell? I have tried my hand at three different shells. KSH, CSH, ans SH. Of these shells, I have found that my favorite shell so far is the KSH. The korn shell seems to be the quickest to load. And it seems to offer the nice program branching controls that you become used to when progrmming in high level languages. Anyone have any different opinions? What is better about your shell then any other?
...I just ftp my .login or .cshrc out while logged in on another system, edit out the mistakes (hopefully), and then put the file(s) back. That's one way to get around not being able to log in because your .login is .logging .you .out... (Assumes you have an account on another system with ftp, though). I'd like to hear other ways around, though.
:97 slipped in. Most of the how-to manuals I've looked at recommend the Bourne shell (sh) as the easiest to use. csh has been a pain for me, though I have occasionally had to use it for features it had that sh lacked. I've never tried ksh, sounds interesting. How does it compare to sh for scripting?
I find it difficult to believe that ksh loads faster than sh, since it's much larger. However, if you want to discuss different shells for programming, we should probably do it in a different item (perhaps in the Jellyware conference).
Yes. I'll go enter an item now, unless someone's already done it.
It's now jellyware item #108. Kent, on Grex another way around (not good, yours is better if you can do it) is to create a new account, then do su to your old account (not su -, though), fix stuff up, and then (as your new account) send mail to staff explaining why you did what you did & asking that the new account be deleted. Bleah. If you're personally known to other users in your area, you may also be able to convince them to let you su to your account from theirs, avoiding the creation of a dummy account. Obviously, none of these work if you've lost your password.
This response has been erased.
I think Rane meant removing .profile to save disk space, & then using change to change shells. But yes, make sure your control files all work before officially changing shells. At least once source .login just to make sure it works, then run csh (which should source .cshrc) & run a few things to make sure stuff's all right. (And to make sure you know what you're doing before you get stuck. In this case, the user in question at least has help on hand, apparently.)
I suggested removing .profile because it had term "dumb", and the user didn't know how to edit. I suspected there might be a problem with term set to "dumb" in profile, and vt100 in .login, when using a terminal set to vt100. But tell me - would any problems have arisen?
This response has been erased.
Just to confuse matters, I'm hoping we'll be able to provide zsh as yet another alternative in the near future.
Briefly, what is advantageous about zsh? (I use tcsh currently, why would I like zsh).
To extend on #108, what is the difference head on between zsh and bash. Maybe you all had better make a nice message detailing what is good about each shell?
sh = comes standard with any Unix system.
Smallest shell, not so good for interactive use, quite
reasonable for many scripting chores. Uses .profile
csh = comes standard with the system.
Fairly small, decent interactive shell, only middling fair
for scripting. Uses .cshrc/.login
tcsh = provides "visual" command line editting, perhaps other goodies.
Fairly large, upwards compatible with csh, popular for
interactive use, same disadvantages for scripting.
Uses .cshrc/.login.
ksh = AT&T proprietary, so we don't have it. "visual" command line
editting, somewhat large, good for interactive use if
properly configured, upwards compatible with sh and good for
scripting. Uses .profile (with compatible extensions)
bash = "Born Again shell" - Gnu license restrictions (not an issue
for grex). Fairly large, visual command line editting,
good for interactive & scripting. I think it's also
compatible with ksh & sh. I think it uses .profile
zsh = the Z shell. freeware distribution. Fairly large,
visual command line editting, good for interactive & scripting.
compatible with ksh & sh. Uses .zshenv, .zlogin and .zshrc
We also have these, although there are caveats about switching to these
(and they aren't "real" shells)
bbs "/b" uses .profile
lynx from .login
menu from .login
I described which shells use which dot files. There aren't any real
standards here. Chsh can be used to switch between most of these
shells, but you should get the right dot files and test them out first.
Lynx & menu have to be editted out of .login instead. ^Z has
unpleasant results in lynx/menu. The whole situation is rather a mess,
and does need some changes. I'm hoping newuser can be switched to give
everyone all the dot files, and lynx/menu switched to work like bbs.
But this isn't a simple decision and there are some tradeoffs; other
staff people have some different ideas and it's not clear which will
actually happen.
I was browsing the comp.sources.misc index (v 40-todate) and I think there was a posting listed there for a PD|freeware ksh. Might be worth checking out...
People who are switching shells, but don't have .login or .cshrc, might enjoy the new /usr/bin/icant program. This program will create a .login & .cshrc file based on your current settings. It will pull in your stty settings, editor & terminal type; and give you the option of customizing your editor & termianl type. The program has the "interesting" path so that even a user with a confused path (ie, they switched shells before making sure they had the right dot files) can type "icant". Also, this way, the /usr/local/ gremlin can't eat the file.
Neat! Where'd the program come from?
Ah, I just had a look at it. It's a shell script that evidently came from the brain of Marcus Watts...
Is this safe to run just to see its interface, even though I don't want to change my .login or .cshrc?
my, mdw, that was fast!
Re #115: Yes.
wow!
Thanks, Marcus!!!!!
There's been a thread in a Coop item (about a cf needing a FW) which drifted into a technical scripting discussion of how to find who the current FWs are in different shells. This should be *here*: not only is Coop due for a restart, but it's a good illustration of the differences between sh (and, I think, bash & probably ksh) and csh/tcsh for one important & unobvious construct. Who would look for that kind of thing in an item called "vomit fw needed"? So here it is as of this morning. I've cut out drift about how many archived old cfs there are and so on. > #18 Valerie Mates (popcorn) (Sat, Sep 17, 1994 (08:41)): > Tip for speeding up the process: You can get a list of all fairwitnesses > and their conferences with the command "more /bbs/*/config". That will > include a bunch of other junk, too, but the last line of each file shown > will be the names of the fair witnesses. > ---- > #19 Valerie Mates (popcorn) (Sat, Sep 17, 1994 (08:42)): > (Put a ! in front of the command if you're at a Picospan prompt.) > ---- > #21 Dave Lovelace (davel) (Sat, Sep 17, 1994 (09:47)): > Or, to get just the FWs (and assuming you're using sh): > for cf in /bbs/*/config; do echo $cf: `tail -1 $cf`;done > > (Prepend an exclamation mark if you're at a Picospan Ok: or Respond or pass? > prompt.) > ---- > #22 Valerie Mates (popcorn) (Sat, Sep 17, 1994 (12:29)): > Hey - that works! > There are some real blast from the past names listed there. We are > definitely due for an overhaul! > ---- > #28 From Another Planet (rcurl) (Mon, Sep 19, 1994 (01:28)): > Didn't work for me. What did I do wrong? > /home/rcurl echo $cf: `tail -1 $cf`;done > Bad : modifier in $ ( ). > ---- > #29 John H. Remmers (remmers) (Mon, Sep 19, 1994 (04:07)): > Dave's command is in Bourne shell syntax; won't work for csh or tcsh. Try > > sh -c 'cd /bbs; for cf in */config; do echo $cf: `tail -1 $cf`; done' > > ---- > #30 Dave Lovelace (davel) (Mon, Sep 19, 1994 (05:55)): > Or run sh & then try it, I think. I really don't use csh, but I'm sure it > has some kind of looping mechanism. Somebody might enlighten both Rane > (who *does* use csh) and me. > > (*I* have no reservations about drifting this item off, but possibly we > should take this drift to info instead?) > ---- > #31 John H. Remmers (remmers) (Mon, Sep 19, 1994 (08:58)): > For csh and tcsh, do > > foreach cf (/bbs/*/config) > echo "$cf) `tail -1 $cf/config`" > end > > ---- > #32 Dave Lovelace (davel) (Mon, Sep 19, 1994 (20:15)): > <davel reasserts his own ignorance but questions the second close paren > and the second "config"> > ---- > #33 John H. Remmers (remmers) (Mon, Sep 19, 1994 (23:26)): > Opps, the second /config shouldn't be there. I used $cf) instead of > $cf: because in csh/tcsh, ":" after a variable is taken as a meta- > character. > ---- > #34 From Another Planet (rcurl) (Tue, Sep 20, 1994 (01:11)): > How do I parse that as an alias in .cshrc?
This response has been erased.
I'll ask here too: how do I write vomit#31 (!) in an alias? I tried it several ways, but either it ran it when .cshrc was sourced, or it gave me an error about " ' ".
For that matter (& possibly related), how would you combine your three lines into one line, John? I tried it the same way I'd do it in sh, just separating them with semicolons, and it gives me a question-mark prompt. I finally tried answering end , and I got /bbs/aaypsi/config) danr,chelsea (which I think is just the first one). Is there a way in csh to run a foreach loop as a single-line command? Then, I suppose, the question would be how to attach it to an alias - I also tried a couple of ways to do even my erroneous one, without success there.
This response has been erased.
I've studiously avoided learning much about csh scripting, as I find the language ugly and much prefer sh. So I don't know the answer to your question. I experimented like you did, with equal unsuccess.
I made it work by taking popcorn's suggestion to put the script in a file (/u/rcurl/fwss) with perms 755 and calling that with an alias. I learned that I needed that #!/bin/csh thingy, whatever that does.
But I notice that your script is multiline and doesn't use semicolons. Like davel, I was unable to make semicolons work to separate the parts of a "foreach" loop. That's the main reason I dislike csh programming -- too much inconsistency. There are lots of things that "usually" work but have annoying and unexpected exceptions that bite you when you least expect it. The sh script language is much more uniform and consistent.
Actually, its your script, John, as amended by davel and packaged by popcorn, to which I added a dash of thyme.
OK, since all the standing questions on this are either answered or unanswered: Rane, why do you *need* an alias to list all the FWs? How often do you want to investigate this, for heaven's sake?
This response has been erased.
I believe it defaults to /bin/sh. Re #129: It's not a question of need. It's *status*. Now Rane can say "I'm the first kid on the block to have an alias that lists all FW's."
Remmers is partly right. Actually, I don't really need it, but the
discussion caught my interest at just the time I started to fw a new
(old) cf, so I asked myself "how do I run that with an alias, if I
wanted to?". The rest is, as they say, history (as they say). Leaving
off #/bin/csh leads to an error message due to a "(". By the way, I'm
giving it away, if anyone else wants one. I suspect, though, that
Steve (pick one...) will rewrite it to run in sh to speed it up, or
whatever.
If you leave off the #!/bin/sh (and don't forget the "!"!), I think the script I originally gave is the one you'd want. (If you were putting that in a file as a script, I'd suggest line breaks replacing the semicolons, purely for readability - and my own preferences would include a line break after "do" as well, & indenting the line between the "do" and "done" lines.)
I believe if you leave of the #!, the shell defaults to running it on a child
process of itself. But as far as the bourne shell being all that consistent,
it's not THAT consisten, as I found out when I tried to use the following bit
of code in my .bashrc and had to stick an extra \ in there:
if [ ` stty size | awk "\$1 == 0 {print \$1}" ` ]
then stty rows 25 columns 80
export TERM=vt100
fi
Now, personally, I can't think of a time when I wouldn't want this to work,
butthis doesn't stop bash (or sh) from striping off the \'s twice.
If you're referring to the backslashes in the argument to awk, it looks perfectly regular and consistent to me. The shell normally expands variable references like $1 when they occur in double- quotes. But you don't want that in this case since $1 has to be passed literally to awk -- hence the extra backslashes to quote the $. Another way to do it would be to use single-quotes and eliminate the backslashes.
Right. This difference between ' and " is perfectly standard, in my experience. One difference I have found, however: On the system I've worked with most, echo (a sh builtin command) handles \c at the end of the echoed string as meaning to suppress the newline. (There are a bunch of other ones too.) Here, you have to use echo -n to suppress the newline. The man page here says that echo -e enables the backslash sequences, but when I try it it echoes the -e and does not handle the backslash sequence but echoes it. Bleah. Still, sh is amazingly standardized for such a complex program. Contrast it with ps or something like that, which works very differently here vs SYSV systems (in terms of options). Ditto for many other "standard" utilities.
Do yo[A[A
talk dony@grex.cyberspace.org Who are you?
Do you now how do I change web pages(html)?
I really recommend zsh. ksh is also available on grex now (i assume this is the same public domain Korn shell (pdksh) used on Linux.
i hope ksh here isn't pdksh. and anyone that saddles themselves with a linux distribution that uses pdksh over ksh93 deserves what they get.
Well, I don't use it. Thanks for the info.
help me!!How can i change bbs shell to any other shell?I think I'm in trouble ,since i changed menu shell to bbs shell.Now i type "!change" in OK:prompt and select S then modify the file.Doing these things can not work.System always says "Attemping lock password.....".What should i do ?