Slashdot Mirror
What UNIX Shell Config Settings Work for Newbies?
Human_Diastrophism asks: "I'm involved in the roll-out of a new *x-based computing service in my previously Windows-centric organization. I want things set up so that newcomers will understand and like what they see. They should feel encouraged to behave appropriately, i.e. explore and extend the environment for themselves. We're talking about technically literate folk who are simply new to the demands and freedoms of the command line. No shell advocacy, please; it's going to be ksh or bash. What would you put in a .profile or .rc to make things work smoothly and give the user the capabilities and feedback they need? I'm thinking about stuff like 'stty erase ^H' and 'set -o emacs' so the edit keys work, and a compact but informative prompt. But what else would you put in? What would you leave out?"
Depending on how tech-literate/savy they are this is , i would make a nice little data sheet explaining how to set up their profiles and what the commands do etc ,perhaps make a small perl script that asks a few questions and creates a profile based on the awnsers for those who arn't to up to the task. .(incase things go wrong make a simple script to reset their profile so you can rest easy).
Well if they are neading to get used to shell , then i would say this may be a good approach as it will educate them as well
Just another idea you may consider.
The only things certain in war are Propaganda and Death. You can never be sure which is which though
I'd think anyone who was familar with emacs shortcut keys would already know about the shell..
I would say try to change the shell as little as possible from default, else you are going to confuse them if they have previously done a little command line work, or try to install it at home, or try to learn it from a book / web guide.
I would consider using aliasing to stick a "-i" on rm... nice for beginners (and experts as well to be honest)
Combination - fun iPhone puzzling
It really depends on what sort of users you plan on having on your system. I understand you say that you have computer (read: Windows) literate people, but, I have seen people that I would consider have a decent ability to navigate and use various Windows okay, and just absolutely freak out when they see a CLI.
I'd really recommend a tutorial course given by yourself, or by some other member of IT, to familiarize your users with the CLI. I like my prompt very simple and plain, but informative enough for me, for example, in ZSH, I use: prompt='[%T][%n@%m][%~] ' and that is informative enough for me. If you do something simple like this in the global rc file, and then even personalize it a little more on per user basis.
YOU'RE WINNER !
Another lame blog
I dunno if you can have both at the same time...
alias setprompt 'set prompt="\\
`pwd`\\
`hostname`# "'
alias cd 'chdir \!* && setprompt'
setprompt
Here come da fudge!
the basic emacs commands are rather simple and take no time atall to master. .Just give them a sheet with the commands on like ctrl+f = forward , and they will pick it up quickly enough as the basics are fairly logical .
its not as if they would need to learn the whole emacs multiverse
The only things certain in war are Propaganda and Death. You can never be sure which is which though
Funny, I'd say the same thing about vi commands.....and they're fewer keystrokes.
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
1. Set up the skeleton .bashrc with just a few customizations. For each customization, include a comment so that they will learn how to customize too. For example:
2. Send them an e-mail telling them that they can customize their accounts by editing ~/.bashrc with an easy editor (nano/pico) or whatever. Point them to a nice tutorial on the web, too. Also, tell them that they can reset their settings to the default by typing reset_shell_defaults, and put a script in /usr/local/bin that prompts "Are you sure? Your settings will be lost!" and then overwrites .bashrc. That way, they won't be afraid to play. Nobody ever got 1337 without playing around.
3. Offer up Midinight Commander for those who need some curses.
4. Tell them about man/apropos/info.
are you kidding??? set -o vi goddangit! Gots to start these newbs on the right foot!
most newb are familiar with the idea that .exe means something you can run, and therefore the idea of typing 'README.EXE' to view the howto would not be all that alien to them.
Nonsense. Anyone who associates ".exe" with running a program is a Windows power user, and they will NOT associate "readme.exe" with anything, because readmes are always "readme.txt".
The command to get help in a Windows command prompt is "help", just like in bash, and it works just like bash's. A useful thing to do would be to alias "help" to your own help system that includes information on non-bash commands like ls(1). But your "readme.exe" idea, while clever, would not be at all intuitive to anyone.
Then what is the use of the aliases? The main point is: Constant warnings like that are way too annoying to do any good; people start ignoring them in various ways all too soon, if only mentally.
/* Steinar */
(This comment is of course GPLed.)
No matter what, make it absolutely clear whenever they use something that can bite them hard on a normal terminal. Don't train them to fail later. Aliasing 'rm' to 'rm -i' can hurt them bad when they get used to typing 'rm *' to be prompted for which files to delete.
If you want to get really advanced, include two scripts that will switch them to 'normal' mode or back to 'training' mode.
Start them out in training mode. When they log in, they get:
* an entire screen of help, including the command to leave training mode, and listing the safety nets you added.
* their prompt contains "(TRAINING)" or "(NEWBIE)" or something
* alias 'rm' to 'rm -i', etc.
* any other safety nets
* point out 'grep', 'find', 'head', 'tail', 'less' and the cute little 'wc' and where to discover more about unix commands.
When they switch to normal mode, after confirmation, their login only includes the command to return to training mode. (Which they can edit out of the
The idea is that you make sure that they know which safety nets you create, that aren't on other systems. They also get a transistion period for as long as they want. Leaving the "TRAINING" in the prompt is a continual reminder that there setup is more 'safe' than other systems, and may add motivation to go into normal mode.
The rest of this is from my tcsh experience:
* set up 'complete' options for common, yet complex commands like 'find', 'alias', 'set', 'man', 'nethack'. (very cool in tcsh, is this feature in bash?)
* alias l=ls, ll=ls -l, la=ls -a (doesn't hurt anyone)
* set tab to autocomplete or list matches, if it doesn't already
* include apache-style comments (maximum verbosity) inside the
* set prompt to "(time)
* don't alias any DOS commands directly to Unix except for 'dir'. Alias the others DOS commands to mini-helps that remind them gently to use the proper Unix command.
* use nano
Everyone is entitled to his own opinions, but not his own facts.
I worked doing tech support during my undergrad. The engineering school went and set aliases like you're suggesting, including aliasing 'rm' to 'rm -i'.
So, of course, as the systems I did support for were stock systems, we had the joy of explaining to people why 'rm *' didn't prompt them, just like they were expecting it to, as it did on the engineering school's computers.
Dumbing things down can have the exact opposite effect that was intended, when people think that's the way that the shell always works.
Build it, and they will come^Hplain.
Another thing I do is set ls, ll, and lr aliases and include -aF switches in addition to the -l and -R for the latter two, respectively (I just set ls to what I want and have ll/lr reference my ls alias).
Next, I have a huge command line history--10K lines. It really sucks if I lose my .bash_history file. But I almost can always refer to stuff in history and (almost) never have to write down an obscure command again. But doing this makes working with many windows to a login a challenge. I must use exit or explicitly ^Ding to have my history saved. If I X-out my history is lost. May be a terminal emulator thing--I use tterm w/ ttssh.
My prompt is 2 lines. A bit over kill, but I traverse to lengthy paths and I like to see the complete path. First line is machine + path, second is just my shell name. I really like editing my command line with bash's v command.
That assumes the users are familiar with the DOS command prompt.
First of all, that doesn't describe the usual windows user, even among seemingly tech savy people. (Which, if you'll forgive a brief flame, is no surprise given the crippled and disgusting nature of the DOS shell... why would anyone use it for anything if they had a choice?)
Second, anyone who intuitively reaches for DOS commands will pick up a dozen unix commands in minutes. And, once they know the actual command, they'll instantly have access to man files and online help sources, and they'll be able to easily switch to a different unix machine without confusion. Just try a google search to find out to make the unix command "dir" sort by date. If you ask me, aliasing commands to totally different names is asking for trouble. At best, it will never be noticed by anyone. At worst, one will have a bunch of pissed off users a few weeks down the line.
Someone else in this thread suggested aliasing the dos commands to display help messages instead. That sounds like a very good idea!