How to Create a Table in Oracle/Sql Server 2005 / TeraData

Create Table in Oracle

create table Department
(department_number Smallint,
department_name char(30) not null,
budget_amount decimal(10,2),
manager_employee_number integer);

Create Table in TeraData

create table Employee, Fallback
(employee_number integer,
manager_employee_number integer,
department_number integer,
job_code integer,
last_name char(20) not null,
first_name varchar(30) not null,
hire_date Date not null,
birthdate Date not null,
salary_amount Decimal(10,2) not null)
Unique Primary Index (employee_number);

SQL Server 2005

create table Department
(department_number Smallint,
department_name char(30) not null,
budget_amount decimal(10,2),
manager_employee_number integer);

Final Semister Project How to Test a Software

035-TEST PLAN-
SOFTWARE TESTING FOR APS ZAMZAMA
V1.0

Summary…………………………………………………………………………………………………
4
Background….…………………………………………………………………………………………
5
Project Scope…………………………………………………………………………………………
5
Test Plan Objectives/ Deliverables ………………………………………………………
5
Features to be Tested…………………………………………………………………………..
6
Test Strategy………………………………………………………………………………………..
6
System Functionality Test……………………………………………….
6
Security Test……………………………………………………………………
6
Documentation Test………………………………………………………..
6
Regression Test……………………………………………………………….
7
User Acceptance Test……………………………………………………..
7
Test Pass/Fail Criteria…………………………………………………………………………..
7
Suspension/ Resumption Criteria………………………………………………………….
7
Defect Reporting…………………………………………………………………………………….
7
Test Deliverables /Test Deliverables…………………………………………………….
8
Resources and Responsibilities……………………………………………………………..
8
Resources……………………………………………………………………………..
8
Responsibilities……………………………………………………………………..
8
Security Clearance…………………………………………………………………………………..
9
Risks…………………………………………………………………………………………………………
9
Management…………………………………………………………………………………………..
9
Personnel…………………………………………………………………………………………………..
9
Requirements………………………………………………………………………………………….
9
Documentation………......................................................................
9


Document Name
Prepared / Reviewed by
Review Summary
Date
035- Test Plan Document for School Management System Project
Ahmed Zeb
Document Created
12-28-2007


SUMMARY
This document covers the Test Plan for the APS Zamzama testing Project. Documents that are referenced for the preparation of this test plan involve:
· Requirement Document – APS Zamzama.doc
BACKGROUND
The main disadvantage in the manual work was that, there was no sharing of information between different activities of the departments. This created a lot of problem for the employees of the school. To perform work manually, it wasted a lot of time of the school’s employee. It took a lot of time to storage and retrieve records. As the system was totally dependent on the human labor, so it needed number of employee to do any task. Due to manual work there was chance for the employee to tired or became ill and they to make mistake.
PROJECT SCOPE
School Management System was designed to cater for the growing need of automation of processes and ease of use. The application aims to provide better and automated accounting, admission, examination and employee modules.
TEST PLAN OBJECTIVES / DELIVERABLES
This Test Plan for the School Management System will comprise of the following Objectives / Deliverables:
1. Define the activities required to prepare, execute, and report the White Box (Unit, Module, Integration, System) and Black Box (Usability, Functional, Regression and User Acceptance Testing).
2. Communicate the Test Strategy to all responsible parties.
3. Communicate the various Dependencies and Risks to all responsible parties.



FEATURES TO BE TESTED
Following is the list of features of the School Management System Project that are to be tested:

The Examination section will keep all the records of all students including mid term, final term, Assignments, weekly tests Marks.
The passing marks are 5o %. They calculate all mid term, Final term, Assignments, weekly tests Marks and which student took 50 % he will be promoted to next Class, while there will be no Final Exam of Class 9th actually the 9th and 10th Classes subjects are same so they take only one (1) Exam of Both Classes.
The Examination Section also to keep the record of,
Warning
This is the warning form of the school. Warning which is given by the principle to the students if we click on search button a frame will open & give following search options
Student no
Student name
Subject id
Subject Name
All Record
The fields of this form are,
Adm_ no (FK), Warning _no (PK), Class_ no (FK), Section _no (FK), Subject _no (FK), Date, Principle remarks.

COUNCIL FORM
The APS make a council of Intelligent and brilliant Students and the head of the council is a teacher the council members go to the week Students that why they cannot study are there any home problem or due to any other reason they can not study.
The council members also teach the week Students Free of Cost.
Observation
The observation also to keep all the records of all the students and they directly contact with Students Parents.
This is the main form of the Zamzama Public School Nowshera.This form is used for the admission process of the student. It contains the basic information about students.
In the registration field we give the registration no & the rest of the information displayed on the form.
This is admission search form. In this form we can search the record of the student by the following search option & the record of the students will be displayed in the grid.
By Student Name
By Admission No
By Gender
By Section
By Class
By Father Name
When the user is going to search the record of the student if the user write e.g. a or b or any other alphabet the whole list of the student will be open in the grid whose name is starting from a or b or any other alphabet, or when he write full name of the student only that student data will be come to the grid whose name is written by the user.
The account section will maintain all the accounts of the school. It has two major components.
· Fee Structure
The Fee Structure of the account section will show the structure of the student, which they have paid or have to be paid when he/she admitted in the School.
· Monthly Fee



The fields of this form are,
Serial _no, Admission _no (FK), Registration fee, Library fee, Computer fee, Science fee, Sports fee, Book fee, Examination fee, Security fee, Annual fee, Category, Relatives, Month, total.
The user only fill the above fields the computer will automatically calculate all the fields.



MONTHLY FEES FORM
Serial _no (FK), Admission _no (FK), Class _no (FK), Library fee, Computer fee, Science fee, Sports fee, Book fee, Examination fee, Security fee, Annual fee, Category, Relatives, Month, Late fee fine, Absentee fine, Tuition fee, Total.
The user only fill the above fields the computer will automatically calculate all the fields



SUBJECT INFORMATION FORM
This is the subject information form of the School, that which subject is Teaching by which Teacher to which Class and also store the Subject Edition & the record is saved by subject no.
If we click on search button a frame will open which give following search options:

Student no
Student name
Subject id
Subject Name
All Record
By selecting one search option the record will be displayed on flex grid.
NOTE:
The subject no must be ‘integer’.The fields of this form are’
Subject _no, Subject name, Sub edition, Class _no (FK), Teacher.
TEACHER’S OBSERVATION FORM
This form is used for teacher’s observation about students. The teachers checks the record of the student & give his remarks about the students.
When a Teacher enter admission no the admission no will only accept ‘integer’ not any other character or any thing else & the record will display.
If we want to delete a record from database we can only delete record by class no, not on any other field.
The fields of this form are,
Adm_ no (FK), Observation _no (PK), Class_ no (FK), Section _no (FK), Class teacher, First remarks, Date, Second remarks, Date.






TEST STRATEGY
The test strategy consists of a series of different tests that will fully exercise the School Management System Project requirements. The primary purpose of this testing is to uncover the system limitations and measure its full capabilities as per the modifications performed. The initial testing will be carried out on the QA Server. A list of the various planned tests and a brief explanation follows below:
1. Unit testing:
Unit testing will focus on the testing of a single unit of code. Unit testing will help verify the integrity of a single unit. It will make sure that a single unit performs its designated task and is fulfilling the requirements ( or sharing the load to fulfill it).
2. Integration Testing:
Integration testing will focus on the integration of two modules and their impact on the overall system. Tests will be performed to determine the compatibility of two modules with each other and with the system.
3. Module Testing:
Module testing will be carried to determine functionality of a single module. Efforts will be made to test all possible paths.

4. System Functionality Test
The System Functionality Test will focus on the behavior of the School Management System Project users as per the requirements. User scenarios will be executed against the system to find the defects in the modified functionality.
Overall, the system tests will verify whether it meets the functionality defined in the Requirements Documents.
5. Security Test
The Security Tests will determine the accessibility of Internal Users to the “School Management Software”. Everyone should not be allowed to use the software. The concerned person should only view reports.
6. Documentation Test
Tests will be conducted to check the accuracy of the documentation provided to the QA Team till the completion of the project. These tests will ensure that no feature is missing, or needed data set unavailable, and the School Management System Project can easily be understood.

7. Regression Test
The testing cycle will be repeated if the fixes are made to the defects found. Regression Test is done in order to check if maybe any error has been introduced due to the Changes / Fixes done.

8. User Acceptance Test (Optional)
Once the School Management System Project is ready for implementation / deployment, end users will perform User Acceptance Testing (UAT). The purpose of this testing is to confirm that the system is developed according to the specified user requirements and is ready for operational.

TEST PASS / FAIL CRITERIA
Following functionalities will determine the Test Pass/Fail Criteria of School Management System Project .
· All the intended requirements for the School Management System Project are working fine.
SUSPENSION/RESUMPTION CRITERIA
If any defects are found which may seriously impact the testing progress, the QA Manager may choose to suspend testing. Criteria that will justify test suspension are:
1. As per described in the documentation, the intended functionalities of School Management System Project are not working properly
If testing is suspended, resumption will only occur when the problem(s) that caused the suspension has been resolved. When a critical defect is the cause of the suspension, the QA Department must verify the “FIX” before testing is resumed.

DEFECT REPORTING
No formal defect report will be documented during the testing cycle. When defect(s) are found, the QA Analysts will notify all issues to the development team at Mantis (En Pointe Bug Tracker). In case of ambiguity, discussions will be carried out between the concerned teams. The development team will then resolve the reported defect(s). Once the resolution is prepared, a notification is sent to all assigned team members of development; mentioning the defect(s) which are resolved. The QA Department then will resume testing and will verify the issue as ‘Open’ or ‘Closed’. Once all defect(s) are resolved and verified by QA,
The QA / EDI Team Lead will give the final Sign Off for moving subsequent build(s) into production.



TEST DELIVERABLES
Following are the test deliverables of School Management System Project:
1. Test Plan Document
2. Develop Test Cases
3. Testing Methodologies
4. Execute tests
5. Defect Report


RESOURCES AND RESPONSIBILITIES
The QA Team will determine when system tests will start and end. They will also be responsible for coordinating schedules & equipment for the personal involved in testing as well as writing / updating the Test Plan, and other documents.
1. Resources
The Project team consists of:
1. Project Manager ------------ Ahmed Zeb
2. Snr. Supervisor QA ------------ Ahmed Zeb
3. Project Lead Developer ------------ Ahmed Zeb
4. QA Analysts ------------ Ahmed Zeb


2. Responsibilities
Project Manager
Responsible for Project schedules and the overall success of the project.
Snr. Supervisor QA
Ensures the overall success of the Test Cycles. He will determine when system tests will start and end and also be responsible for coordinating schedules & equipment for the personal involved in testing as well as writing / updating the Test Plan, and other documents.

Project Lead Developer
Serve as a primary contact between the development department and the project team.
QA Analyst
Responsible for documenting, executing the test cases and defect reporting. Will coordinate and communicate the testing status to the project team.
User
Will assist in performing Beta and User Acceptance testing.

SECURITY CLEARANCE
All the information related to the School Management System of users should be provided to the QA Team (Testing team).
RISKS
1. Management
Management support is needed to insure testing is an event based process guided by milestones not by predetermined time frames. Management can reduce the risk of delays by ensuring dedicated testing personal, test equipment, and simulated system environments are available as requested.

2. Personnel
Dedicated staff is needed in order to promptly execute the test scenarios. If we have attrition of any type either external or internal we will experience delays in the project. All efforts to minimize attrition should be realized by all levels of management.
3. Requirements
The test plan and test schedule are based on the current available Documentation. Any changes to the requirements could affect the test schedule and will need to be approved by the Project Team.

DOCUMENTATION
The following documentation will be available at the end of the test phase:
1. Test Plan
2. Test Cases
3. Bug Reports

TEST CASES

Test Case Id
1
Test Date
12/28/2007
Test Point

Pre-Requisite
NA
Use Case Name
1.1
Test Engineer
Ahmed Zeb
Description
Login into System
Test Case Type
Functional
Steps Performed
1. Go to Desktop.
2. Open the Application
3. Give the correct username and correct password.
Expected Output
User should be allowed to enter into the system.
Result (Pass/Fail)
PASS
Observations/
Suggestions for Improvement


Regards,
Ahmed Zeb
Q.A Analyst - Quality Assurance Department
Ph: 0334-5088530

Test Case Id
2
Test Date
12/28/2007
Test Point
Admission section form
Pre-Requisite
1
Use Case Name
2.1
Test Engineer
Ahmed Zeb
Description
Login into System
Test Case Type
Functional
Steps Performed
1. Go to Desktop.
2. Open the Application
3. Click Admission section.
4. Click the Add button on top.
Expected Output
All the fields (name, last name etc) should get blank except for student id field.
Result (Pass/Fail)
PASS
Observations/
Suggestions for Improvement


Test Case Id
3
Test Date
12/28/2007
Test Point
Admission section form
Pre-Requisite
2
Use Case Name
2.2
Test Engineer
Ahmed Zeb
Description
Save button again after filling the values in fields
Test Case Type
Functional
Steps Performed
Go to Desktop.
2. Open the Application
3. Click Admission section.
4. Click the Add button on top.
5. Click the Add Button again after filling the values in the form.
Expected Output
Message box should be displayed “Please save the exisisting values”.
Result (Pass/Fail)
PASS
Observations/
Suggestions for Improvement


Test Case Id
3.1
Test Date
12/28/2007
Test Point
Admission section form
Pre-Requisite
2
Use Case Name
2.3
Test Engineer
Ahmed Zeb
Description
Next Button
Test Case Type
Functional
Steps Performed
Go to Desktop.
2. Open the Application
3. Click Admission section.
4. Click the Next button on top.
5.When the user continuously clicking next button and reach last record and then click next button again.
Expected Output
Message box should be displayed “This is Last Record ”.
Result (Pass/Fail)
PASS
Observations/
Suggestions for Improvement



Test Case Id
3.2
Test Date
12/28/2007
Test Point
Admission section form
Pre-Requisite
2
Use Case Name
2.4
Test Engineer
Ahmed Zeb
Description
First Button
Test Case Type
Functional
Steps Performed
Go to Desktop.
2. Open the Application
3. Click Admission section.
4. Click the First button on top.
5.Click the First Button to check the First record if the user again click the First button.
Expected Output
Message box should be displayed “This is The First Record ”.
Result (Pass/Fail)
PASS
Observations/
Suggestions for Improvement





Test Case Id
3.3
Test Date
12/28/2007
Test Point
Admission section form
Pre-Requisite
2
Use Case Name
2.4
Test Engineer
Ahmed Zeb
Description
Last Button
Test Case Type
Functional
Steps Performed
1.Go to Desktop.
2. Open the Application
3. Click Admission section.
4. Click the Last button on top.
5. Click the Last Button to check the Last record if the user again Click the Last Button.
Expected Output
Message box should be displayed “This is Last Record ”.
Result (Pass/Fail)
PASS
Observations/
Suggestions for Improvement









Test Case Id
4
Test Date
12/28/2007
Test Point
Examination section form
Pre-Requisite
2
Use Case Name
4.1
Test Engineer
Ahmed Zeb
Description
Previous Button
Test Case Type
Functional
Steps Performed
1.Go to Desktop.
2. Open the Application
3. Click Examination section.
4. Click the Previous button on top.
5. When the user continuously clicking Previous button and when reach first record and when again click Previous button.
Expected Output
Message box should be displayed “This is The First Record ”.
Result (Pass/Fail)
PASS
Observations/
Suggestions for Improvement





Test Case Id
4
Test Date
12/28/2007
Test Point
Examination section form
Pre-Requisite
2
Use Case Name
4.2
Test Engineer
Ahmed Zeb
Description
Update Button
Test Case Type
Functional
Steps Performed
1.Go to Desktop.
2. Open the Application
3. Click Examination section.
4. Click the Update Button on top.
Expected Output
Message box should be displayed “Do you want to Update the Record” and when user click on “yes” Button then he is allow to Update the Record and when user click on “Save” Button to save the record Message box should be displayed “The record which you Update is Saved Successfully ”.
Result (Pass/Fail)
PASS
Observations/
Suggestions for Improvement






Test Case Id
4
Test Date
12/28/2007
Test Point
Examination section form
Pre-Requisite
2
Use Case Name
4.3
Test Engineer
Ahmed Zeb
Description
Reports Button
Test Case Type
Functional
Steps Performed
1.Go to Desktop.
2. Open the Application
3. Click Examination section.
4. Click the Reports Button on top.
Expected Output
This Button is used when user to see the report of the student and want to make a hard copy of it.
Result (Pass/Fail)
PASS
Observations/
Suggestions for Improvement



Test Case Id
5
Test Date
12/28/2007
Test Point
Examination section form
Pre-Requisite
2
Use Case Name
5.1
Test Engineer
Ahmed Zeb
Description
Exit Button
Test Case Type
Functional
Steps Performed
1.Go to Desktop.
2. Open the Application
3. Click Examination section.
4. Click the Exit Button on top.
Expected Output
This Button is used when user want to Exit from the Existing Form.0…….
Result (Pass/Fail)
PASS
Observations/
Suggestions for Improvement



Test Case Id
6
Test Date
12/28/2007
Test Point
Employees section form
Pre-Requisite
2
Use Case Name
5.1
Test Engineer
Ahmed Zeb
Description
Exit Button
Test Case Type
Functional
Steps Performed
1.Go to Desktop.
2. Open the Application
3. Click Employees section.
4. Click the Search Button on top.
Expected Output
This Button is used when user want to search the record of any employee.

Result (Pass/Fail)
PASS
Observations/
Suggestions for Improvement

Assignement 1 (SRS)

Software Requirement Specification (SRS)
Table of Contents
1. Introduction----------------------------------------------------2
1.1 Purpose----------------------------------------------------
1.2 Scope----------------------------------------------------
1.3 Definitions----------------------------------------------------
1.4 References----------------------------------------------------
1.5 Overview----------------------------------------------------

2. Overall Requirements----------------------------------------------------
2.1 Product Perspective----------------------------------------------------
2.1.1 Hardware Interfaces. ----------------------------------------------------
2.1.2 Software Interfaces. ----------------------------------------------------
2.1.3 Communication Interfaces. ----------------------------------------------------
2.1.4 Memory Constraints. ----------------------------------------------------
2.2 User Characteristics----------------------------------------------------
2.3 Design Constraints----------------------------------------------------
2.4 Functional Requirements----------------------------------------------------
2.4.1 Non- Functional Requirements----------------------------------------------------

3. Software system attributes
3.1 Reliability------------------------------------------------------------------------------
3.2 Security--------------------------------------------------------------------------------
3.3 Availability----------------------------------------------------------------------------
3.4 Maintibilty-----------------------------------------------------------------------------
3.5 Scalability----------------------------------------------------------------------------
4. Other requirements--------------------------------------------------------------------
4.1 Assumptions--------------------------------------------------------------------------
4.2 Future Requirements. -------------------------------------------------------------







Introduction:

1.1 Purpose
The purpose of this SRS document is to completely define and explain each and every requirement/intended functionality and their inter-dependencies. The documents will help project stakeholders, users, suppliers able to understand the intended functionality of our APS Zamzama software The users and stake holders related to this project are:


Principal
Admission Clerk
Accountant Clerk
Examination Controller.


Scope:
The scope of the project (APS Zamzama software) is to automate the Admission, Examination, Accounts and Employee departments. This will include automation of all manual tasks such as student fee records, file keeping, report generation, maintaining the student progress through out the year regarding different assignments, quizzes and examinations. The benefit of automating these departments will help reduce error rate and improve performance by improving response time. The application will also help reducing time-consuming jobs. The will in turn improve the efficiency of the school management and the school itself. Management can spend more time planning and executing other managerial tasks.




Definitions:

YOU WILL WRITE BY YOURSELF. Application/software/system , record, response time, user interface, APS Zamzama,

References:

Name: IEE_Standard_For_SRS.pdf – Document ID: Std-830-1998
Name: APS Report.doc


Overview:
This SRS document contains the functional and non-functional requirements. It will also explain some of the assumptions, future requirements and some design constraints. Overall this document will help explain the requirements of the APS Zamzama software.





















Overall Description


Hardware interfaces:
q Switches, Router, Hardware Firewall
System Requirement:
q 600 MHZ Processor, 128MB RAM, 20GB, Network Card.

Software interfaces:

Name;
Specification number;

Version number
Source
Windows 2003 Server
5.2.1.4
2003
Microsoft
SQL Server 2000 for
5.2.1.4
2000
Microsoft
VB-6

6
Microsoft


Communications interfaces:

TCP/IP protocol, File Transfer Protocol , Local Area Network, IP addresses
ICMP (“Ping” To Check Network Communictions)














Functional Requirements:

v Secure login (password based)
v To store record of Students and Employees department wise.
v Display student record.
v Update all student records.
v Delete records.
v Use of buttons to provide users with functions like:
- Scroll through records
- Move to previous record
- Move to last record
- Move to first record
v Retrieve records.
v Output Records- System should be able to generate reports based on the data available in the database and selection made specifically by the users.
v Search: System shall allow the users of the system to search through records/database.
v System should provide voice messages/commands to the user’s.
v All grids used in the application shall be flex grid.
v System shall allow to store student pictures.
v Application will allow for data backup and recovery procedures.

Non-Functional Requirements:

v Maximum response time per record should not be greater than 2 seconds.
v Searching through all databases should not exceed 5 seconds.
v Should have user-friendly interface.
v The application should be delivered in 5 months



User Characteristics


Users
Expertise level
Education
Principal:

Intermediate
Post Graduate
Vice Principal
Intermediate
Post Graduate
Admission Clerk:

Beginner
Intermediate
Controller Examination:

Beginner
Intermediate
Accounting Clerk:

Beginner
Intermediate


Design Constraints:
n The application only runs on Intel Based Platforms.
n Only VB 6 shall be used to run the application.
n The application will be developed in a time span of 4 months only.
n The application cost shall not exceed Rs 50,000.
n The application will be developed using VB6 on the front end, SQL Server 2000 on backend and Microsoft Seagate Crystal Reports 8i for Outputs.





Software system attributes


Reliability Requirements:

The use of this software the user will expects good and some more relaxation because before this software they store record into the registers. And know they store record into the computer and easily save record, easily search data, delete data, update data etc.

Security Requirements:

Without user no one can open the database only those persons will enter into the database that know the password. The software is perfectly secure. The user can take the backup on daily basis or weekly basses.

Scalability Requirements:

Scalability is building an infrastructure that supports both vertical growth (increase in the number of sales for a specific product) as well as horizontal growth (increase in breadth of product).
The infrastructure must be flexible enough to support growth in network size, transaction handling, data throughput and security. This requires sophisticated tools that can model capacity planning on the site and network.

Maintainability Requirements:

Every one to three months (sometimes sooner), new features are offered in new product iterations. Many of these iterations are developed in parallel with each other. The work products, from the requirements to the code, must be easily maintained in order to keep to this rigorous schedule. Conforming to standards defined by the organization (and by international standards organizations) facilitates the making of products that are easily updated and maintained through each iteration.

Usability Requirements:

The use of this software is so easy, there is no complicated things that user cannot understand. And also the documents are given to the user.



























Other Requirements

Assumptions:
- The management will provide with desktops to the entire user of this software.
- The hardware should be able to support 32-bit applications.
- All systems will be able to run Windows XP/98.
- All systems shall be having a network adapter card installed.
- Operating environment shall allow systems to work on optimum.

Future Requirements:

--Create a web-based application of APS Zamzama software.
-- Create a flash intro of the application.
-- Upgrade Database to SQL Server 2005.

Linux Notes A

A

accept
accept [option] destination
System administration command. Instruct printing system to accept jobs for the specified print queue or queues. Depending on queue settings, the system may prompt for a password. Also invoked as cupsaccept.
Option
-E

access
access [mode] [filename]
Check whether a file is available for the action specified with the mode argument: r for read, w for write, x for execute. Used mostly in scripting, access works better than test because it uses a direct system call rather than looking at the file permissions, which can be misleading when a filesystem is mounted read-only.
Options
--help
Display help message, then quit.
--version
Display version, then quit.
aclocal
aclocal [options]
GNU autoconf tool. Place m4 macro definitions needed by autoconf into a single file. The aclocal command first scans for macro definitions in m4 files in its default directory (/usr/share/aclocal on some systems) and in the file acinclude.m4. It next scans for macros used in the configure.in file. It generates an aclocal.m4 file that contains definitions of all m4 macros required by autoconf.
Options
--acdir=dir
Look for macro files in directory dir instead of the default directory.
--help
Print help message, then exit.
-I dir
Additionally, search directory dir for m4 macro definitions.
--output=file
Save output to file instead of aclocal.m4.
--print-ac-dir
Print the name of the directory to be searched for m4 files, then exit.
--verbose
Print names of files being processed.
--version
Print version number, then exit.


Print

Email article link


aconnect
aconnect [options] [sender] [receiver] aconnect [options]
Like its GUI relative alsa-patch-bay, aconnect connects ports in MIDI hardware and software to route events, similar to running patch cables between different mixers and synthesizers in an all-hardware audio system. aconnect is part of the ALSA (Advanced Linux Sound Architecture) system.
Options
-d,--disconnect
Undo the connection described.
-e,--exclusive
The connection being created must be exclusive: the sender and receiver ports may not connect to any other port.
-i,--input
List all input (sender) ports. This flag is used without any other arguments or flags.
-o, --output
List all output (receiver) ports. This flag is used without any other arguments or flags.
-r, --real queue-name
All events processed through this connection get new timestamps from the named real-time queue. The receiving port must have access to, and use, the real-time queue.
-t, --tick queue-name
All events processed through this connection get new timestamps from the specified tick queue.
-x, --remove-all
Cancel all connections. This flag is used without any other arguments or flags.

Email article link


acpi
acpi [options]
Displays information about the ACPI (Advanced Configuration and Power Interface) system, based on the /proc/acpi file. Most kernels after 2.4 support ACPI hardware, and in both hardware and software, ACPI is gradually replacing the older APM (Advanced Power Management) system. Some operating systems, including SUSE, ship a combined ACPI/APM power interface called powersaved. Most, however, require either ACPI or APM software.
Note that some ACPI systems have special events that are not available on others. For example, IBM laptops have events related to their docking stations and keyboard lights that are not used on nondocking or unlighted laptops. On all systems, the /proc/acpi directory must be present for acpi commands to work.
Options
-b, --battery
Display battery information.
-B, --without-battery
Do not display battery information.
-t, --thermal
Display temperature information.
-T, --without-thermal
Do not display temperature information.
-a, --ac-adapter
Show whether the AC adapter is connected.
-A, --without-ac-adapter
Do not show information about the AC adapter.
-V, --everything
Show all information on every device.
-s, --show-empty
Display information even on devices that are not available or not installed, such as empty slots for extra batteries.
-S, --hide-empty
Do not display information on devices that are not operational or not installed.
-c, --celcius
Use degrees Celsius as the temperature unit. This is the default unit.
-d, --directory /path
Use the specified path to ACPI information. The default path is /proc/acpi.
-f, --fahrenheit
Use degrees Fahrenheit as the temperature unit.
-h, --help
Display help information.
-k, --kelvin
Use degrees Kelvin as the temperature unit.
-v, --version
Display version information
acpi_available
acpi_available
Determine whether ACPI functionality exists. Returns 0 for true and 1 for false.
acpid
acpid [options]
Daemon that informs user-space programs about ACPI (Advanced Configuration and Power Interface) events, such as battery warnings, power-supply changes, and laptop lid closings. As ACPI hardware replaces older APM (Advanced Power Management) hardware, acpid replaces apmd. Like other daemons, this application is controlled primarily through a configuration file that determines which events merit action, and what those actions are. In some operating systems, including SUSE Linux and its relatives, all power management is handled by a combined ACPI/APM system called powersave and this daemon is not installed.
Options
-c directory, --confdir=directory
Set the directory used for configuration files. The default directory is /etc/acpi/events. All files in this directory, except those beginning with a period (.), are parsed as configuration files. Typically, a single file is used for each ACPI event to be acted upon.
In the configuration files, blank lines and those beginning with # are ignored. Other lines are expected to consist of a regular expression and a command to be executed when an ACPI event matches the expression.
-d, --debug
Debug mode: run the daemon in the foreground and send all log output to stderr and stdout, rather than a logfile.
-e filename,--eventfile=filename
Set the file used to find events. Normally this is /proc/acpi/event.
-g group,--socketgroup=group
Set the group ownership of the socket to which acpid publishes events. This allows you to restrict which users on the system can access ACPI event information.
-l filename,--logfile=filename
Set the logfile location. Normally, it is /var/log/acpid.
-m mode,--socketmode=mode
Set the permission mode of the socket. Normally, it is 666, with the sticky bit off.
-s filename,--socketfile=filename
Set the file used to define the socket. Normally, this is /var/run/acpid.socket.
-S,--nosocket
Tells acpid not to open a socket at all. Overrides all other socket options.
-v,--version
Print version information and quit.
-h,--help
Print help message and quit.
addr2line
addr2line [options] [addresses]
Translate hexadecimal program addresses into filenames and line numbers for the executable given with the -e option, or a.out if -e is not specified. If addresses are given on the command line, display the filename and line number for each address. Otherwise, read the addresses from standard input and display the results on standard output (useful for use in a pipe). addr2line prints two question marks (??) if it cannot determine a filename, and 0 if it cannot determine the line number. addr2line is used for debugging.
Options
-b bfdname, --target=bfdname
Set the binary file format using its binary file descriptor name, bfdname. Use the -h option for a list of supported formats for your system.
-C, --demangle[=style]
Decode (demangle) low-level symbol names into usernames. See the -h help output for a list of styles supported by your compiler.
-e file, --exe=file
Specify the filename of the executable to use. The default filename is a.out.
-f, --functions
Display function names in addition to filenames and line numbers.
-h, --help
Display help information and exit.
-s, --basenames
Strip directories off filenames and show only the basenames.
addresses
addresses [-p port]
Connect to the PalmOS device on the specified port, and dump the addresses from the address book to stdout. Part of the pilot-link package of tools for managing PalmOS devices.
agetty
agetty [options] port baudrate [term]
System administration command. The Linux version of getty. Set terminal type, modes, speed, and line discipline. agetty is invoked by init. It is the second process in the series init-getty-login-shell, which ultimately connects a user with the Linux system. agetty reads the user's login name and invokes the login command with the user's name as an argument. While reading the name, agetty attempts to adapt the system to the speed and type of device being used.
You must specify a port, which agetty will search for in the /dev directory. You may use -, in which case agetty reads from standard input. You must also specify baudrate, which may be a comma-separated list of rates through which agetty will step. Optionally, you may specify the term, which is used to override the TERM environment variable.
Options
-f file
Specify the use of file instead of /etc/issue upon connection to terminal. It is overridden by -i.
-h
Specify hardware, not software, flow control.
-H hostname
Write login hostname into the utmp file. By default, no login host is specified.
-I string
Specify string to be sent to the tty or modem.
-i
Suppress printing of /etc/issue before printing the login prompt.
-l program
Specify the use of program instead of /bin/login.
-L
Do not require carrier detect; operate locally only. Use this when connecting terminals.
-m
Attempt to guess the appropriate baud rate.
-n
Don't prompt for a login name.
-t timeout
Specify that agetty should exit if the open on the line succeeds and there is no response to the login prompt in timeout seconds.
-w
Wait for carriage return or linefeed before sending login prompt. Use when sending an initialization string.
amidi
amidi [options]
Read and write raw MIDI files (.syx format, without timing information) to ALSA ports. For standard MIDI (.mid) files, use aplaymidi and arecordmidi.
Options
-a,--active-sensing
Record and send active-sensing (FEh) bytes in MIDI commands. By default, these bytes are ignored.
-d,--dump
Output all received data directly to the screen.
-h,--help
Display help information and quit.
-l,--list-devices
List all hardware MIDI ports.
-L,--list-rawmidis
List all RawMIDI definitions. Useful for debugging configuration files.
-p,--port=name
Use the specified port. This overrides the port set in the configuration file. If neither this flag nor the configuration file sets a port, the default is port 0 on device 0, which may or may not exist.
-r,--receive=filename
Write data from the port specified with the -p or --port flag to the file named here. This will be a raw file, and should end in .syx. Unless you use the -a option, it will not contain any Active Sensing (FEh) bytes.
-s,--send=filename
Send the file to the port specified with the -p or --port flag. Use raw (.syx) MIDI files only.
-S,--send-hex="hex-numbers..."
Send a string of hexadecimal numbers to the port specified with the -p or --port flag.
-t,--timeout=n
Stop listening after n seconds of receiving no data.
-V,--version
Display version information and quit.
amixer
amixer [-ccard] [command]
Command-line ALSA mixer. For an ncurses interface, use alsamixer. amixer displays or changes the current mixer settings for the current sound card and sound device. To display all mixer settings, use with no flags or commands.
Commands
controls
Displays a complete list of card controls. These controls can be set with the cset command, in contrast to simple mixer controls, which use set or sset.
contents
List card controls and their contents.
cget [control]
Display the contents of the specified card control.
cset [control] [parameter]
Set the card control to the value specified in the parameter. Card controls may be identified by iface, name, index, device, subdevice, or numid. The parameter will normally be a number or percentage value. For example, the command amixer -c 1 cset numid=16 50% will set the 16th element of the first sound card to 50%.
get,sget [control]
Display the current values for the specified control.
help
Display help message and quit.
info
Displays information about the card specified with the -c flag.
scontrols
Display a list of simple mixer controls. Simple mixer controls can be set with the set or sset commands, in contrast to card controls, which use the cset command.
set,sset [control] [parameter]
Set one of the controls listed by scontrols. You can specify the volume with a percentage from 0% to 100%, or a specific hardware value. By appending + or - to the number, you will increase or decrease the volume by that amount. To set recording and muting values, use the parameters cap (meaning capture, or record), nocap,mute,unmute, or toggle. To specify individual channels, use the parameters front, rear, center, or woofer. For example, the command amixer -c 1 sset Line,0 100% unmute will set Line 0 on the first sound card to 100% and unmute it.
Options
-c n
The number of the card to adjust.
-D devicename
Specify the name of the device. By default, the name is default.
-h
Display help information and quit.
-q
Quiet mode: do not show the results of changes made
anacron
anacron [options] [job]
System administration command. Normally started in a system startup file. Execute commands periodically. By default, anacron reads a list of jobs from a configuration file, /etc/anacrontab. The file consists of shell variables to use when running commands, followed by a list of tasks to run. Each task specifies how often in days it should be run, a delay in minutes to wait before running the task, a unique job identifier used to store a timestamp, and the shell command to execute. Timestamps for the last run of each task are stored in the /var/spool/anacron file. For each task, anacron compares the stored timestamp against the current time. If the command has not been executed within the specified frequency, the command is run. Upon completion, anacron records the new date in the timestamp file. Limit anacron to a specified task by providing the task's unique job identifier on the command line.
The anacron command is often used to support the cron daemon on systems that do not run continuously.
Options
-d
Run in foreground rather than as a background process. Send messages to standard error.
-f
Run tasks ignoring timestamps.
-h
Print help message, then exit.
-n
Run tasks now, ignoring delay specifications.
-q
Suppress messages to standard error when using the -d option.
-s
Execute tasks serially. Do not start new task until previous task is completed.
-t file
Read tasks from file instead of from /etc/anacrontab.
-u
Update timestamps for tasks, but don't run them.
-V
Print version number, then exit.
aplay
aplay [options] [file]
Play sound files using the ALSA sound system. The related arecord records sound files.
Options
-h
Print help message, then exit.
--version
Print version and quit.
-l,--list-devices
List available sound cards and digital audio devices.
-L,--list-pcms
List all PCM (pulse-coded modulation, or digital audio) devices that have been defined. PCMs may be defined in the .asoundrc file.
-D,--device=devicename
Select a PCM device by name.
-q
Do not display messages.
-t,--file-type=type
Name the file type used. Files may be voc, wav, raw, or au.
-c,--channels=n
Use n channels: 1 for mono, 2 for stereo.
-f,--format=format
Specify the sample format. The sample formats available will depend on hardware. For CD and DAT output, use the cd and dat shortcuts, which set the sample rate, format, and channel numbers all at once.
-r,--rate=n
Set the sample rate in Hertz.
-d,--duration=n
Set an interrupt for n seconds after playback begins.
-s,--sleep-min=n
aplaymidi
aplaymidi [options] [file]
Play MIDI files using the ALSA sound system; output is to ALSA sequencer ports.
Options
-d,--delay=n
Delay n seconds at the end of a file to allow for reverberation of the final notes.
-h
Print help message, then exit.
-V
Print version and quit.
-l
List output ports available.
-p,--port=client:port
Specify the port to which the MIDI file will be sent. If no port is specified, the file will be sent to port 0.
apm
apm [options]
Display current Advanced Power Management hardware information, such as battery life, or send the system into standby or suspend-to-disk mode. Used on older systems, and replaced by acpi and related commands.
-V, --version
Display version information and quit.
-v,--verbose
Verbose mode. Display information about the APM BIOS and Linux APM driver.
-m, --minutes
Display estimated minutes of battery life remaining. Default format is in hours and minutes.
-s, --suspend
Suspend system to disk. Suspending the system to disk is equivalent to turning it off, but boot time will be faster and the system will resume exactly where it was before suspend.
-S, --standby
Set system to standby. This will normally turn off the monitor and spin down the disk drives, reducing energy consumption by approximately 50 percent. Recovery from this mode is more rapid than from a full suspend to disk, but the system is still running.
-i,--ignore
When the system is using AC power, ignore suspend or standby requests generated by the system.
-n,--noignore
Do not ignore any suspend or standby events. This overrides a previously issued -i flag.
apmd
apmd [options]
System administration command. apmd handles events reported by the Advanced Power Management BIOS driver. The driver reports on battery level and requests to enter sleep or suspend mode. apmd will log any reports it gets via syslogd and take steps to make sure that basic sleep and suspend requests are handled gracefully. You can fine-tune the behavior of apmd by editing the apmd_proxy script, which apmd runs when it receives an event. Note that the APM hardware standard is gradually being replaced by the ACPI (Advanced Configuration and Power Interface) standard, and apmd by acpid. On SUSE Linux, both APM and ACPI hardware are handled by powersave and powersaved.
Options
-c n, --check n
Set the number of seconds to wait for an event before rechecking the power level. Default is to wait indefinitely. Setting this causes the battery levels to be checked more frequently.
-p n, --percentage n
Log information whenever the power changes by n percent. The default is 5. Values greater than 100 will disable logging of power changes.
-P command, --apmd_proxy command
Specify the apmd_proxy command to run when APM driver events are reported. This is generally a shell script. The command will be invoked with parameters indicating what kind of event was received. The parameters are listed in the next section.
-v, --verbose
Verbose mode; all events are logged.
-V, --version
Print version and exit.
-w n, --warn n
Log a warning at ALERT level when the battery charge drops below n percent. The default is 10. Negative values disable low-battery-level warnings.
-W, --wall
Use wall to alert all users of a low battery status.
-q, --quiet
Disable low-battery-level warnings.
-?, --help
Print help summary and exit.
Parameters
The apmd proxy script is invoked with the following parameters:
start
Invoked when the daemon starts.
stop
Invoked when the daemon stops.
suspend [ system user ]
Invoked when the daemon receives a suspend request. The second parameter indicates whether the request was made by the system or by the user. Suspend, also known as "hibernate," effectively powers the system down but has a quicker recovery than a normal boot process.
standby [ system user ]
Invoked when the daemon receives a standby request. The second parameter indicates whether the request was made by the system or by the user. Standby mode powers off the monitor and disks, but the system continues to run and use power.
resume [ suspend standby critical ]
Invoked when the system resumes normal operation. The second parameter indicates the mode the system was in before resuming. critical suspends indicate an emergency shutdown. After a critical suspend, the system may be unstable, and you can use the resume command to help you recover from the suspension.
change power
Invoked when system power is changed from AC to battery or from battery to AC.
change battery
Invoked when the APM BIOS driver reports that the battery is low.
change capability
Invoked when the APM BIOS driver reports that some hardware that affects its capability has been added or removed.
apropos
apropos string ...
Search the short manual page descriptions in the whatis database for occurrences of each string and display the result on the standard output. Like whatis, except that it searches for strings instead of words. Equivalent to man -k.
apt
apt
The Advanced Package Tool, the Debian package management system. A freely available packaging system for software distribution and installation. For detailed information on apt and its commands, see Chapter 5.
ar
ar key [args] [posname] [count] archive [files]
Maintain a group of files that are combined into a file archive. Used most commonly to create and update static library files, as used by the link editor (ld). Compiler frontends often call ar automatically. Only one key letter may be used, but each can be combined with additional args (with no separations between). posname is the name of a file in archive. When moving or replacing files, you can specify that they be placed before or after posname. ar has largely been superseded by tar and bzip2.
Keys
d
Delete files from archive.
m
Move files to end of archive.
p
Print files in archive.
q
Append files to archive.
r
Replace files in archive.
t
List the contents of archive or list the named files.
x
Extract contents from archive or only the named files.
Arguments
a
Use with r or m key to place files in the archive after posname.
b
Same as a, but before posname.
c
Create archive silently.
f
Truncate long filenames.
i
Same as b.
l
For backward compatibility; meaningless in Linux.
N
Use count parameter. Where multiple entries with the same name are found, use the count instance.
o
Preserve original timestamps.
P
Use full pathname. Useful for non-POSIX-compliant archives.
s
Force regeneration of archive symbol table (useful after running strip).
S
Do not regenerate symbol table.
u
Use with r to replace only files that have changed since being put in archive.
v
Verbose; print a description of actions taken.
V
Print version number.
Example
Replace mylib.a with object files from the current directory:
ar r mylib.a `ls *.o`
arch
arch
Print machine architecture type to standard output. Equivalent to uname -m.
arecord
arecord [options] [filename]
Records sound using ALSA. Accepts the same arguments and options as aplay.
arecordmidi
arecord [options] [filename]
Records midi files using ALSA. You must specify the port using the -p flag.
Options
-p,--port=host:port
Set the sequencer host and port used. The default host is the local host, and the default is port 0.
-h,--help
Display help message.
-v,--version
Display version number.
-l, --list
List available ports.
-b,--bmp=n
Set the tempo value to n beats per minute. The default is 120.
-f,--fps=n
Set timing (SMPTE resolution) to n frames per second. The value is normally 24, 25, 29.97 (NTSC dropframe), or 30.
-t,--ticks=n
Set the frequency with which timestamps, or ticks, are used in the file. For MIDI files using musical tempo, timestamps are set in ticks per beat (default 384), while those with SMPTE timing use ticks per frame (default 40).
-s,--split-channels
For each channel of input, create a separate track in the MIDI output file.
arp
arp [options]
TCP/IP command. Clear, add to, or dump the kernel's Address Resolution Protocol (ARP) cache (/proc/net/arp). ARP is used to translate protocol addresses to hardware interface addresses. Modifying your ARP cache can change which interfaces handle specific requests. ARP cache entries may be marked with the following flags: C (complete), M (permanent), and P (publish). While arp can create a proxy for a single system, subnet proxies are now handled by the arp kernel module, arp(7). See the "Linux 2.4 or later Advanced Routing HOWTO" for details.
Options
host option arguments may be given as either a hostname or an IP address. With the -D option, they may also be given as a hardware interface address (e.g., eth0, eth1).
-a [hosts] , --display [hosts]
Display entries for hosts or, if none are specified, all entries.
-d host [pub] , --delete host [pub]
Remove the specified host's entry. To delete a proxy entry, add the pub argument and specify the interface associated with the proxy using -i.
-D, --use-device
Use the hardware address associated with the specified interface. This may be used with -s when creating a proxy entry.
-f file, --file file
Read entries from file and add them.
-H type, --hw-type type, -t type
Search for type entries when examining the ARP cache. type is usually ether (Ethernet), which is the default, but may be ax25 (AX.25 packet radio), arcnet (ARCnet), pronet (PROnet), or netrom (NET/ROM).
-i interface, --device interface
Select an interface. If you are dumping the ARP cache, this option will cause the command to display only the entries using that interface. When setting entries, this will cause the interface to be associated with that entry. If you do not use this option when setting an entry, the kernel will guess.
-n, --numeric
Display host IP addresses instead of their domain names.
-s host hardware-address [netmask mask] [pub] , --set host hardware-address [pub]
Add a permanent entry for host at hardware-address. A hardware-address for type ether hardware is 6 hexadecimal bytes, colon-separated. The pub argument can be used to set the publish flag, creating a proxy entry.
-v, --verbose
Verbose mode.
Examples
Display entry for host eris:
arp -a eris
Set a permanent cache entry for host illuminati, whose hardware address you know:
arp -s illuminati 00:05:23:73:e6:cf
Set an ARP proxy for host fnord using the eth0 interface's hardware address:
arp -Ds fnord eth0 pub
Remove the fnord ARP proxy:
arp -i eth0 -d fnord pub
as
as [options] files
Generate an object file from each specified assembly-language source file. Object files have the same root name as source files but replace the .s suffix with .o. There may be some additional system-specific options.
Options
-- [ files]
Read input files from standard input, or from files if the pipe is used.
-a[cdhlmns] [=file]
With only the -a option, list source code, assembler listing, and symbol table. The other options specify additional things to list or omit:
-ac
Omit false conditionals.
-ad
Omit debugging directives.
-ah
Include the high-level source code, if available.
-al
Include an assembly listing.
-am
Include macro expansions.
-an
Suppress forms processing.
-as
Include a symbol listing.
=file
Set the listing filename to file.
--defsym symbol=value
Define the symbol to have the value value, which must be an integer.
-f
Skip whitespace and comment preprocessing.
--fatal-warnings
Treat warnings as errors.
--gstabs
Generate debugging information in stabs format.
--gdwarf2
Generate DWARF2 debugging information.
-o objfile
Place output in object file objfile (default is file.o).
--statistics
Print information on how much time and space assembler uses.
-v
Display the version number of the assembler.
-I path
Include path when searching for .include directives.
-J
Don't warn about signed overflow.
-R
Combine both data and text in text section.
-W
Don't show warnings.
-Z
Generate object file even if there are errors.
at
at [options] time [date]
Execute commands at a specified time and optional date. The commands are read from standard input or from a file. (See also batch.) End input with EOF. time can be formed either as a numeric hour (with optional minutes and modifiers) or as a keyword. It can contain an optional date, formed as a month and date, a day of the week, or a special keyword (today or tomorrow). An increment can also be specified.
The at command can always be issued by a privileged user. Other users must be listed in the file /etc/at.allow if it exists; otherwise, they must not be listed in /etc/at.deny. If neither file exists, only a privileged user can issue the command.
Options
-c job [job...]
Display the specified jobs on the standard output. This option does not take a time specification.
-d job [job...]
Delete the specified jobs. Same as atrm.
-f file
Read job from file, not from standard input.
-l
Report all jobs that are scheduled for the invoking user. Same as atq.
-m
Mail user when job has completed, regardless of whether output was created.
-q letter
Place job in queue denoted by letter, where letter is any single letter from a-z or A-Z. Default queue is a. (The batch queue defaults to b.) Higher-lettered queues run at a lower priority.
-V
Display the version number.
Time
hh:[mm] [modifiers]
Hours can have one digit or two (a 24-hour clock is assumed by default); optional minutes can be given as one or two digits; the colon can be omitted if the format is h, hh, or hhmm (e.g., valid times are 5, 5:30, 0530, 19:45). If modifier am or pm is added, time is based on a 12-hour clock. If the keyword zulu is added, times correspond to Greenwich Mean Time.
midnight noon teatime now
Use any one of these keywords in place of a numeric time. teatime translates to 4:00 p.m.; now must be followed by an increment (described in a moment).
Date
month num[, year]
month is one of the 12 months, spelled out or abbreviated to its first three letters; num is the calendar date of the month; year is the four-digit year. If the given month occurs before the current month, at schedules that month next year.
day
One of the seven days of the week, spelled out or abbreviated to its first three letters.
today tomorrow
Indicate the current day or the next day. If date is omitted, at schedules today when the specified time occurs later than the current time; otherwise, at schedules tomorrow.
Increment
Supply a numeric increment if you want to specify an execution time or day relative to the current time. The number should precede any of the keywords minute, hour, day, week, month, or year (or their plural forms). The keyword next can be used as a synonym of + 1:
Examples
In typical usage, you run at and input commands that you want executed at a particular time, followed by EOF.
$ at 1:00 am tomorrow at> ./total_up > output at> mail joe <> Entered by pressing Ctrl-D job 1 at 2003-03-19 01:00
The two commands could also be placed in a file and submitted as follows:
$ at 1:00 am tomorrow < scriptfile
More examples of syntax follow. Note that the first two commands here are equivalent:
$ at 1945 December 9 $ at 7:45pm Dec 9 $ at 3 am Saturday $ at now + 5 hours $ at noon next day
atd
atd options
System administration command. Normally started in a system startup file. Execute jobs queued by the at command.
Options
-b n
Wait at least n seconds after beginning one job before beginning the next job. Default is 60.
-d
Print error messages to standard error instead of using syslog.
-l average
When system load average is higher than average, wait to begin a new job. Default is 0.8.
-s
Process queue once, then exit.
atq
atq [options]
List the user's pending jobs, unless the user is a privileged user; in that case, list everybody's jobs. Same as at -l, and related to batch and atrm.
Options
-q queue
Query only the specified queue and ignore all other queues.
-v
Show jobs that have completed but have not yet been deleted.
-V
Print the version number.
atrm
atrm [options] job [job...]
Delete jobs that have been queued for future execution. Same as at -d.
Options
-q queue
Remove job from the specified queue.
-V
Print the version number and then exit.
aumix
aumix [options]
Audio mixer tool. Run without any options or arguments for an ncurses-based interactive mode.
Options
The first set of options sets the volume level of a channel to a percentage of the maximum. Each channel is represented by a single letter or number: v for overall volume, b for bass, t for treble, s for synthesizer, w for PCM channels, c for CD, m for microphone, i for line in, o for line out, l for the main line, x for imix, and 1, 2, or 3 for lines 1, 2, and 3. Passing q as an argument to any of those flags displays their current status. Passing + or - will increase or decrease the channel volume by one, and +n or -n will adjust them by n.
For example, aumix -c q -l 10 will display the CD value and set the main line to 10%.
Additional options:
-C filename
Use the color-scheme file specified to determine the appearance of the ncurses interface.
-d devicename
Specify the mixer device to be used. The default is /dev/mixer.
-f filename
Specify a settings file.
-h
Display a help message and quit.
-I
Interactive mode: provides an ncurses-based UI similar to alsamixer.
-L
Load settings from the default .aumixrc file.
-q
Query all devices, and display the results.
-S
Save settings to the default .aumixrc file.
autoconf
autoconf [options] [template_file]
Generate a configuration script from m4 macros defined in template_file, if given, or in a configure.ac or configure.in file in the current working directory. The generated script is almost invariably called configure.
Options
-d, --debug
Don't remove temporary files.
-f, --force
Replace files generated previously by autoconf.
-h, --help
Print help message, then exit.
-i, --initialization
When tracing calls with the -t option, report calls made during initialization.
-o file, --output=file
Save output to file.
-t macro, --trace=macro
Report the list of calls to macro.
-v, --verbose
Verbosely print information about the progress of autoconf.
-B dir, --prepend-include=dir
Prepend directory dir to the search path.
-I dir, --include=dir
Append directory dir to the search path.
-V, --version
Print version number, then exit.
-W category, --warnings=category
Print any warnings related to category. Accepted categories are:
cross
Cross compilation.
obsolete
Obsolete constructs.
syntax
Questionable syntax.
all
All warnings.
no-category
Turn off warnings for category.
none
Turn off all warnings.
error
Treat warnings as errors.
autoheader
autoheader [options] [template_file]
GNU autoconf tool. Generate a template file of C #define statements from m4 macros defined in template_file, if given, or in a configure.ac or configure.in file in the current working directory. The generated template file is almost invariably called config.h.in.
Options
-d, --debug
Don't remove temporary files.
-f, --force
Replace files generated previously by autoheader.
-h, --help
Print help message, then exit.
-o file, --output=file
Save output to file.
-v, --verbose
Verbosely print information about the progress of autoheader.
-B dir, --prepend-include=dir
Prepend directory dir to the search path.
-I dir, --include=dir
Append directory dir to the search path.
-V, --version
Print version number, then exit.
-W category, --warnings=category
Print any warnings related to category. Accepted categories are:
obsolete
Obsolete constructs.
all
All warnings.
no-category
Turn off warnings for category.
none
Turn off all warnings.
error
Treat warnings as errors.
automake
automake [options] [template_file]
GNU automake tool. Create GNU standards-compliant Makefile.in files from Makefile.am template files and can be used to ensure that projects contain all the files and install options required to be standards-compliant. Note that Versions 1.4 and 1.6 differ enough that many distributions include an automake14 package for backward compatibility.
Options
-a, --add-missing
Add any missing files that automake requires to the directory by creating symbolic links to automake's default versions.
-c, --copy
Used with the -a option. Copy missing files instead of creating symbolic links.
--cygnus
Specifies project has a Cygnus-style source tree.
-f, --force-missing
Used with the -a option. Replace required files even if a local copy already exists.
--foreign
Treat project as a non-GNU project. Check only for elements required for proper operation.
--gnu
Treat project as a GNU project with the GNU project structure.
--gnits
A stricter version of --gnu, performing more checks to comply with GNU project structure rules.
--help
Print help message, then exit.
-i, --ignore-deps
Disable automatic dependency tracking.
--libdir=dir
Used with the -a option. Search in directory dir for default files.
--no-force
Update only Makefile.in files that have updated dependents.
-v, --verbose
List files being read or created by automake.
--version
Print version number, then exit.
-Werror
Treat warnings as errors.
autoreconf
autoreconf [options]
GNU autoconf tool. Update configure scripts by running autoconf, autoheader, aclocal, automake, and libtoolize in specified directories and subdirectories. This command is seldom invoked manually. It is usually called automatically from other autoconf tools.
Options
-d, --debug
Don't remove temporary files.
-f, --force
Remake all configure scripts, even when newer than their template files.
-h, --help
Print help message, then exit.
-i, --install
Add any default files missing from package by copying versions included with autoconf and automake.
-s, --symlink
Used with the -i option. Create symbolic links to default files instead of copying them.
-v, --verbose
Verbosely print information about the progress of autoreconf.
-I dir, --include=dir
Search in directory dir for input files.
-V, --version
Print version number, then exit.
-W category, --warnings=category
Print any warnings related to category. Accepted categories are:
cross
Cross compilation.
obsolete
Obsolete constructs.
syntax
Questionable syntax.
all
All warnings.
no-category
Turn off warnings for category.
none
Turn off all warnings.
error
Treat warnings as errors.
autoscan
autoscan [options] [directory]
GNU autoconf tool. Create or maintain a preliminary configure.ac file named configure.scan based on source files in specified directory, or current directory if none given. If a configure.ac file already exists, autoconf will check it for completeness and print suggestions for correcting any problems it finds.
Options
-d, --debug
Don't remove temporary files.
-h, --help
Print help message, then exit.
-v, --verbose
Verbosely print information about the progress of autoscan.
-I dir, --include=dir
Search in directory dir for input files. Use multiple times to add multiple directories.
-B dir, --prepend-include=dir
Search dir for input files before searching in other directories. Use multiple times to add multiple directories.
-V, --version
Print version number, then exit.
autoupdate
autoupdate [options] [file]
GNU autoconf tool. Update the configure template file file, or configure.ac if no file is specified. This command is seldom invoked manually. It is usually called automatically from other autoconf tools.
Options
-d, --debug
Don't remove temporary files.
-f, --force
Remake all configure scripts, even when newer than their template files.
-h, --help
Print help message, then exit.
-v, --verbose
Verbosely print information about the progress of autoupdate.
-I dir, --include=dir
Search in directory dir for input files.
-V, --version
Print version number, then exit.

Source : www.linuxdevcenter.com

Singh is Kinng - Jee karda [FULL SONG!!!]

Jee Karda - Singh is Kinng

Bridal mehndi trends in the Middle East

Weddings are a time to celebrate, like all festive occasions and rituals it brings happiness and harmony, renews family ties, strengthens bonds of friendship and spreads merriment.
The age old custom of women applying mehndi or henna to adorn the hands and feet originated as early as the 12th century, in the Middle East, and thereafter spread to South Asia and some parts of Africa. This ancient art is now becoming increasingly popular in many European countries and in the United States.
History reveals that, mehndi patterns reflect distinct styles, depending on their country of origin. The Sub-continent has delicate, intricate patterns of paisleys, while the Africans prefer large geometric shapes. The Middle Eastern States replicated the Arabs, in their designs and motifs created in miniature paintings, textiles and carvings.
While bridal fashions, hairstyles and embroidery have evolved over the centuries, the trend of mehndi designs applied to brides in the Middle East left an indelible mark from history (almost patented), and even today the primitive patterns of mehndi styles in the Middle East are symbolic in appearance from it’s neighbouring countries.
Bridal mehndi styles in the Middle East can be distinguished by:
• Large bold pattern of flowers centering the palm, and creeping vines with closed flower buds and leaves decorating the fingers.
• Chunky mystical motifs in abstract forms, seashells and shapes of symmetrical designs are also very popular.
• The colour is mehndi is usually black or dark brown.
• Blocks of colour cover the finger tips and toes, as though these have been dipped in a bowl of mehndi.
The ‘rasam-e-henna’ or ritual of mehndi applied to a bride, takes place a day or two before the wedding; it has valuable significance in different cultures. Some consider it a form of blessing; others believe it brings good luck and happiness, as well as increases fertility.

Source : http://www.rewaj.com

"Grace" a disappointment for horror fans

Source : rewaj.com

Traditional yet Novel Bridal Dresses for a Stylish Wedding.

Wedding is an auspicious occasion when every bride has a desire to be looked stunning and gorgeous, as it is the most important day in her life. So, all the outfits of the bridal wear need keen attention, careful planning, and right choice.

Whatever the preferences may be, but a wedding in Pakistan is bound to be unforgettable - every marriage is the sign for an important family celebration. A marriage is incomplete without the typical wedding dress, which compasses Pakistani culture and heritage. On one hand, traditional weddings are gaining a lot of popularity and the long-established wedding customs are still very important, but on the other hand today’s modern bride isn’t afraid to put a new twirl on an old idea.

Brides are finding novel ways to present their own style with appealing slants on customary traditions and with the passage of time the established domain of wedding dress has started to bend to the trend. Today, the brides have a wide variety of wedding dress to choose from and outfits like Gahgra Choli, Gharara, Sharara and Pishwas are few traditional bridal dresses which are commonly worn by Pakistani brides.

Pakistani brides are known for their elegant traditional dresses, which are usually, embellished with embroidery, beads and sequences. Not only this, but the expensive clothes are used to enhance the look of the bride’s dress which is normally worn only once in a life time.

In Pakistan the traditional color of female wedding dress is red. Choosing the right color Lehnga is very important, for fair complexion you can go for almost any color. But you will look best in light colors and pastel shades and colors like peach, lilac, pink, sky blue, sea green and medium range blues are all good choices. For evening occasions one can opt for deep navy and sapphire blue with silver accents.

People should avoid very pale or pastel colors if their complexion is very fair, as they can wash out fair skin and colors like ruby red, bright orange, rust, turquoise and navy blue would be best for such complexion. The basic black and white colors are always suitable, but for dusky skin one can wear bright colors like sunshine yellow, bright orange, red, magenta and bright blue.

Lehngas are often hand decorated in the traditional designs such as Zardozi embroidery. Just as in ancient times, these Lehnga suits are still hand decorated to keep it as true to tradition as possible. Now-a-days embroidery works for these wedding dresses include combination of different embroidery styles by experts.

Some of these embroidery works are gotta, dabka, kora, beads, thread work, discs, silk embroidery to produce elegance in the modern and traditional wedding dresses. Embroidery, sitara, dabka or zari work looks beautiful on clothes but need a lot of hard work in its making. The craftsmen make designs with real silver and gold wires, embellished with stones, beads and other imitation material. The price ranges from as low as 5000 and as high as 4 to 500000 Rupees.


Source: http://www.rewaj.com