Add files to SVN recursively via command line

Submitted by abhishek on Wed, 09/15/2010 - 14:33

Search files in subdirectories and add them to SVN recursively
svn status | grep "^\?" | awk '{print $2}' | xargs svn add

original link: http://abhishek.nagar.me/blogs/add-files-svn-recursively-command-line

Ubuntu change the root password of MySQL

Set / change / reset the MySQL root password on Ubuntu Linux. Enter the following lines in your terminal.

1. Stop the MySQL Server.
   

   sudo /etc/init.d/mysql stop



2. Start the mysqld configuration.
   

   sudo mysqld --skip-grant-tables &



3. Login to MySQL as root.
   

   mysql -u root mysql



4. Replace YOURNEWPASSWORD with your new password!
   

   UPDATE user SET Password=PASSWORD('YOURNEWPASSWORD') WHERE User='root'; FLUSH PRIVILEGES; exit;

Note: This method is not regarded as the securest way of resetting the password. However it works.

original link: http://ubuntu.flowconsult.at/en/mysql-set-change-reset-root-password/

create a script that can be executed at boot in Ubuntu.

Step 1 – Create your script.
Simply create a new file (I called mine svnserve) and type the command you’d like to run
cd /etc/init.d/ # (thanks Alfonso)
sudo touch svnserve
sudo vi svnserve
svnserve -d -r /usr/local/svn/repository_name
Step 2 – Save the script in the /etc/init.d/ folder
Step 3 – Make the script executable
sudo chmod +x svnserve
Step 4 – Add the script to the boot sequence
sudo update-rc.d svnserve defaults
That’s it. When you’re done you should see some output similar to
Adding system startup for /etc/init.d/svnserve ...
/etc/rc0.d/K20svnserve -> ../init.d/svnserve
/etc/rc1.d/K20svnserve -> ../init.d/svnserve
/etc/rc6.d/K20svnserve -> ../init.d/svnserve
/etc/rc2.d/S20svnserve -> ../init.d/svnserve
/etc/rc3.d/S20svnserve -> ../init.d/svnserve
/etc/rc4.d/S20svnserve -> ../init.d/svnserve
/etc/rc5.d/S20svnserve -> ../init.d/svnserve

Configure SVN Ubuntu

1: Create a repo:

    $ svnadmin create /media/datadrive/svn/test

2: Set the password:

    $ sudo gedit /media/datadrive/svn/passwd-team

    And then, add the user information into the file, as follows:

[users] 
michal = somepassword 
jimmy = anotherpassword 
craig = yetanotherpassword

Since the password is not encrypted, so use the following command so that only the root can read.

    $ sudo chmod 600 /media/datadrive/svn/passwd-team

3: configure:
Each SVN repo has a scnserve.conf file, which is created automatically when you execute step 1. Using the following command to edit this file for configuration.

    $ gedit /media/datadrive/svn/test/conf/svnserve.conf

Find the following lines, and specify the password:

[general] 
anon-access = none 
password-db = /media/datadrive/svn/passwd-team 
realm = Team

4: Start the svn:
foreground

    $ sudo svnserve -d --foreground -r /media/datadrive/svn/

or background:

    $ sudo svnserve -d -r /media/datadrive/svn/

5: Start svn client using another machine:

    svn checkout svn://192.168.10.01(put the IP addr. here)/test --username jimmy

Ubuntu: Configure SVN Server

Prerequisites

It is assumed that you already have a basic Ubuntu server running, and that the other developers can connect to it. If you want to allow them to access the Subversion server with the secure svn+ssh protocol, then each developer must also be able to login to your machine with SSH.

Basic Subversion Setup

Begin by installing the Subversion package:

$ sudo apt-get install subversion

You're going to need a directory for your repositories, as well as other Subversion-related files. Most people use /home/svn or /usr/local/svn for this purpose, and you can choose either. I personally prefer /usr/local/svn over /home/svn, as I like to keep /home for home directories of real users of the system.

$ sudo mkdir /usr/local/svn

Inside this directory, create another one to hold your repositories:

$ sudo mkdir /usr/local/svn/repos

Now, you need to set some access permissions on those directories. You only want to allow certain users of your system (that is, yourself and the other developers) to access the repositories, so add a new group for those users. Name the group svn.

$ sudo groupadd svn

Then, change the group ownership of /usr/local/svn/repos to the new group using the chgrp command:

$ sudo chgrp svn /usr/local/svn/repos

The members of the svn group also need write access to the repos directory, so use chmod to add the write permission for the group:

$ sudo chmod g+w /usr/local/svn/repos

Additionally, you need to make sure that all new files and directories created in the repos directory (in other words, anything committed to the repositories) will also be owned by the group. To accomplish this, use chmod again to set the set-group-ID bit on the directory, which causes any file created inside it to have the same group ownership as the directory itself. Effectively, everything in repos will belong to the svn group.

$ sudo chmod g+s /usr/local/svn/repos

OK, so you now have the repositories directory with proper permissions, ready to be used by the svn group. Go ahead and add yourself to the group:

$ sudo usermod -a -G svn michal

However, your new group membership will not be effective for the current session, so you need to log out and log back in. When you're back, you can verify that your account is recognized as a member of the svn group:

$ groups michal adm dialout cdrom plugdev lpadmin admin sambashare svn

If the other developers have user accounts on your server, add them to the group too:

$ sudo usermod -a -G svn jimmy $ sudo usermod -a -G svn craig

If they don't, they will still be able to access the repositories, but only using the basic svn protocol, not the secure svn+ssh method.

Creating a Test Repository

You can now create a repository. In the following steps, I'll demonstrate how to create a simple test repository containing one text file, and how to check out and commit files. If you're not familiar with Subversion, then this could be a good exercise to learn the basics. Otherwise, you can skip all the test checkouts and commits and just create the repository for your project.
The repository will be a subdirectory in the repos directory, and will have its group ownership set to svn (thanks to the chmod g+s you did earlier). However, that's not all – you also need to make sure the repository will be group writable, so that the other members of the svn group will be able to commit files. To do this, set the umask to 002:

$ umask 002

This command sets the new file mode creation mask which controls the default permissions of any new file that you create. The default value is 022 and it corresponds to read/write permissions for the file owner, and read permissions for the group and others. The new value, 002, also gives write permissions to the group, which is just what you need.
Create the repository using the svnadmin command:

$ svnadmin create /usr/local/svn/repos/test

And set back the default umask:

$ umask 022

So you now have an empty repository, waiting for you to commit something to it. But, before you do this, you need to check out the current version (i.e., the empty directory) to create a working copy.

$ svn checkout file:///usr/local/svn/repos/test Checked out revision 0.

The working copy has been checked out to a new directory named test. Go ahead and create a simple "hello world" text file in that directory:

$ cd test $ echo 'Hello, World!' > hello.txt

Then, add it to version control with the svn add command:

$ svn add hello.txt A         hello.txt

Finally, commit it using svn commit:

$ svn commit -m "Added a 'hello world' text file." 

Adding         hello.txt Transmitting file data . 

Committed revision 1.

The hello.txt file is now in the repository.

Accessing the Repository with the Svn Protocol

Remote repository access with the svn protocol requires you to use svnserve, a Subversion server program. Each repository has a svnserve configuration file (stored in the conf subdirectory) which controls how the repository can be accessed with svnserve.
First, create a passwords file that lists the users of the repository and their passwords. This will be a common passwords file for your development team and you will be able to use it with multiple repositories.

$ sudo gedit /usr/local/svn/passwd-team

Here's a sample passwords file. Each line (except the first one, which is the configuration section name) defines a user name and the corresponding password.

[users] michal = somepassword jimmy = anotherpassword craig = yetanotherpassword

Since the passwords are stored unencrypted, it's important that you protect the passwords file by setting the proper permissions. The file should not be readable by anyone except the owner (which is root), so change its mode to 600:

$ sudo chmod 600 /usr/local/svn/passwd-team

Then, open the svnserve configuration file in the test repository:

$ gedit /usr/local/svn/repos/test/conf/svnserve.conf

There's probably some default configuration in the file, but you can just remove everything and enter this:

[general] anon-access = none password-db = /usr/local/svn/passwd-team realm = Team

The anon-access = none line denies access to the repository to unauthenticated users (by default, they are allowed read access, so they can do checkouts). The password-db setting tells svnserve where to look for the passwords file when authenticating users, and the realm setting defines the name of the authentication realm.
OK, the configuration is ready, so you can now launch svnserve.

$ sudo svnserve -d --foreground -r /usr/local/svn/repos

The command-line options tell svnserve to run in daemon mode (-d) as a foreground process (--foreground), and to look for repositories in the repos dir that was created earlier (-r /usr/local/svn/repos). Normally the program should be running in the background (that's what daemon processes do), but at this moment you only need to test it, so it's more convenient to run it in the foreground, where you can easily kill it with Ctrl+C.

Now, try accessing the repository using the svn protocol. You can try it on another machine over the network, or on the same computer (in another terminal). In the latter case, make sure you're not doing the checkout in the same directory where the previous test working copy was checked out, because it won't work – either delete the test directory, or cd to some other location.

Enter the following svn checkout command, replacing 192.168.10.11 with the IP address of your Subversion server (if you're testing on the same machine, you can use 127.0.0.1):

$ svn checkout svn://192.168.10.11/test --username jimmy

The server will ask you for password:

Authentication realm: <svn://192.168.10.11:3690> Team Password for 'jimmy':

Then, it proceeds with the checkout.

A    test/hello.txt Checked out revision 1.

And there's your working copy. Now, check if it works the other way – try modifying the file and committing it back to the repository. Open hello.txt with a text editor and add some text:

$ cd test $ gedit hello.txt

When you're done, commit it:

$ svn commit -m "Modified the hello.txt file." Sending        hello.txt Transmitting file data . Committed revision 2.

Sweet, it works both ways.

Accessing the Repository with the Svn+SSH Protocol

Setting up your Subversion server for svn+ssh access is simple, as it doesn't even require using the svnserve program. Assuming you have a SSH server running on the Subversion machine, and the other developers can login to it, you don't have to configure anything – just set up the repository.
You can just go ahead and check out the test project. The checkout operation is slightly different with the svn+ssh access method. First, you must specify the full path to the repository in the checkout URL:

$ svn checkout svn+ssh://192.168.10.11/usr/local/svn/repos/test --username jimmy

Then, when the server asks you for a password, you need to enter the user's SSH password, not the one from the passwd-team file.

jimmy@192.168.10.11's password:

And there it goes:

A test/hello.txt Checked out revision 2.

From here, you can use your working copy the same way as with the svn protocol.

Svnserve Initialization Script

If you plan on using svnserve in the long run, you probably don't want to start it from the command-line every time the server is rebooted. The proper way to start system services is with init scripts located in the /etc/init.d directory.
The Subversion package for Ubuntu does not include an init script, so you have to make one yourself. Or, you can download this init script, written by yours truly. Save the script as /etc/init.d/svnserve and make it executable:

$ sudo chmod +x /etc/init.d/svnserve

If you chose anything other than /usr/local/svn/repos for the repositories directory, make sure to change the path in the init script.
Run update-rc.d to install the script:

$ sudo update-rc.d svnserve defaults Adding system startup for /etc/init.d/svnserve ... /etc/rc0.d/K20svnserve -> ../init.d/svnserve /etc/rc1.d/K20svnserve -> ../init.d/svnserve /etc/rc6.d/K20svnserve -> ../init.d/svnserve /etc/rc2.d/S20svnserve -> ../init.d/svnserve /etc/rc3.d/S20svnserve -> ../init.d/svnserve /etc/rc4.d/S20svnserve -> ../init.d/svnserve /etc/rc5.d/S20svnserve -> ../init.d/svnserve

And that's it – svnserve will be started automatically when your system boots up. To start it manually, run this command:

$ sudo /etc/init.d/svnserve start

References

• Version Control with Subversion This is the official Subversion book, written by the people who developed the version control system. The complete text of the book is available online, and one of the chapters is fully devoted to server configuration.
  
• Subversion - Community Ubuntu Documentation A guide on setting up a Subversion server on Ubuntu, published as part of the Ubuntu Community Documentation. It covers some of the tasks presented in this tutorial, and provides instructions on how to configure other methods of repository access (e.g., HTTP).
  

original link: http://odyniec.net/articles/ubuntu-subversion-server/

Stop svnserver in Ubuntu

On my flavour of Linux this would work:


   ps auxww | fgrep svnserve


Then the number in the second column is the process id, then I can do:


   kill <process id> (without the <> brackets)


and in the worst case (e.g. svnserve won't stop after many minutes):


   kill -9 <process id>

Auto-mount the second hard drive in Ubuntu

1: create a mount point:

  mkdir /media/datadrive 
    create a mount point "datadrive" in /media

2: Change the rights of this directory:

  sudo chmod g+w /media/datadrive
  sudo chmod +t /media/datadrive

    The last "chmod +t" adds the sticky bit, so that people can only delete their own files and sub-directories in a directory, even if they have write permissions to it (see man chmod).
3: Edit the /etc/fstab file:

  sudo gedit /etc/fstab

The first column,Ubuntu recommend the UUID instead of logical name. To check the UUID of hard drive and partition, use the following command:

  sudo blkid

wcg1sgh@/mnt$sudo blkid
[sudo] password for wcg1sgh:
/dev/sda1: UUID="8b7a0996-d499-4722-b691-87dde9c0dd37" TYPE="ext4"
/dev/sda5: UUID="2aee8aab-8543-4476-9f43-bde31ab5ee49" TYPE="swap"
/dev/sdb2: LABEL="DATADRIVE" UUID="17b2b066-a817-4f9c-9330-cdd94b7a4191" TYPE="ext4"

    Then, add the following line into /etc/fstab:

    # the second hard drive /dev/sdb
    UUID=17b2b066-a817-4f9c-9330-cdd94b7a4191 /media/datadrive    ext4    defaults    0    2

The detailed explanation of /etc/fstab can be found in [2].

3: run the following command or reboot the computer to have the changes take effect.

  sudo mount -a

4: Then, you can use the second hard drive.

wcg1sgh@/media/datadrive$cd /media/
wcg1sgh@/media$ls
datadrive
wcg1sgh@/media$cd datadrive/
wcg1sgh@/media/datadrive$ls
lost+found  svn

Now, we have to directories in the second hard drive:
1: lost+found
2: svn

references:  
[1] https://help.ubuntu.com/community/InstallingANewHardDrive
[2] http://web.archive.org/web/20130413052717/http://www.tuxfiles.org/linuxhelp/fstab.html 

Ubuntu User Management

Root Users

• If for some reason you wish to enable the root account, simply give it a password:
  
  

  sudo passwd 

  Sudo will prompt you for your password, and then ask you to supply a new password for root as shown below:
  
  

  [sudo] password for username: (enter your own password)
  Enter new UNIX password: (enter a new password for root)
  Retype new UNIX password: (repeat new password for root)
  passwd: password updated successfully 

• To disable the root account, use the following passwd syntax:
  
  

  sudo passwd -l root 

• You should read more on Sudo by checking out it's man page:
  
  

  man sudo
  

Adding and Deleting Users

• To add a user account, use the following syntax, and follow the prompts to give the account a password and identifiable characteristics such as a full name, phone number, etc.
  
  

  sudo adduser username 

• To delete a user account and its primary group, use the following syntax:
  
  

  sudo deluser username
  

• To temporarily lock or unlock a user account, use the following syntax, respectively:
  
  

  sudo passwd -l username
  sudo passwd -u username 

• To add or delete a personalized group, use the following syntax, respectively:
  
  

  sudo addgroup groupname
  sudo delgroup groupname 

• To add a user to a group, use the following syntax:
  
  

  sudo adduser username groupname

TBD

Upload file to remote server using SCP

chenwang@~/Downloads$scp BuildingCocoaApps.pdf wcg1sgh@sgh023118:/home/wcg1sgh/Desktop/
Ubuntu 12.04.4 LTS
wcg1sgh@sgh023118's password:
BuildingCocoaApps.pdf                         100%  653KB 652.9KB/s   00:00

chenwang@~/Downloads$

Vim: basic usage

1: set line number:

:set number or :set nu

2: search:

/key_words

N: next
P: previous

/opt and /usr/local

/usr/local: System software/commands,  for example, the software installed from directly by running installation package.

/opt: Other software (based on my understanding, it can be some open source software). When you have an application installed in /opt directory, you will have:
/opt/<appname>/bin
/opt/<appname>/lib
/opt/<appname>/share/man

conf files in /etc/opt/<appname>/ and logs in /var/opt/<appname>/

If an Ubuntu machine become responseless

If the ubuntu machine locks up completely, you can REISUB it, which is a safer alternative to just cold rebooting the computer.
REISUB by:
While holding Alt and the SysReq (Print Screen) keys, type REISUB.

R:  Switch to XLATE mode
E:  Send Terminate signal to all processes except for init
I:  Send Kill signal to all processes except for init
S:  Sync all mounted file-systems
U:  Remount file-systems as read-only
B:  Reboot

REISUB is BUSIER backwards, as in "The System is busier than it should be", if you need to remember it. Or mnemonically - R eboot; Even; If; System; Utterly; Broken.

Environment variables

First of all, we have different places to setup environment variable. All the following files are applicable to both Ubuntu and Mac OS:

• ~/.profile:
  use this for variables you want to set in all programs launched from the terminal (note that, unlike on Linux, all shells opened in Terminal.app are login shells).
  
• ~/.bashrc:
  this is invoked for shells which are not login shells. Use this for aliases and other things which need to be redefined in subshells, not for environment variables that are inherited.
  

• /etc/profile:
  this is loaded before ~/.profile, but is otherwise equivalent. Use it when you want the variable to apply to terminal programs launched by all users on the machine (assuming they use bash).
  

Ubuntu System

/etc/profile.d/:
All the script in this directory will be automatically executed. For more details, you can check the file /etc/profile

vim /etc/profile

then, you will see:

if [ -d /etc/profile.d ]; then
  for i in /etc/profile.d/*.sh; do
    if [ -r $i ]; then
      . $i
    fi
  done
  unset i
fi


Mac OS X

• ~/.MacOSX/environment.plist: this is read by login window on login. It applies to all applications, including GUI ones, except those launched by Spotlight in 10.5 (not 10.6). It requires you to logout and login again for changes to take effect. This file is no longer supported as of OS X 10.8. 
• your user's launchd instance: this applies to all programs launched by the user, GUI and CLI (command line interface). You can apply changes at any time by using the setenv command in launchctl. In theory, you should be able to put setenv commands in ~/.launchd.conf, and launchd would read them automatically when the user logs in, but in practice support for this file was never implemented. Instead, you can use another mechanism to execute a script at login, and have that script call launchctl to set up the launchd environment.
• /etc/launchd.conf: this is read by launchd when the system starts up and when a user logs in. They affect every single process on the system, because launchd is the root process. To apply changes to the running root launchd you can pipe the commands into sudo launchctl.

a

Set the colour in terminal of Mac OS X

set the colour for normal users.
1: Go to the home directory, and create the following file:

    vim .bash_profile

2: Insert the following content into the file:

    export TERM="xterm-color"

    PS1='\[\e[00;32m\]\u\[\e[0m\]@\[\e[00;32m\]\w\[\e[0m\]\$'

The definition of each colour can be referred to the previous article.

3: save the file. Make it validated.

    source .bash_profile
-------------------------------------
set the colour for root.
1: login as a root.

    sudo -i

and then, enter the password.

2: create the following file:

    vim .profile

3: Enter the following content into the file (can be the same as normal users):

    export TERM="xterm-color"

    PS1='\[\e[00;31m\]\u\[\e[0m\]@\[\e[00;31m\]\w\[\e[0m\]\$'

4: save the file and make it validated immediately.

    source .profile
-------------------------------------

THEN, THE WORLD BECOMES COLOURFUL! :-)

Determine 32bit or 64bit of your mac OS

1

Launch Terminal app (see Applications/Utilities)

2

At prompt, type the following: "uname -a" (without the quotes) (note the blank space between "uname" and "-a" strings.

3

The terminal will display two lines of text. At the end of the 2nd line, you'll find something like either

• RELEASE_I386 i386 ; the latest "i386" means that you're running 32bits kernel
• RELEASE_X86_64 x86_64 ; the latest "x86_64" means that you're running 64bits kernel

Original Link: http://www.wikihow.com/Determine-if-You're-running-the-32-Bit-or-64-Bit-Kernel-in-Mac-oSX

Change the Command-Line Prompt Colour in the Ubuntu/Linux Terminal

How to Change the Command-Line Prompt Colour in the Ubuntu/Linux Terminal

July 11, 2011 by Ubuntu Genius

The terminal for running commands in Ubuntu and any other Linux distro is dull to look at, but you can easily spice it up a little with some colour.

Simply run the following command in a terminal:
gedit ~/.bashrc
When .bashrc opens, locate and uncomment “force_color_prompt=yes” (that is, remove the hash, so it no longer looks like: #force_color_prompt=yes).
Save the file, and open a new terminal window, and you should already see a change (the prompt should be Light Green, which is defined by 1;32). You can then change any colour value you like; eg: 0;35 = Purple.
To edit the colour values, locate the following section, and change the default values with some of the examples listed further down:
if [ "$color_prompt" = yes ]; then
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;31m\]\w\[\033[00m\]\$ '
else
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
You can check out this Bash colour chart for a full range of colour values, but here are a few basic ones you can play around with (note that “Light” isn’t what you might think – it actually means “bold”):
Black 0;30 – Dark Gray 1;30 – Blue 0;34 – Light Blue 1;34 – Green 0;32 – Light Green 1;32 – Cyan 0;36 – Light Cyan 1;36 – Red 0;31 – Light Red 1;31 – Purple 0;35 – Light Purple 1;35 – Brown 0;33 – Yellow 1;33 – Light Gray 0;37 – White 1;37
For those curious about the codes used in the example pic, here’s the line from that section:
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;35m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
As you can see, 1;35 is the Light Purple user and machine name, while the 1;34 is the Light Blue tilde (~). If you want yours a bit brighter, try:
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;36m\]\u@\h\[\033[00m\]:\[\033[01;31m\]\w\[\033[00m\]\$ '
… which will give you Light Cyan and Light Red, and look like the following:

In case you’re wondering about the colon and dollar sign, you can change those as well, but you need to do more than just edit the colour values. You’ll need to insert code in the appropriate places, so the line looks like this:
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;36m\]\u@\h\[\033[01;33m\]:\[\033[01;31m\]\w\[\033[01;33m\]\$ '
You’ll notice the first highlighted code is just before the colon (:) while the second is before the dollar sign ($). In this example, both are yellow, with the result looking like:

Now, if you want to go even further, you can make the user name stand out by doing the following:
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;36m\]\u\[\033[01;35m\]@\h\[\033[01;33m\]:\[\033[01;31m\]\w\[\033[01;33m\]\$ '
That extra bit of code is specifying Light Purple for the @ and the desktop name, making it now look like:

And of course, one last bit of fiddling and you can have every element a different colour. In this last example, we’re going to make the computer name the same as the user name, and have them broken up by red, as with the yellow elements:
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;36m\]\u\[\033[01;31m\]@\[\033[01;36m\]\h\[\033[01;33m\]:\[\033[01;31m\]\w\[\033[01;33m\]\$ '
As you can see, the @ is now Light Red, while the code before \h is specifying Light Cyan, like the user name:

You’ll also notice when you type commands that the colour of the text will match that of the $, which can be preferable if using a “light” colour, since the bold text is easier to see.
Lastly, in case you’re wondering whether the prompt can end in anything other than a $, the answer is yes, and it’s as easy as opening the Character Map (sudo apt-get install gucharmap if you don’t have it), selecting a character, and pasting it over the $ at the end of the line of code:
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;36m\]\u\[\033[01;31m\]@\[\033[01;36m\]\h\[\033[01;33m\]:\[\033[01;31m\]\w\[\033[01;33m\]ᛤ '
In that example, I simply selected a cool looking character from the font Runic, and replaced the $ with that. You’ll also note one other thing you’ll have to do, and that’s remove the \ before it, or else that will appear too (obviously, that doesn’t happen if using the $, but will with other characters).

Have fun experimenting!

Original Link: http://ubuntugenius.wordpress.com/2011/07/11/how-to-change-the-command-line-prompt-colour-in-the-ubuntulinux-terminal/

and

http://www.arwin.net/tech/bash.php

Enable remote desktop for Ubuntu for multiple users

1: install xrdp

    sudo apt-get install xrdp

2: if now, you use remote desktop connector, you can only see a blank desktop. So a few more steps are needed:

    sudo vim /etc/xrdp/startwm.sh 

And then, add the following line in front of ". /etc/X11/Xsession":

    echo "gnome-session --session=ubuntu-2d" > .xsession





So, the file now looks like:

    #!/bin/sh

    if [ -r /etc/default/locale ]; then
      . /etc/default/locale
      export LANG LANGUAGE
    fi

    echo "gnome-session --session=ubuntu-2d" > .xsession

    . /etc/X11/Xsession




3: Start the xrdp


    /etc/init.d/xrdp start

Other useful commands:

    /etc/init.d/xrdp restart
    /etc/init.d/xrdp stop

4: start the remote desktop connector, and enter the IP address of the Ubuntu machine, then follow the instructions.