Dell provides very good service through it's support site http://support.dell.com/.
My laptop video driver got screwed up, for that just I need to visit this support site, click on "Drivers & downloads", then provide your laptop service tag, which lists already installed drivers, from there we can download required drivers.
Monday, June 29, 2009
Premature end of script headers
This error comes when we execute a Perl/Php/python script from apache http webserver. This is a common error which get reported for many problems.
The actual error reported in apache log file is
Use of uninitialized value in concatenation (.) or string at HAT.pm line 887.
Use of uninitialized value in string eq at HAT.pm line 888.
[Mon Jun 29 04:07:36 2009] [error] (2)No such file or directory: exec of /var/www/main/CEandPorting/internal/hotfix/automation/cgi-bin/hat_branches.cgi failed
[Mon Jun 29 04:07:36 2009] [error] [client 128.222.51.107] Premature end of script headers: /var/www/main/CEandPorting/internal/hotfix/automation/cgi-bin/hat_branches.cgi
This error got resolved for me after changing the cgi script from Windows format to Unix format (using notepad++)
The actual error reported in apache log file is
Use of uninitialized value in concatenation (.) or string at HAT.pm line 887.
Use of uninitialized value in string eq at HAT.pm line 888.
[Mon Jun 29 04:07:36 2009] [error] (2)No such file or directory: exec of /var/www/main/CEandPorting/internal/hotfix/automation/cgi-bin/hat_branches.cgi failed
[Mon Jun 29 04:07:36 2009] [error] [client 128.222.51.107] Premature end of script headers: /var/www/main/CEandPorting/internal/hotfix/automation/cgi-bin/hat_branches.cgi
This error got resolved for me after changing the cgi script from Windows format to Unix format (using notepad++)
Tuesday, June 23, 2009
CVS commands for novices
1) Building your repository
export CVSROOT=/home/siddesh/cvs-repo
mkdir -p $CVSROOT
cvs init or (cvs -d $CVSROOT init)
# Above command is to set up your chosen directory as a CVS repository. Setting up the repository produces a place to store projects and also adds the special CVSROOT directory. The CVSROOT directory contains configuration and metadata files. Projects are stored in subdirectories of the repository root directory, which is /home/siddesh/cvs-repoin our example.
2) Importing Projects
#Create your initial project directory structure, possibly in /tmp. Once the project is stored in CVS, this initial version can be removed.
mkdir ~/cvs-home #Create a temporary project directory
create ~/cvs-home/lilprogram/source.c #create temp file
#Once you have your initial structure, add any initial files you want. Change into the root directory of the project. Then, from within that directory, import the project with the command:
cd ~/cvs_home/lilprogram
cvs import -m "Test" lilprogram loci lilprogram_0_0
(or cvs -d repository_path import name_of_project vendor_tag release_tag)
Example 2: Importing a project
/tmp$ mkdir example
/tmp$ touch example/file1
/tmp$ touch example/file2
/tmp$ cd example
/tmp/example$ cvs -d /var/lib/cvsroot import example example_project ver_0-1
#In the repository, the imported project is stored as a collection of RCS files.
ls -l /home/siddesh/cvs_repo/
total 8
drwxrwxr-x 3 siddesh siddesh 4096 Feb 9 18:55 CVSROOT
drwxrwxr-x 3 siddesh siddesh 4096 Feb 9 19:03 lilprogram
ls -l /home/siddesh/cvs_repo/lilprogram/
total 8
drwxrwxr-x 2 siddesh siddesh 4096 Feb 9 18:53 Attic
-r--r--r-- 1 siddesh siddesh 1060 Feb 9 18:49 source.c,v
3) Accessing Remote Repositories
There are several ways to access a remote repository. One among them is ext method with the SSH protocol. The ext and SSH approach uses the ext repository access method, with an SSH client as the program that performs the connection.
Your first step,is to install SSH on the client machine. Make sure that the client-end SSH protocol matches the server's SSH protocol. Set up SSH keys or passwords and test the connection. Using SSH enables you to create a secure connection to the remote repository.
Next, if you're on a Unix or Linux system, set the CVS_RSH environment variable on your client machine to the name of your SSH program, usually ssh or ssh2.
On a remote machine, the repository path takes the form:
[:method:][[[user][:password]@]hostname[:[port]]]/path
Ex: :ext:cvs:/home/cvs
where "ext" is the method and "cvs" is the hostname.
4) Checkout
#CVS stores projects and files in a central repository, but you work from a working copy, called a sandbox , in your local directories. You create that sandbox with cvs checkout.
mkdir ~/cvs_home/client1
cd !$
cvs checkout lilprogram or (cvs -d repository_path checkout project_name)
Example 2:
$mkdir ~/cvs
$cd ~/cvs
$cvs -d /var/lib/cvsroot checkout example
cvs checkout: Updating example
U example/file1
U example/file2
#The checkout command puts a copy of the project's files and subdirectories into a directory named for the project, created in the current working directory. It also puts some administrative files of its own in a subdirectory of the project directory, called CVS.
#You can check out an individual file or subdirectory of a project by replacing project_name with the pathname to the file or directory, from the project's root directory. CVS stores the repository path as part of the sandbox, so you should never again need to use -d repository_path in commands executed within that sandbox.
Example 3: Remote repository checkout
cvs -d :ext:cvs:/home/cvs checkout cvsbook
5) Commit & Update
#Once you've checked out project files into a sandbox, you can edit those files with your preferred editor. Changes are not synchronized with the repository until you run the cvs commit command. This command is best run from the root directory of your sandbox, and it must be run from within the sandbox.
vi source.c -> make changes
cvs update
cvs commit source.c (give description)
#If a revision in the repository is more recent than the revision the sandbox was based on, cvs commit fails. Use the cvs update command to merge the changed files; then run cvs commit again.
Ex: cvs update -d
#As a command option to the update command, -d downloads new directories and files.
#As the update command runs, it generates a list of files that are modified. To the immediate left of each filename, you will see a single uppercase letter. Those letters report the status of each file listed, and they have the following meanings:
U filename
Updated successfully. A newer version in the repository has replaced your sandbox version.
A filename
Marked for addition but not yet added to the repository (need to run a cvs commit).
R filename
Marked for removal but not yet removed from the repository (need to run a cvs commit).
M filename
Modified in your working directory. The file in the sandbox is more recent than the repository version or the sandbox and the repository both had changes that the system could safely merge into your sandbox copy (need to run a cvs commit).
C filename
There was a conflict between the repository copy and your copy. The conflict requires human intervention.
? filename
The file is in your working directory but not in the repository. CVS doesn't know what to do with it.
The A, R, and M codes mean that your sandbox contains changes that are not in the repository and it would be a good idea to run a cvs commit.
If CVS can't merge a modified file successfully with the copy in the repository, it announces the conflict in the output of cvs update.
CVS automatically merges files when the changes are on different lines. If a line in the repository copy is different from the corresponding line in the sandbox copy, CVS reports a conflict and creates a file with the two revisions of the line surrounded by special marks, as shown below
<<<<<<
= = = = = = =
This line came from the repository..
>>>>>>> 1.4
The contents of the original file are stored in .#file.revision in the file's working directory, and the results of the merge are stored as the original filename. Search for these marks in the file with the original name, edit the file, then commit the changed file to the repository.
6) Adding Files
To add a file to a project in the repository, first create the file in your sandbox. Be sure to consider your project's structure and place the file in the correct directory. Then, issue the following command from the sandbox directory containing the file:
cvs add filename
cvs add header.h; cvs commit
This command marks the new file for inclusion in the repository. Directories are added with the same command. Files within a directory can't be added until the directory itself is added. A file is only marked for addition when you run cvs add ; it is actually added to the repository when the next cvs commit is run. A directory is added to the repository immediately.
7) Removing Files
To remove a file from the repository, first remove the file from the sandbox directory; then run the following command from the sandbox directory that contained the file:
cvs remove filename
rm header.h; cvs remove header.h; cvs commit
The deletion does not take effect until the next cvs commit command is run; the file remains in the repository until then.
After thecvs commit is run, CVS doesn't remove the file entirely; it puts it in a special subdirectory in the repository called Attic . This saves the file history and enables the file to be returned to the repository later.
Use the -P flag to cvs checkout and cvs update to avoid empty directories in your sandbox.
8)Branching
cvs rtag -b lilprogram_0_1 lilprogram
cvs update -r lilprogram_0_1
cvs status source.c
9)Reverting to main branch
cvs update -A
cvs status source,c
10) Tag as label
edit source.c; cvs commit
cvs tag liltagl_01_0
cvs update -r lilprogram_0_1; cat source.c
11) Merging branches
edit source.c(in -0-1 branch); cvs commit source.c
cvs update -A; cvs update -j lilprogram_0_1; cvs commit source.c
14) export
cvs export -r lilprogram_0_1 lilprogram
15) annotate
cvs annotate source.c
export CVSROOT=/home/siddesh/cvs-repo
mkdir -p $CVSROOT
cvs init or (cvs -d $CVSROOT init)
# Above command is to set up your chosen directory as a CVS repository. Setting up the repository produces a place to store projects and also adds the special CVSROOT directory. The CVSROOT directory contains configuration and metadata files. Projects are stored in subdirectories of the repository root directory, which is /home/siddesh/cvs-repoin our example.
2) Importing Projects
#Create your initial project directory structure, possibly in /tmp. Once the project is stored in CVS, this initial version can be removed.
mkdir ~/cvs-home #Create a temporary project directory
create ~/cvs-home/lilprogram/source.c #create temp file
#Once you have your initial structure, add any initial files you want. Change into the root directory of the project. Then, from within that directory, import the project with the command:
cd ~/cvs_home/lilprogram
cvs import -m "Test" lilprogram loci lilprogram_0_0
(or cvs -d repository_path import name_of_project vendor_tag release_tag)
Example 2: Importing a project
/tmp$ mkdir example
/tmp$ touch example/file1
/tmp$ touch example/file2
/tmp$ cd example
/tmp/example$ cvs -d /var/lib/cvsroot import example example_project ver_0-1
#In the repository, the imported project is stored as a collection of RCS files.
ls -l /home/siddesh/cvs_repo/
total 8
drwxrwxr-x 3 siddesh siddesh 4096 Feb 9 18:55 CVSROOT
drwxrwxr-x 3 siddesh siddesh 4096 Feb 9 19:03 lilprogram
ls -l /home/siddesh/cvs_repo/lilprogram/
total 8
drwxrwxr-x 2 siddesh siddesh 4096 Feb 9 18:53 Attic
-r--r--r-- 1 siddesh siddesh 1060 Feb 9 18:49 source.c,v
3) Accessing Remote Repositories
There are several ways to access a remote repository. One among them is ext method with the SSH protocol. The ext and SSH approach uses the ext repository access method, with an SSH client as the program that performs the connection.
Your first step,is to install SSH on the client machine. Make sure that the client-end SSH protocol matches the server's SSH protocol. Set up SSH keys or passwords and test the connection. Using SSH enables you to create a secure connection to the remote repository.
Next, if you're on a Unix or Linux system, set the CVS_RSH environment variable on your client machine to the name of your SSH program, usually ssh or ssh2.
On a remote machine, the repository path takes the form:
[:method:][[[user][:password]@]hostname[:[port]]]/path
Ex: :ext:cvs:/home/cvs
where "ext" is the method and "cvs" is the hostname.
4) Checkout
#CVS stores projects and files in a central repository, but you work from a working copy, called a sandbox , in your local directories. You create that sandbox with cvs checkout.
mkdir ~/cvs_home/client1
cd !$
cvs checkout lilprogram or (cvs -d repository_path checkout project_name)
Example 2:
$mkdir ~/cvs
$cd ~/cvs
$cvs -d /var/lib/cvsroot checkout example
cvs checkout: Updating example
U example/file1
U example/file2
#The checkout command puts a copy of the project's files and subdirectories into a directory named for the project, created in the current working directory. It also puts some administrative files of its own in a subdirectory of the project directory, called CVS.
#You can check out an individual file or subdirectory of a project by replacing project_name with the pathname to the file or directory, from the project's root directory. CVS stores the repository path as part of the sandbox, so you should never again need to use -d repository_path in commands executed within that sandbox.
Example 3: Remote repository checkout
cvs -d :ext:cvs:/home/cvs checkout cvsbook
5) Commit & Update
#Once you've checked out project files into a sandbox, you can edit those files with your preferred editor. Changes are not synchronized with the repository until you run the cvs commit command. This command is best run from the root directory of your sandbox, and it must be run from within the sandbox.
vi source.c -> make changes
cvs update
cvs commit source.c (give description)
#If a revision in the repository is more recent than the revision the sandbox was based on, cvs commit fails. Use the cvs update command to merge the changed files; then run cvs commit again.
Ex: cvs update -d
#As a command option to the update command, -d downloads new directories and files.
#As the update command runs, it generates a list of files that are modified. To the immediate left of each filename, you will see a single uppercase letter. Those letters report the status of each file listed, and they have the following meanings:
U filename
Updated successfully. A newer version in the repository has replaced your sandbox version.
A filename
Marked for addition but not yet added to the repository (need to run a cvs commit).
R filename
Marked for removal but not yet removed from the repository (need to run a cvs commit).
M filename
Modified in your working directory. The file in the sandbox is more recent than the repository version or the sandbox and the repository both had changes that the system could safely merge into your sandbox copy (need to run a cvs commit).
C filename
There was a conflict between the repository copy and your copy. The conflict requires human intervention.
? filename
The file is in your working directory but not in the repository. CVS doesn't know what to do with it.
The A, R, and M codes mean that your sandbox contains changes that are not in the repository and it would be a good idea to run a cvs commit.
If CVS can't merge a modified file successfully with the copy in the repository, it announces the conflict in the output of cvs update.
CVS automatically merges files when the changes are on different lines. If a line in the repository copy is different from the corresponding line in the sandbox copy, CVS reports a conflict and creates a file with the two revisions of the line surrounded by special marks, as shown below
<<<<<<
= = = = = = =
This line came from the repository..
>>>>>>> 1.4
The contents of the original file are stored in .#file.revision in the file's working directory, and the results of the merge are stored as the original filename. Search for these marks in the file with the original name, edit the file, then commit the changed file to the repository.
6) Adding Files
To add a file to a project in the repository, first create the file in your sandbox. Be sure to consider your project's structure and place the file in the correct directory. Then, issue the following command from the sandbox directory containing the file:
cvs add filename
cvs add header.h; cvs commit
This command marks the new file for inclusion in the repository. Directories are added with the same command. Files within a directory can't be added until the directory itself is added. A file is only marked for addition when you run cvs add ; it is actually added to the repository when the next cvs commit is run. A directory is added to the repository immediately.
7) Removing Files
To remove a file from the repository, first remove the file from the sandbox directory; then run the following command from the sandbox directory that contained the file:
cvs remove filename
rm header.h; cvs remove header.h; cvs commit
The deletion does not take effect until the next cvs commit command is run; the file remains in the repository until then.
After thecvs commit is run, CVS doesn't remove the file entirely; it puts it in a special subdirectory in the repository called Attic . This saves the file history and enables the file to be returned to the repository later.
Use the -P flag to cvs checkout and cvs update to avoid empty directories in your sandbox.
8)Branching
cvs rtag -b lilprogram_0_1 lilprogram
cvs update -r lilprogram_0_1
cvs status source.c
9)Reverting to main branch
cvs update -A
cvs status source,c
10) Tag as label
edit source.c; cvs commit
cvs tag liltagl_01_0
cvs update -r lilprogram_0_1; cat source.c
11) Merging branches
edit source.c(in -0-1 branch); cvs commit source.c
cvs update -A; cvs update -j lilprogram_0_1; cvs commit source.c
14) export
cvs export -r lilprogram_0_1 lilprogram
15) annotate
cvs annotate source.c
Friday, June 19, 2009
How to configure apache2.2 .x and php5.x?
As a newbie to PHP, I was trying to run a simple php file which I wrote on web browser. But it was displaying the php script contents instead of executing it. Then I found the need to configure php interpreter to Apache. Here is the link which explains very well about configuring apache & php
http://www.thesitewizard.com/php/install-php-5-apache-windows.shtml
In simple, we need to copy php.ini-recommended file as php.ini inside php directory and after that modify httpd.conf file as described in link and then restart Apache.
http://www.thesitewizard.com/php/install-php-5-apache-windows.shtml
In simple, we need to copy php.ini-recommended file as php.ini inside php directory and after that modify httpd.conf file as described in link and then restart Apache.
Monday, June 1, 2009
How to set a login timeout for a perforce user?
Perforce supports two methods of authentication: password-based and ticket-based.
How password-based authentication works?
Password-based authentication is stateless; once a password is correctly set, access is granted for indefinite time periods.
How ticket-based authentication works
Ticket-based authentication is based on time-limited tickets that enable users to connect to Perforce servers. Tickets are stored in the file specified by the P4TICKETS environment variable. If this variable is not set, tickets are stored in %USERPROFILE%\p4tickets.txt on Windows, and in $HOME/.p4tickets on UNIX and other operating systems. Tickets are managed automatically by 2004.2 and later Perforce client programs.
Tickets have a finite lifespan, after which they cease to be valid. By default, tickets are valid for 12 hours (43200 seconds). To set different ticket lifespans for groups of users, edit the Timeout: field in the p4 group form for each group. The timeout value for a user in multiple groups is the largest timeout value (including unlimited, but ignoring unset) for all groups of which a user is a member. To create a ticket that does not expire, set the Timeout: field to unlimited.
Although tickets are not passwords, Perforce servers accept valid tickets wherever users can specify Perforce passwords. This behavior provides the security advantages of ticket-based authentication with the ease of scripting afforded by password authentication.
Logging in to Perforce
To use ticket-based authentication, get a ticket by logging in with the p4 login command:
p4 login
You are prompted for your password, and a ticket is created for you in your ticket file. You can extend your ticket's lifespan by calling p4 login while already logged in. If you run p4 login while logged in, your ticket's lifespan is extended by 1/3 of its initial timeout setting, subject to a maximum of your initial timeout setting.
By default, Perforce tickets are valid for your IP address only. If you have a shared home directory that is used on more than one machine, you can log in to Perforce from both machines by using the command:
p4 login -a
to create a ticket in your home directory that is valid from all IP addresses.
Determining ticket status
To see if your current ticket (that is, for your IP address, user name, and P4PORT setting) is still valid, use the command:
p4 login -s
If your ticket is valid, the length of time for which it will remain valid is displayed.
To display all tickets you currently have, use the command:
p4 tickets
The contents of your ticket file are displayed.
Refer P4 Sys admin Guide for details
How password-based authentication works?
Password-based authentication is stateless; once a password is correctly set, access is granted for indefinite time periods.
How ticket-based authentication works
Ticket-based authentication is based on time-limited tickets that enable users to connect to Perforce servers. Tickets are stored in the file specified by the P4TICKETS environment variable. If this variable is not set, tickets are stored in %USERPROFILE%\p4tickets.txt on Windows, and in $HOME/.p4tickets on UNIX and other operating systems. Tickets are managed automatically by 2004.2 and later Perforce client programs.
Tickets have a finite lifespan, after which they cease to be valid. By default, tickets are valid for 12 hours (43200 seconds). To set different ticket lifespans for groups of users, edit the Timeout: field in the p4 group form for each group. The timeout value for a user in multiple groups is the largest timeout value (including unlimited, but ignoring unset) for all groups of which a user is a member. To create a ticket that does not expire, set the Timeout: field to unlimited.
Although tickets are not passwords, Perforce servers accept valid tickets wherever users can specify Perforce passwords. This behavior provides the security advantages of ticket-based authentication with the ease of scripting afforded by password authentication.
Logging in to Perforce
To use ticket-based authentication, get a ticket by logging in with the p4 login command:
p4 login
You are prompted for your password, and a ticket is created for you in your ticket file. You can extend your ticket's lifespan by calling p4 login while already logged in. If you run p4 login while logged in, your ticket's lifespan is extended by 1/3 of its initial timeout setting, subject to a maximum of your initial timeout setting.
By default, Perforce tickets are valid for your IP address only. If you have a shared home directory that is used on more than one machine, you can log in to Perforce from both machines by using the command:
p4 login -a
to create a ticket in your home directory that is valid from all IP addresses.
Determining ticket status
To see if your current ticket (that is, for your IP address, user name, and P4PORT setting) is still valid, use the command:
p4 login -s
If your ticket is valid, the length of time for which it will remain valid is displayed.
To display all tickets you currently have, use the command:
p4 tickets
The contents of your ticket file are displayed.
Refer P4 Sys admin Guide for details
Subscribe to:
Posts (Atom)