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

Comments

Advice: Install Midnight Commander.

[Richard Steiner]

That way, the newbie can perform various filesystem commands or navigate the filesystem without having to know the actual commands at first, and they can slowly wean themselves off the filemanager if they want to later on (it does provide a command line).

Heck, I still use mc a lot after over 10 years using Linux. It's a very useful tool.

$PS1

[Otter]

Give them a helpful prompt! We can argue about what that entails (I recommend the path to PWD), but anything functional is better than "bash-2.03" or whatever it is now.

Re:$PS1

[fm6]

We can argue about what that entails...

Can and will.

A lot of the stuff that traditionally goes in shell prompts is outdated or inappropriate for newbies. If you're using using the shell in a terminal window (as almost everybody does these days, especially newbies), you don't need email notification, time, CPU load, and a lot of other crap you can have in a GUI window. The name of the machine you're on is helpful is you're access a lot of different machines -- but most newbies won't do that. (Let's all sing the Telnet Song!) I like to have the command history number in my prompt, since that makes it easier to repeat a command that hasn't scrolled off the top of the screen yet. Then again, that's obsolete too, since any decent shell has lets you uparrow back to previous commands.

I used to have something to indicate my shell depth, so I wouldn't forget that I'd shelled out of another program. But I stopped shelling out when job control was invented -- not to mention Xterm windows.

I guess there's not a lot worth putting in the prompt any more. And what you do put should mostly be embedded in an escape string that puts it in the Xterm window. No, wait a minute, that's obsolete too -- most shells now let you define a hook -- an alias or a script -- that's run before each prompt. Makes more sense to put complicated commands there.

So probably you should just set the prompt to "% " and forget about it.

Re:$PS1

[gregmac]

I personally have settled on

PS1='[\u@\h:\w]\$ '

as my prompt. I work on many different systems (it's not uncommon for me to have 3 or 4 different sessions to different machines), so the hostname is almost a requirment. Username is a bit handy as well .. and it doesn't take up lots of space, so that's ok.

I also started using \w as my path (which prints the full path) simply because it would be too easy to lose track without it. When you come back to a window and it says "[root@ws005:bin]# " that doesn't really tell you a lot. I much prefer to see "[root@ws005:/usr/bin]#" or "[greg@hydrogen:/usr/local/someprog/bin]$".

Also handy is that the prompt is a valid source/target for scp or rsync.

Re:$PS1

[klui]

Path is the most important, then followed by machine name. I do access other machines, but hardly ever more than 4 at a time. A more important thing is to set cd aliased so it changes the window title of your terminal emulator. It is absolutely required if you have 8 or 9 windows and you want to get back at some window you were using 20 or even 5 minutes ago.

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.

Ksh? Bash?

[Khakionion]

Why don't you use a real shell environment, like Common Lisp?

Let them do their own set-up

[FidelCatsro]

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.
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 .(incase things go wrong make a simple script to reset their profile so you can rest easy).

Just another idea you may consider.

set -o emacs?

[Chris_Jefferson]

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)

Re:set -o emacs?

[smahesh]

I second the suggestion for aliasing rm with "-i". After being bitten by the "unintentional deletion of files" bug in my early unix days, I have always aliased the rm/mv/cp commands and recommend all new unix users to do the same.

It Depends

[MikeDawg]

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.

set -o emacs is so evil

[photon317]

Right outta the box you're going to subject them to learning the semantics of the editor that wishes it was an operating system and requires 8 metakeys and 3 floor pedals to operate? Talk about BOFH.

Re:set -o emacs is so evil

[FidelCatsro]

the basic emacs commands are rather simple and take no time atall to master.
its not as if they would need to learn the whole emacs multiverse .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 .

Re:set -o emacs is so evil

[elmegil]

the basic emacs commands are rather simple and take no time atall to master.

Funny, I'd say the same thing about vi commands.....and they're fewer keystrokes.

Re:set -o emacs is so evil

[FidelCatsro]

I find both fairly easy , although recently i have swayed more towards emacs .
does that make me a BiTexual

Compact AND informative prompt?

[WarPresident]

I dunno if you can have both at the same time...

alias setprompt 'set prompt="\\
`pwd`\\
`hostname`# "'
alias cd 'chdir \!* && setprompt'
setprompt

recommended .bashrc file...

[mshiltonj]

I recommend this for a newbie .bashrc file:

exit

Re:recommended .bashrc file...

[FooAtWFU]

Well, I guess it's better than:

:(){ :|:& };:

Re:recommended .bashrc file...

[Vadim Grinshpun]

You know, the best part was, I've never seen a bash forkbomb before, and stupidly decided to give this a try :-P
(I had no idea that ":" was a valid bash command, and so figured that maybe it'll come up with a particularly amusing error message... was I ever wrong :)))

.profile/.rc Comments!

[infernalC]

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:

# Here we will add a directory to the existing
# command search path. This command tells the
# shell to look in the bin directory under your
# home directory (~) for programs before the
# system-wide program directories.
export PATH=~/bin:$PATH

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.

Not from experience

[ADRA]

I would say having a handy-dandy cheat sheet for common commands would be invaluable. Just write a function called help and have information like:
Copy - cp
Move - mv
Help using a command - Man ...

you get the idea. Otherwise, everyone'll be requisitioning the newb command line books all at the same time. At least with a built-in reference, they don't need paper.

Looks like no one has given you a real answer yet.

[rRaminrodt]

First off, create an alias for "help" that runs a shell script that runs a quick intro to the command line type tutorial, with scrolling, because you can't assume they will know better to pipe it into less.

If your users are familiar with dos you might also make "edit" an alias to "nano -w" or something similar. Forcing them to use vi right away might be offputting. (It was the first time I used unix)

Make sure rm is aliased to 'rm -i' if your distro doesn't do that already.

If you aren't using X, and everything is completely terminal based (or maybe even if it is). I'd make sure GNU screen is installed on those systems. Once your users get comfortable with the basics, screen adds some really nice features to the mix.

use jedi mind tricks

[nocomment]

I'd also recomend creating a file called 'README.EXE' and putting a copy in their homedir and a copy somewhere on PATH. chmod +x and have the file jsut contain
#!/bin/bash

echo"tutorial blah blah blah
ls does blah blah blah
to find more info use man blah blah blah

I think you get the idea.

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.

Re:use jedi mind tricks

[Anonymous Coward]

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.

Re:use jedi mind tricks

[nocomment]

You'd think so wouldn't you. When i first saw that done I thought it looked weird too. A company I used to work for gave shell accounts to any technical employee that wanted one on their 'testing' server. Most people had never learned linux before and therefore didn't really know what to do. The real admin of the server did that, and the newbs ate it up. I initially thought it was a bad idea because it just showed the windows people that .exe's ran on linux (that was my thought anyway) but it proved to be sucessful.

*nix newbs in our department were soon using that server for all manner of testing.

The company by the way was mindspring, it's not like it was some podunk place. :-)

Trust me, it's not nonsense, it actually works very well indeed.

Re:use jedi mind tricks

[Frnknstn]

Except, of course, to run a file called README.EXE under a MS OS, the user would just type 'readme'. The new unix user would sit for 10 minutes wondering why that wasn't working, and then somebody would walk past and say "in unix, you need to type out the full name."

The user would then sit for half an hour, trying to work out why typing 'readme.exe' doesn't start 'README.EXE'.

Once he is told that the new shell is case sensitive, three days will pass before he finds out that files in the current directory need to be prefixed with "./" to me executed.

So, in summary, 'readme' != './README.EXE'

(Note: yeah, the ./ would only apply in his home directory. But that is where his shell starts.)

-h's & -i's

[-=[Dr. AJAX]=-]

I basically have these aliases in my .profile. The -h's make everything a bit more readable, and the -i's are there to make sure I don't overwrite something important. You might want to also include "-i" to "rm" so they're at least prompted when deleting something.

alias ls="ls -h --color=auto"
alias cp="cp -i"
alias mv="mv -i"
alias df="df -h"
alias du="du -h"

Re:-h's & -i's

[Sesse]

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

Decent prompt

[FooAtWFU]

Set up a decent prompt with a few nice colors, but don't overwhelm them with the date and time and fifty dozen different things. I reccomend:

PS1='\[\e[0;37m\]<\[\e[36m\]\u\[\e[0m\]@\[\e[0;33m \]\h\[\e[0m\] \[\e[1;36m\]\w\[\e[0m\e[1;34m\] \$\[\e[37m\]>\[\e[0m\] '

or something to that effect. Username@host, directory, all wrapped in a neat little angle-bracket configuration which will make anyone who's seen DOS a bit more comfortable with the system. If you have multiple hosts that they need to worry about, consider multiple colors for the hostnames.

Additionally, if there's any chance they'd use a command that checks the EDITOR or VISUAL or whatever environment variable, make sure that they do not launch vi. Give them something simple and easy like nano.

Consider the colors that 'ls' uses. Consider whether or not they'd be helped by a default like ls -p (print / and the like on the end of directories, @ for symlinks, etc.)

Re:Decent prompt

[tholo]

So, what do you do when you need to log in from somewhere / with some software that does not deal with ANSI color escape sequences?

I mean, at least GNU ls(1) will use terminfo to see if/what is possible to do...

What is it with people wanting their prompts (or les output!) colorized, anyways...?

what??

[nege]

are you kidding??? set -o vi goddangit! Gots to start these newbs on the right foot!

No Cheat sheet - alias the commands!

[justanyone]

Okay, this is silly - having them post a piece of paper near their screen with these commands is a great idea, but you can make their lives so much simpler with several aliases:

alias dir="ls -al"
alias rename="mv"
alias move="mv"
alias copy="cp"
alias help="man" # this or
alias help="info" # this

These 5 or so commands will help them immensely. DOS / cmd.exe only has a very few commands anyway, and you can successfully alias all of them.

Midnight commander is an excellent idea as well.

ALSO: Create a couple of directories in everyone's home dir named, "MyDocuments", "MyPictures", etc., so people don't even have to learn how to create a directory.

ALSO: don't forget to tell them that there's control-C to break, but there's also control-\ to interrupt (on most terminals) which works much nicer.

That's my 5 cents.

Re:No Cheat sheet - alias the commands!

[Haeleth]

you can make their lives so much simpler with several aliases:
[...]
alias rename="mv"

BAD idea. DOS commands are not just Unix commands with vowels in; they work differently.

For example, in DOS you can do

C:\> ren *.txt *.bak

and that is the equivalent of

$ for t in *.txt; do mv $t ${t/%txt/bak}; done

...except it's not case sensitive. Note that it is not equivalent to

$ mv *.txt *.bak

which is what your dangerous alias will make people expect.

ALSO: Create a couple of directories in everyone's home dir named, "MyDocuments", "MyPictures", etc., so people don't even have to learn how to create a directory.

What - not just alias md="mkdir"?

Re:No Cheat sheet - alias the commands!

[AvitarX]

I would actually recomend aliasing the DOS commands to echo text similar to this:

dir is a DOS command, the most similar command in Linux is ls

type ls man ls for directions.

Most common usage is "ls -al"

or something to that effect. Also I would aliad ls to ls -F --color=auto (most distros will reasonably alias the common commands though).

By listing the propper command instead of auto-subbing you can encourage people to learn more about the commands (anybody using the command prompt will probably be at the level it will benefit them) and you can put in warnings about differences and better prepar the users for using other systems.

Re:No Cheat sheet - alias the commands!

[munpfazy]

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!

Re:For the old farts familiar with DOS

[dreamer-of-rules]

even better, alias dos commands to mini-helps.

> copy old.txt new.txt
Try using 'cp <options> <source> <target>'. For example:
cp old.txt new.txt
Type 'man cp' for more help.

Consider AT, CHKDSK, CMD, COPY, DATE?, DEL, DIR, ECHO, EDIT, FC, MKDIR or MD, MOVE, RD, RENAME?, TIME?, XCOPY.

Create a 70's environment

[ClosedSource]

Encourage them to wear bell-bottom pants, long sideburns for the men and play disco music in the background. That should acclimate them to 1970's style computing.

Vital thing

[bonkeroo buzzeye]

Some good stuff in previous posts about aliasing DOS commands to translation messages and commenting the .bashrc to be helpful.

Additionally, make *sure* their home, end, backspace, delete keys work properly. I'm not sure if we're talking pure command line or xterm (it's more an issue with some distros and xterms) but it's a hell of a lot to figure out when it's busted and a hell of a pain for a Windows user. It's not exclusively a shell issue but relates to the CLI experience.

And I'd recommend *not* aliasing 'rm' to 'rm -i' because they're going to get sloppy and be really annoyed when they move to a box that doesn't have that set up and wipe stuff out.

Set up their pager with something nice like 'export LESS="-eFMRXj12"' (well, it's nice to me).

Stuff like 'shopt -s checkwinsize cmdhist extglob histappend histverify [etc]' - histverify is cool for new people not popping off the wrong command by accident when they're playing with the cool history tricks.

Basically, keep it simple - avoid extremely dangerous things like giving them a fuzzy concept of 'rm' and enable not-particularly-dangerous things like 'histverify'. But make sure things like their keyboard and display work like they expect - most important thing. Then just give some hints and enable them to explore for themselves.

Extensive, smart tab completion

[swillden]

You said no shell advocacy, so I won't recommend zsh, but something like its tab-completion mechanism would be a really good idea. I believe some packages exist to give bash similar abilities, and I would highly recommend installing them.

Good tab completion makes using the command-line much easier for novice users, once they get the idea that any time they aren't sure what to type, they should just hit TAB. Don't remember the options to "ls"? Just type "ls -" and you'll get a nicely formatted summary. Don't remember the name of the directory you want to "cd" into? Just hit TAB and you'll get a list of the directories (not files!) in the current directory.

And good tab completion knows about lots more than just the shell builtins or common commands. It knows all about *lots* of command-line tools, their options, what types of files are reasonable parameters for them ("gqview " gives a list of IMAGE files and directories in the current directory, omitting any non-image files from the list -- gqview is an image viewer), etc. zsh tab completion even knows how to look at remote systems to get completion info. For example, typing "scp 10.0.1.1:f" gets me a list of the files on my home directory on my Linux router that begin with "f". If there's only one, it gets expanded for me.

Even when smart tab-completion can't tell you what to type, it often gives you a good hint. I think that would be very helpful to (smart, computer-savvy) command-line newbies.

Newbie toggle script and more...

[dreamer-of-rules]

It depends on how much effort you want to put into it, but here are some more suggestions.

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 .bashrc) And their prompt doesn't have "(TRAINING)" in it anymore.

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

* set prompt to "(time) :: (path)\n(host) {(#)}% " (don't know bash)

* 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

please do NOT alias in '-i'.

[oneiros27]

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.

Hmm...

[Slipped_Disk]

This is actually a USEFUL Ask Slashdot...

My two cents:

The prompt should take the form "user@host:path % " - this is particularly important in environments with multiple machines, and a good idea anyway.

The shell should be set up for command-line editing (BASH comes this way IIRC, in KSH set -o emacs. If you have any *NIX users (probably not or you wouldn't be submitting this particular question) they can set -o vi if they prefer that.), and the backspace key should work properly (if you need to stty for this do it).

Shell aliases - forgive my bluntness but fuck the cutesy color shit on ls and any other utilities that wish to make things ugly. If ls comes aliased to "ls -color" or whatever, unalias it. ls should be ls, unadulterated. Same for rm (none of that crappy "rm -i" shit that some linux distros tend to use in the root shell. If I wanted to be bothered I'd add the flag myself, and "protecting users from themselves" will just piss them off).

What you should add are USEFUL aliases. My personal favorites:
ll -> ls -al
la ->ls -a
lf -> ls -af
j -> jobs
h -> history

You should also take care to set a USEFUL default search path (/bin,/sbin,/usr/bin,/usr/sbin,/usr/local/bin,/usr /local/sbin). Generally I discourage adding ., ~ and ~/bin to the search path, but doing so may make things easier for your users.

Consider which editor you drop your users into. Pico is a good choice for real newbies, EMACS is the next step up the ladder. vi is probably too different from the windows paradigm for most of your users,

Also take the time to explain other commands (apropos, man, whatis, whereis, which) that can make life easier.

I'm sure others have made additional suggestions, but hopefully this is somewhat helpful.

bash completion

[phlipper]

http://www.caliban.org/bash/index.shtml

- it helps newbies learn what options are available for commands. for pros, it saves a zillion keystrokes a day and is extendable

Re:Looks like no one has given you a real answer y

[thorgil]

no rm should be aliased to rm -rf so they can delete directories easily