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

18 of 159 comments (clear)

  1. Advice: Install Midnight Commander. by Richard+Steiner · · Score: 4, Informative

    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.

    --
    Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
    The Theorem Theorem: If If, Then Then.
  2. $PS1 by Otter · · Score: 3, Informative

    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.

    1. Re:$PS1 by gregmac · · Score: 4, Informative

      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.

      --
      Speak before you think
  3. Not from experience by ADRA · · Score: 2, Informative

    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.

    --
    Bye!
  4. Looks like no one has given you a real answer yet. by rRaminrodt · · Score: 3, Informative

    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.

    --
    They'll think I've lost control again and leave it all to evolution. -- Supreme Being, Time Bandits
  5. -h's & -i's by -=[Dr.+AJAX]=- · · Score: 2, Informative
    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"
  6. Decent prompt by FooAtWFU · · Score: 3, Informative
    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.)

    --
    The World Wide Web is dying. Soon, we shall have only the Internet.
    1. Re:Decent prompt by tholo · · Score: 2, Informative

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

      --
      Universe, n.: The Problem.
  7. No Cheat sheet - alias the commands! by justanyone · · Score: 2, Informative

    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.

    1. Re:No Cheat sheet - alias the commands! by Haeleth · · Score: 5, Informative
      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"?
  8. Vital thing by bonkeroo+buzzeye · · Score: 3, Informative

    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.

  9. Extensive, smart tab completion by swillden · · Score: 2, Informative

    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.

    --
    Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  10. Re:set -o emacs? by smahesh · · Score: 2, Informative

    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.

  11. Re:recommended .bashrc file... by Vadim+Grinshpun · · Score: 2, Informative

    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 :)))

  12. Stop right there! by Anonymous Coward · · Score: 1, Informative
    I'm thinking about stuff like 'stty erase ^H'

    Please... no...

    Some jackass did this in our unified root configs at work and pushed them out to all our boxes. Now everytime I su - on any of them I have to unfuck my terminal.

    BACKSPACE DOES NOT PRODUCE ^H ON ALL TERMINALS!

    http://www.squish.net/docs/delbs.html

    If the termcap/terminfo entries for your TERM on your system match what your terminal actually produces, this is unnecessary and will just piss people off who have a terminal that behaves differently.

  13. Hmm... by Slipped_Disk · · Score: 2, Informative

    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.

    --
    /~mikeg
  14. bash completion by phlipper · · Score: 2, Informative

    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

  15. Re:use jedi mind tricks by Frnknstn · · Score: 2, Informative

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

    --
    If it's in you sig, it's in your post.