Try out our Premium Member services: Virtual Legal Assistant, Query Alert Service and an ad-free experience. Free for one month and pay only if you like it.
BEFORE THE NATIONAL GREEN TRIBUNAL (WESTERN ZONE) BENCH, PUNE APPLICATION NO.2/2014 CORAM : HON'BLE SHRI JUSTICE V.R. KINGAONKAR (JUDICIAL MEMBER) HON'BLE DR. AJAY A.DESHPANDE (EXPERT MEMBER) B E T W E E N: DILEEP B. NEVATIA Shashi Deep, 5-A, Worli Sea Face, Mumbai-400030. ....APPLICANT AND 1. UNION OF INDIA Through the Secretary, Ministry of Environment & Forests, ParyavaranBhawan, CGO Complex, Lodhi Road, New Delhi-110003. 2. MINISTRY OF ROAD TRANSPORT & HIGHWAYS Through the Secretary, Transport Bhavan,1, Parliament Street New Delhi 110 001. 3. CENTRAL POLLUTION CONTROL BOARD Through the Member Secretary PariveshBhavan, CBD cum Office Complex East Arjun Nagar, New Delhi 110 032. (J) Appln No.2/2014 Page 1 4. Maharashtra Pollution Control Board Through its Member Secretary Kalpatru Point, 3rd& 4th Floor, SionMatunga Road, No.8 Sion Circle, Sion (East), Mumbai-400026. 5. AUTOMOTIVE RESEARCH ASSOCIATION OF INDIA Through the Director Survey No.102, Vetal Hill, Off Paud Road Kothrud, Pune-411 038. 6. State of Maharashtra, Through its Chief Secretary, Mantralaya, Mumbai-400023. 7. The Transport Commissioner Government of Maharashtra Administrative Building, 4th Floor, Bandra East, Mumbai-400 051. .........Respondents
Counsel for Applicant In Person.
Counsel for Respondent(s):
Mr. Neharu Advocate a/w Shweta Busar for Respondent No.1. Mr. K.D.Ratnaparkhi, Advocate for Respondent No.2. Mr. A.B.Avhad Advocate a/w R.A.Andhale Advocate for Respondent No.3.
Mr.D.M.Gupte Advocate a/w Supriya Dangare Advocate for Respondent Nos.4 & 5.
Mrs. Ujwala Pawar DGP/Mr.A.S. Mulchandani, AGP, a/w Mr. Jitendra Patil, Mr. Yogesh Bag RTOs for Respondent Nos. 6 & 7.
Date: September 23rd, 2014 (J) Appln No.2/2014 Page 2 1. J U D G M E N T
1. This Application has been filed under Section 14 read with Section 18 of the National Green Tribunal Act, 2010. Briefly stated the Applicant, named above, has raised substantial issue relating to environment by contending that the present regulatory framework is not being effectively implemented by Respondents in terms of standards specified for noise limits for automobiles at the manufacturing stage.
2. In the Present Application, Respondent No.1 is a Central Government Ministry for the planning, promotion, co- ordination and overseeing the implementation of the country's environmental and forestry policies and programmes. Respondent No.2 is also a Central Government Ministry and amongst its main responsibility is to administer the Motor Vehicles Act, 1988 and the Rules made there- under. Respondent No.3 is a statutory Board, and its main functions are to improve the quality of air and to prevent, control and abate air pollution in the country. Respondent No.4 is also a statutory Board which has a mandate for air pollution control, abatement, fixing standards etc for the State of Maharashtra. Respondent No.5 is a co-operative industrial research association established by the automotive industry with the Ministry of Industries, Government of India (J) Appln No.2/2014 Page 3 and amongst its main activities is research in automotive sector and testing the vehicles/automobiles. Respondent No.6 is the State of Maharashtra and Respondent No.7 is responsible to give effect to the provisions of Motor Vehicles Act, 1988 and Rules made there-under for the State of Maharashtra.
3. The Applicant submits that Schedule VI, in part E of the Environment (Protection) Rules, 1986 specify the noise limits relating to noise standards for construction of vehicles at the manufacturing stage with effect from 1st July, 2005, which is to be monitored as per test method IS: 3028-1988,. The Applicant claims that he came to know recently that the Respondents are neither monitoring the noise levels of constructed vehicles at the manufacturing stage, in accordance with IS: 3028-1988 nor they are ensuring compliance of noise limits by these vehicles, as specified in Schedule VI, Part E, of the Environment (Protection) Rules, 1986.
4. The Applicant further submits that the noise pollution caused by the moving vehicles is, by far the biggest contributor to the noise pollution all over the country and, therefore, it is necessary to enforce and monitor the compliance of noise standards for the vehicles at manufacturing stage, as prescribed under Schedule VI, Part E, of the Environment (Protection) Rules, 1986. The (J) Appln No.2/2014 Page 4 Applicant further submits that the Air (Prevention and Control of Pollution) Act, 1981, has defined the "air pollutants" as any solid, liquid or gaseous substance (including noise) in the atmosphere in such concentration as may be or tend to be injurious to human beings or other living creatures or plants or the property or environment. He further submits that by subsequent amendment the 'noise' has also been included as an 'air pollutant' in the said Act. The Applicant further submits that under Section 16 of the said Act, the Central Pollution Control Board, i.e. Respondent No.3, has overall responsibility to improve quality of air and to prevent, control or abate air pollution in the country. Further, it is contended that as per Sub Section (2) (h) of Section 16 of this Act, the Respondent No.3, is required to lay down standards for the quality of air. The applicant also submits that State Pollution Control Board, i.e. Respondent No.4 is required under Section 17(i) (g) of this Act, to lay down, in consultation with the Central Board, and having regard to standards for quality of air, laid down by the Central Board, standards for emission of air pollutants into the atmosphere. The Applicant also submits that Respondent No.4, i.e. Maharashtra Pollution Control Board (MPCB), has powers to give instructions and directions under Section 31 A of the said Act for ensuring implementation of emissions standards (J) Appln No.2/2014 Page 5 discharged by automobiles, any vehicles or machinery in the atmosphere.
5. The Applicant further submits that the Central Govt. in MoEF i.e. the Respondent No.1, has framed the Environment (Protection) Rules, specifying the noise limits for automobiles with effect from 31st December, 1993, subsequently amended on 30.12.2002 as under;
A. Noise Limits for Automobiles [(Free Field Distance at 7.5 Metre) in dB (A) at the manufacturing stage (a) Motorcycles, Scooters &Three wheelers 80 (b) Passenger Cars 82
(c) Passenger or Commercial vehicles up to 4 MT 85
(d) Passenger or Commercial vehicles above 4 MT and up to 12 MT 89
(e) Passenger or Commercial vehicles exceeding 12 MT 91 [AA. Noise limits for vehicles at manufacturing stage. The test method to be followed shall be IS:3028-1998 Noise limits for vehicles applicable at manufacturing stage from the year 2003.
Sr. Noise Date of Type of vehicle No. Limits dB (A) implementation (I) (2) (3) (4) I. Two wheeler Displacement up to 80 cm3 75 I st January. Displacement more than 80 cm) but 77 2003 up to 175 cm1 more than 175 cm3 Displacement 80 2. Three wheeler Displacement up to J 75 cm3 77 lst January. Displacement more than 175 cmJ 80 2003 3. Passenger car 75 1st January. 2003 4. Passenger or commercial vehicles Gross vehicle weight upto 4 tonnes 80 Gross vehicle weight more than 4 83 I st July. 2003 tonnes but uptO Gross vehicle 12 tonnes weight more than 12 85 tonnes
(2) Noise limits for vehicles at manufacturing stage applicable on and from 1st April, 2005.
(J) Appln No.2/2014 Page 6 Sr. Type of vehicle Noise limits No. dB(A} 1.0 Two wheelers 1.I Displacement upto 80 cc 75 1.2 Displacement more than 80 cc but upto 175 cc 77 1.3 Displacement more than 175 cc 80 2.0 Three wheelers 2.1 Displacement up to 175 cc 77 2.2 Displacement more than 175 cc 80
Vehicles used for the carriage of passengers and 3.0 capable of having not more than nine seats including the 74 driver's seat 4.0 Vehicles used for the carriage of passengers having Than nine seats, more than including the driver's seat, and a maximum Gross nine seats, Vehicle Weight (GVW) of more than 3.5 tonnes 4.1 With an engine power less than 150 KW 78 V 4.2 With an engine power of 150 KW or above 80 5.0 Vehicles used for the carriage of passengers having including more thanthe driver's nine seats,seat: vehicles used for the carriage of goods 5.1 With 8 maximum GVW not exceeding 2 tonnes 76 [Provided that for vehicles mentioned at Serial Numbers 3.0 to 6.3. the noise limits for the following States shall be applicable on and from the date specified against that State.-
(I) Himachal Pradesh with effect from 1st October. 2005 (II) Jammu and Kashmir with effect from 1stOctober. 2005. (III) Madhya Pradesh with effect from 1st September. 2005. (IV) Punjab with effect from 1stOctober, 2005. (V) Rajasthan with effect from 1st June. 2005. (VI) Uttar Pradesh (Mathura, Kannauj. Muzaffarnagar, Aligarh, Farukhabad, Saharanpur. Badaun, Barreily. Moradabad, Hathras, Rampur. Bijnor. Agra, Pilibhit, J.P. Nagar, Mainpuri, Lalitpur, Hardoi, Ferozabad. Jhansi, Shahjahanpur, Etawah, Jalon, LakhimpurKhcri, Etah, Mahoba and Sitapur) with effect from 1stJune, 2005.
(VII) Uttaranchal with effect from 1st July. 2005.]
6. The Applicant submits that on 14th October, 1988, the Motor Vehicles Act relating to the Motor Vehicles was enacted, followed by the Central Motor Vehicles Rules, (CMVR) 1989. The Applicant submits that somewhere in 1988, a Committee constituted by the Indian Standard of Institutes (ISI), approved and specified IS: 3028-1988, in respect of method of (J) Appln No.2/2014 Page 7 measurement of external noise emitted by the moving vehicles. The Applicant pleads that the Committee had no representation of the environmental regulating agencies, namely; the Respondent Nos.1, 3 and 4 and said standards have been updated from time to time. He further submits that the said test procedure has neither been approved nor prescribed under the provisions of Air Act by Respondent 3 and 4, who are the competent authorities for the measurement and monitoring of air pollutants. The Applicant further submits that Sub Rule (2) of Rule 120 of Motor Vehicle Rules, has been amended vide GSR III (e) dated 10thFebruary, 2004 for the noise standards, as under:
" 120.
1. xxxx xxxx xxxx xxx xxxx
2. Noise Standards- every motor vehicle shall be constructed and maintained, so as to conform to the noise standards specified in part E of the Schedule VI, of the Environment (Protection) Rules, 1986, when tested as per IS: 3028: 1988, as amended from time to time."
7. The main contention of the Applicant is that the said IS: 3028-1988, while specifying the measurement of sound from moving vehicle at a distance of 7.5 meters from the vehicle, did not provide for compensation/adjustment of noise levels due to distance from source i.e. the vehicle and therefore, it is contention of the Applicant that IS:3028-1988 is in violation of the provisions of the Air (Prevention and Control (J) Appln No.2/2014 Page 8 of Pollution) Act, 1981 and the Environment (Protection) Rules, 1986 and Noise Pollution (Regulation and Control) Rules, 2000.
8. Applicant further submits that when inquired through RTI, the Respondent No.2 has not provided any information on monitoring and implementation of such standards for noise limits for automobiles at manufacturing stage. However, the Applicant claims to be separately following the matter through the provisions of RTI Act. The Applicant further submits that he also sought the information from Respondent No.5, as to whether the Respondent No.5 is conducting tests of automobiles in terms of Rule 120, Sub- Rule (2) of the Central Motor Vehicles Rules, 1989 for checking noise limits for automobiles at the manufacturing stage. The Applicants submits that the Respondent No.5, vide communication dated 2nd December, 2013, informed that the Respondent No.5, is not conducting such tests and the same is out of scope and purview of the Respondent No.5. The Applicant, therefore, submits that neither the Respondent Nos.1 and 2, nor any of its approved organizations are conducting tests on automobiles for ensuring the noise levels are maintained within levels specified in Rule 120, Sub Rule (2) of the Central Motor Vehicles Rules, 1989. Moreover, in absence of any guidelines given to the Central and the State Boards, i.e. the (J) Appln No.2/2014 Page 9 Respondent Nos.3 and 4, by the Respondent No.1, for enforcing the standards specified under Part-E of Schedule VI of Part of the Environment (Protection) Rules, 1986, these Respondents Nos.3 and 4 are neither monitoring nor controlling the noise limits for automobiles at the manufacturing stage, as specified under the said Rules. The Applicant relied on following citations:
1. Om Birangana Relligious Society vs State &Ors 1996 (100) CAL WN 617,
2. P.A.Jacobvs The Superintendent of Police Kottayam and Anr (AIR 1993 KERALA)
3. Yashwant Trimbak Oke & Ors vs State of Maharashtra, AIR (1998) BOM 121
4. Noise Pollution (v) in Re (2005) 5 SCC 733
5. Enviro-Legal vs Union of India & Ors JT 1996 (4) 263
9. The Applicant further prays that:
(i) Directing that the Respondent No.1 give guidelines to Respondents Nos. 3 and 4 and also the other State Boards for monitoring and enforcing the standards for automobile Noise as more particularly specified under Part E of Schedule VI of the Environment (Protection) Rules, 1986;
(ii) Directing that the Respondent No.1 amends IS:3028-
1998 in order to comply with the provisions of the Air (Prevention and Control of Pollution) Act, Environment (Protection) Act and the Noise Pollution (Regulation and Control) Rules (2000);
(iii) Directing that no new vehicle should be allowed to ply with in excess of the stipulated standards;
(iv) Directing that the Respondent Nos.2,5,6, and 7 do submit a time bound schedule for approval of this Hon'ble Tribunal, so as to ensure that the Noise levels on existing vehicles comply with the standards as more particularly specified under Part E of (J) Appln No.2/2014 Page 10 Schedule VI of the Environment (Protection) Rules, 1986;
(v) Pass any such other or further order as this Hon'ble Tribunal may deem fit and proper in the facts and circumstances of the case.
10. The Respondent No.1, Ministry of Environment and Forests (MoEF), Govt. of India, filed the affidavit in March, 2014, through Mr. R.N.Jindal, Addl. Director. The Respondent No.1 submits that the revised noise limits for automobiles at the manufacturing stage have been identified by the Respondent No.1, vide the Notification dated 5th May, 2005, as Sr. No.46, under the Schedule I of the Environment (Protection) Rules, 1986. The Respondent No.1 submits that these noise limits are implemented under the Central Motor Vehicles Rules, 1989, by the Respondent No.2, i.e. the Ministry of Road Transport and Highways (MoRTH) Govt of India. The Respondent No.1, further submits that testing method to seek compliance of above noise limits for automobiles, has been published by the Bureau of Indian Standards (BIS) i.e. IS: 3028-1988, as amended up to date. The Respondent No.1, therefore, submits that no separate guidelines are required to be issued by the Respondent No.1, in the matter. The Respondent No.1, submits that the Law in terms of Environment (Protection) Rules, is addressing source specific standards under the Schedule I and Schedule VI (Part-E), whereas, the Noise Pollution (Regulation and Control) Rules, 2000, addresses ambient noise quality (J) Appln No.2/2014 Page 11 standards for various areas/zones. The Respondent No.1, therefore, pleads that no action is pending on the part of the Respondent No.1 and therefore, the Application is not maintainable against this Respondent.
11. However, when the matter was heard on 2nd July, 2014, various submissions contained in this affidavit were contested by the Applicant and considering deliberation, the Respondent No.1, was directed to submit the affidavit in clarification, as to under what provisions the implementing agencies are given powers and legal authorities under the Environment (Protection) Act, 1986, to be exercised by the Respondent No.2 for implementation of the relevant rules, indicated under the Environment (Protection) Rules, 1986. During final hearing the learned Counsel for the Respondent No.1 argued that they standby to the contentions shown in of the affidavit filed earlier and also submits that as per the Section 24 of the Environment (Protection) Act, 1986, effect of other Laws are well definition as per Section 24 (2), where any act or omission constitutes an offence punishable this Act, and also under any other Act, will be applicable and any offender found to be guilty of such offence, shall be liable for punishment under the relevant Act and not under this Act.
12. The Respondent No.2, has not filed any separate affidavit, though it was represented by the Counsel. Learned Advocate Sh. K.D. Ratnaparkhi, appearing for the Respondent (J) Appln No.2/2014 Page 12 No.2, submitted that he has instructions to submit that the Respondent No.2, is not filing any affidavit as there are no averments against the Respondent No.2, no relief is claimed in the prayers of the Application, as against the Respondent No.2.
13. The Respondent No.3, i.e. Central Pollution Control Board (CPCB), filed an affidavit on 10th February, 2014, through Sh. B.R. Naidu, Scientist-E. The Respondent No.2, submits that State Pollution Control Board, is the authority to prescribe standards under Section 17 (1) (g) of the Air (Prevention and Control of Pollution) Act, 1981. The Respondent No.3, further submits that the Respondent No.2, MoRTH, is regulating vehicle noise at the manufacturing stage through seven (7) Agencies mentioned at Rule-126 of the Central Motor Vehicles Rules, 1989 (CMVR). A copy of one such Type Approval given by such identified agency for both pass by noise and component level noise was also submitted along with the affidavit.
14. The Respondent No.4, filed affidavit through Shri. V.M. Motghare, Joint Director, on 5th March, 2014. The Respondent No.4, submits that as per the Maharashtra Govt. Resolution dated 21st April, 2009, the Home Department (Transport) is the Authority declared for enforcement and maintenance of noise standards laid down under the Motor Vehicles Act,1989, for a new and operating vehicle within (J) Appln No.2/2014 Page 13 their respective jurisdiction, as per entry No.8, of the Schedule of notification mentioning the notified Authorities, which is reproduced :
8 (i) Any officer form the state Home Enforcement and transport Department/Deputy Department maintenance of the Regional Transport officer in (Transport) noise standards laid their respective jurisdiction not down under Environment below the rank of Deputy Superintendent of Police (Protection) Rules, 1986
(ii) Head of Maharashtra State and Motor Vehicles Act, Road Transport Corporation or 1989 for the new an any officer/Depot Manager not operating vehicles within below the rank of the Deputy their respective Superintendent of Police. jurisdiction.
(iii) Traffic Police Authorities not below the rank of the Deputy The noise levels Superintendent of Police.
granted by the in-use vehicles should be monitored while grant of Pollution Under Control Certificate.
15. The Respondent No.4, further submits that it is appropriate that instead of creating separate authority with regard to the vehicles only for limited purpose of noise, the Transport Department which regulates the majority of issues related to vehicles performs this duty too.
16. The Respondent No.5 i.e. the Automotive Research Association of India (ARAI), Pune filed an affidavit on 2nd April, 2014. The Respondent No.5 submits that it is one of six (6) testing and certifying Agencies authorized by the Central Government, under Rule 126 of the Central Motor Vehicles Rules, 1989. The Respondent No.5 submits that the vehicle manufacturers have to submit their product type for type approval to any of the six Agencies mentioned in Rule 126 of (J) Appln No.2/2014 Page 14 the Central Motor Vehicles Rules, 1989. Further, Automotive Industry Standard Committee (AISC) is constituted by the MoRTH, Govt. of India for preparation of standards and review of the existing standards and the Respondent No.5, only publishes these standards on its website for information of all the concerned. The Respondent No.5, submits that the Respondent No.5, tests and certifies the vehicle as per the Law and the standards applicable for type of vehicle. The Respondent No.5, submits that actual decibel level of the vehicle is a part of test report and the test report contains proprietary information such as design - dimensions, material characteristic etc. of all the vehicle systems, which are intellectual property of the manufacturer concerned. The Respondent No.5, submits that in the light of above and also objections raised by the several vehicle manufacturers regarding disclosure of test reports, test report cannot be disclosed as it is third party information and, therefore, the Applicant was refused all this information. This issue was deliberated upon during hearing dated 21st April, 2014, when Advocate for Respondent No.5, showed willingness to place relevant file for perusal of the Tribunal and accordingly, copy of one such Type approval for grant of test certificate was placed on record.
17. The Respondent No.7 i.e. Transport Commissioner, Govt. of Maharashtra filed the affidavit through Sh.Y.K. Bag, (J) Appln No.2/2014 Page 15 Assistant RTO, Pune. The Respondent No.7 submits that the Transport Commissioner, Govt. of Maharashtra, i.e the Respondent No.7, is responsible to give effect to the provisions of the Motor Vehicles Act and the Rules made there-under for the State of Maharashtra. The Respondent No.7 further submits that registration of the motor vehicle is made by the Registering Authority only after verifying that the certificate of compliance has been issued by the Testing Agencies, as prescribed under Rule 126 of the CMVR, 1989, which includes compliance with maximum permissible noise levels for horns, engines and silencers at the time of registration of vehicles. The Respondent No.7 submits that as per Rule 126
(a) of the CMVR, it is duty of the testing agencies to conduct a test on vehicles drawn from production line of the manufacturer to verify whether these vehicles confirm to the provisions of regulations. Further, as per Rule 127 of CMVR, it is mandatory on the manufacturer that sale of every motor vehicle manufactured shall be accompanied by the certificate of roadworthiness issued by the manufacturer in the form No.22 and, therefore, the Respondent No.7 pleads that they do not have any role or control on monitoring noise levels at the manufacturing stage.
18. Considering the pleadings and documents available on record and arguments advanced by learned Counsel for (J) Appln No.2/2014 Page 16 the parties, following issues emerge for effective adjudication of the present Application.
i) Whether there is a mechanism for enforcing the noise related standards for automobiles as prescribed under Environmental (Protection) Rules?
ii) Whether there is necessity for amending IS:
3028-1998 to comply with the provisions of Air (Prevention and Control of Pollution) Act, 1981 and the Environment (Protection) Act, 1986 and the Rules made thereunder?
iii) Whether present enforcement of noise related standards for automobiles require specific directions from the Tribunal?
19. Before entering into the arena of above issues, we would like to lay emphasis on fact that increasing noise levels in the urban areas, is posing a serious threat to health of the people in general and especially to the children and old, in particular. The Hon'ble Supreme Court and various High Courts, have time and again emphasized the need to control noise pollution and we do not wish to reproduce all such catena of Judgments, as importance of maintaining noise levels within urban areas was generally agreed by the learned Counsel appearing in the present Application too. It is also an admitted fact that automobiles, due to its engine (auto mechanism) noise and also, noise generated by blowing of horns contribute significantly to ambient noise levels in urban areas. Needless to say that various reports available in the public domain, record that ambient noise levels in most of the (J) Appln No.2/2014 Page 17 urban areas in the country are exceeding the ambient noise level standards as set out in the Noise Pollution (Regulation and Control) Rules, 2000.
20. Noise pollution is a significant environmental problem in many urban areas. This problem has not been adequately addressed and remedied despite the fact that it is growing in developing countries. This widespread non- recognition of noise pollution problem, in a similar fashion as to air and water pollution problems, could be attributed to reasons such as; by the definition and perception of noise as a subjective experience, short decay time, and difficulty to associate cause with effect when it comes to health impacts. Depending on its duration and volume, the effects of noise on human health and comfort are divided into four categories; physical effects, such as hearing defects; physiological effects, such as increased blood pressure, irregularity of heart rhythms and ulcers; psychological effects, such as disorders, sleeplessness and going to sleep late, irritability and stress; and finally effects on work performance, such as reduction of productivity and misunderstanding what is heard.
21. The present Application raises a substantial issue of implementation of noise standards of automobiles as defined under Environment Protection Rules. We have noted that Govt. of India has already notified such standards under the provisions of Environment (Protection) Rules, 1986, Part-
(J) Appln No.2/2014 Page 18 E. These standards have two phases of implementation of noise limits, for vehicles at manufacturing stage: (1) for the vehicles manufactures from 2003 and (2) for the vehicles manufactured from 1st April, 2005. The standards also stipulate that test method to be followed for enforcing such noise limits, shall be IS: 3028-1998. These standards are mentioned in paragraphs (5) and (6), as shown herein above.
22. It is grievance of the Applicant that though such standards are in place since year 2002, however, the MoEF has not issued any guidelines for enforcing such standards, nor have delegated any powers for enforcement of these standards to the any local authority. The MoEF has countered such arguments by stating that revised noise limits for automobiles at the manufacturing stage, have been identified by the MoEF vide Notification dated 5.5.2005. However, MoEF mentions that these noise limits were notified at Sr.No.46, under Schedule-I of the Environment (Protection) Rules, 1986, are within Part-E of Schedule-VI. The MoEF further contends that these noise limits are implemented under the Central Motor Vehicles Rules, 1989, by the Respondent No.2 i.e. MoRTH. In order to get clarity on the issue, , we directed the MoEF, vide order dated July 2nd, 2014, to clarify as to under what provisions, such implementing agencies, are given powers and authority under the Environment (Protection) Act, 1986, to be exercised by the Respondent No.2, for (J) Appln No.2/2014 Page 19 implementation of relevant Rules. The order dated July 2nd, 2014, is reproduced here for clarity:
"Heard the Applicant in person.
The affidavit of MoEF, is silent as regards the manner in which the standards notified by the MoEF, can be properly implemented and that what is the mechanism to ensure that violations are to be dealt with. It is stated in paragraph 3 of the reply affidavit that noise limits were notified at Sr. No.46, under the Schedule-I, of the Environment (Protection) Rules, 1986, rather than part-E of the Schedule-VI. It is vaguely stated that these noises are implemented under the Central Motor Vehicles Rules, 1989, by the Respondent No.2. However, it needs clarification as to under what provisions, the implementing Agencies are given powers and legal authority under the Environment (Protection) Act, 1986 to be exercised by the Respondent No.2, for implementation of the relevant Rules, indicated under the Environment (Protection) Rules. It appears prima facie that the MoEF, has made the Rules, the implementing machinery is the local authority i.e. RTO, and it is stated that implementation has to be done under the Central Motor Vehicles Rules, 1989. The Respondent No.1, may file additional affidavit in this behalf. The Counsel seeks time to clarify the position. The Automotive Research Association of India (ARAI) also shall bring the relevant files for perusal of the Tribunal on the same day, inasmuch as today when called, the representative is absent.
Stand over to 28th July 2014. "
23. We have taken a note that in spite of such assurance, MoEF did file its response only on 30/8/2014. MoEF has reiterated the stand taken earlier and submits that the Central Govt. has laid down the Central Motor Vehicles Reles,1989 and the Rule 120(2),stipulates that the every motor vehicle shall be constructed and maintained so as to (J) Appln No.2/2014 Page 20 conform to the noise standards specified in Part E, of Schedule VI, to the Environment (Protection) Rules, 1986, when tested as per IS: 3028 -1998, as amended from time to time. It is the stand of MoEF that as these standards have been incorporated in the Motor Vehicles Rules, under Section 24 of the Environment (Protection) Act, 1986, any violation in respect of noise standards, stipulated under the Central Motor vehicles Rules, is punishable under the Motor Vehicles Act, 1988.
24. The Motor vehicle rule 120 prescribes the noise standards for automobiles at manufacturing stage and are as under:
120. (1) xxx xxx xxxx xxxx (2) Noise standards--Every motor vehicle shall be constructed and maintained so as to conform to noise standards specified in Part E of the Schedule VI to the Environment (Protection) Rules, 1986, when tested as per IS: 3028-1998, as amended from time to time. Similarly, Section 126 of the Central Motor Vehicles Rules, stipulate the requirement that prototype every motor vehicle to be subjected to test. The Rule is reproduced below:
126. Prototype of every motor vehicle to be subject to test--- On and from the date of 'Commencement' of Central Motor Vehicles (Amendment) Rules 1993, every [manufacturer or importer] of motor vehicles other than trailers and semi-trailers shall submit the prototype of the vehicle [to be manufactured or imported by him] for test by the Vehicle Research and Development Establishment of the Ministry of Defence of the Government of India or Automotive Research Association of India, Pune, [or the, Central Farm Machinery Testing and Training Institute, Budni (MP)] or the Indian Institute of Petroleum, Dehradun, [or the Central Institute of Road Transport, Pune, or the International Centre, for Automotive Technology. Manesar,] [or the Northern. Region Farm Machinery Training and Testing Institute, Hissar (for (J) Appln No.2/2014 Page 21 testing of combine harvester)] and such other agencies as may be specified by the Central Government or granting a certificate by that agency as to the compliance of provisions of the Act and these rules:
[Provided that the procedure for type approval and certification of motor vehicles of compliance to these rules shall be in accordance with the AIS; 017-2000, as amended from time to time:] [Provided further that in respect to the vehicles imported into India as completely built units (CBU), the importer shall submit a vehicle of that particular model and type to the testing agencies for granting a certificate by that agency as to the compliance to the provision of the Act and these rules.] [126A. The testing agencies referred to in rule 126 shall in accordance with the procedures laid down by the Central Government also conduct tests on vehicles drawn from the production line of the manufacturer to verify whether these vehicles conform to the provisions of [rules made under section 110 of the Act]:] [Provided that in case the number of vehicles sold in India for a given base model and its variants (manufactured in India or imported to India) are less than 250 in any consecutive period of six months in a year, then such base model and its variants need not be subjected to the above test, if at least one model or its variants manufactured or imported by that manufacturer or importer, as the case may be, is subjected to such tests at least once in a year:
Provided further that, in case the number of base models and its variants manufactured/imported is more than one and if the individual base model and its variants are less than 250 in any consecutive period of six months in a year, then the testing agencies can pick up one of the vehicle out of such models and their variants once in a year for carrying out such test.]
25. We have also perused the affidavit of Respondent No.5 and the Rule 120,126 and 127 of Motor Vehicle Rules. Rule 120(2) sets out noise standards for automobiles at manufacturing and operating stage to be measured as per IS: 3028-1998. Rule 126 prescribes Type Approval to be granted by any of the six identified agencies, but the interesting part (J) Appln No.2/2014 Page 22 is that the procedure given for such Type approval is AIS:017- 2000, and does not refer to IS-3028-1998. It is therefore not clear whether such type approval includes any verification of compliance of the noise standards as specified in Rule 120 (2) of the said rules, which have adopted the noise standards prescribed under the Environmental protection Rules. This aspect of implementation of such noise standards further gets more clarified by the response of Respondent-5 to RTI query dated 2/12/2013, related monitoring of standards prescribed in rule 120 (2) of the MVR. The response clearly says that conducting the test as per noise standards specified in rule 120(2) at the stage of manufacturing is out of scope and purview of the institute.
26. The provisions of Rule 120 of the Central Motor Vehicles Rules, 1989 are very specific as standards specified under the Environment (Protection) Rules, 1986 have been adopted for every motor vehicle at construction stage and also while it is put to use. Therefore it is necessary that compliance of such standards, need to be independently verified and assessed by the concern agencies while granting Certificate of Test, under the Rule 126 of the Central Motor Vehicles Rules, 1989. It is necessary that the provisions of IS: 3028-1998, shall be strictly adhered to while testing noise limits from the automobiles. This is very important, as we have directed the Respondent No.5 (ARAI) to file copies of (J) Appln No.2/2014 Page 23 such certificate and on perusal of certificate granted to Ashok Leyland dated 29th May, 2013, what we found is that there is total absence of mention of vehicle noise as monitored under IS: 3028-1998. We have also perused the copy of such certificate produced by the CPCB along with affidavit, where one certificate issued to M/s Umbrella Corporation and in the said certificate, noise level measurement has been made as per IS: 3028-1998, though measurement parameters are different than as specified in the standard for RPM and also speed.
27. The above submissions clearly shows that there is absence of well-defined mechanism to implement and enforce the noise standards prescribed for automobiles at manufacturing stage, though they have been prescribed under Environmental (Protection) rules, and have also been incorporated under rule 120(2) of the Motor Vehicle rules, 1989. In our opinion, all the concerned agencies are tossing the responsibility on other agencies, with the result, the prescribed noise standards are not being implemented resulting in unabated noise pollution. And, therefore, we record our finding on Issue-I in NEGATIVE.
28. We have also gone through the contents of BIS standards IS: 3028-1998 and the revisions made from time to time. It is found that the standards give elaborate technical procedure and methodologies for measurements of noise from (J) Appln No.2/2014 Page 24 the automobiles. As these standards are evolved by the Committee of Experts, we do not wish to enter into arena of evaluating the correctness or otherwise, of the standards. However, we would like to appreciate the point raised by the Applicant that as these standards deal with the noise standards, it will be prudent to include the Environment Regulatory Authorities like CPCB or SPCB, which are also technical organizations, on such Committee for review and to ensure that environmental regulations are holistically considered while revising such standards. It is also open for MoEF/CPCB/SPCB to prepare their own test procedure for measurement of noise form automobiles, if required. The Issue (2) is accordingly answered in NEGATIVE, with above suggestion.
29. In the absence of an effective mechanism to enforce and implement the Noise standards prescribed under the EP Rules and Motor Vehicles Rules, the noise pollution mainly in urban areas cannot be effectively controlled. Hon'ble Apex Court and High Court decisions referred by Applicant in the Application have given significant impetus to the implementation of noise related regulations. The Apex Court in WP (c) No.72 of 1998 with CA No.3735 of 2005 (arising out of SLP (c) No.2185) (2005) 5 SCC 733 in "Re: Noise Pollution vs Unknown 18 July, 2005" observed that:
(J) Appln No.2/2014 Page 25 "98. Not that the Legislature and the Executive in India are completely unmindful of the menace of noise pollution. Laws have been enacted and the Rules have been framed by the Executive for carrying on the purposes of the legislation. The real issue is with the implementation of the laws. What is needed is the will to implement the laws. It would be useful to have a brief resume of some of the laws which are already available on the Statute Book. Treatment of the problem of noise pollution can be dealt under the Law of Crimes and Civil Law. Civil law can be divided under two heads (i) The Law of Torts and (ii) The General Civil Law. The cases regarding noise have not come before the law courts in large quantity. The reason behind this is that many people in India did not consider noise as a sort of pollution and they are not very much conscious about the evil consequences of noise pollution. The level of noise pollution is relative and depends upon a person and a particular place. The law will not take care of a super sensitive person but the standard is of an average and rational human being in the society."
32.
31.
30.
33. The Apex Court further observed that:
"How to check/control noise pollution
169. The need for checking noise pollution as highlighted by the petitioners and several interveners deserves appreciation.
170. Need for specific legislation to control and prevent noise pollution still needs some emphasis. Undoubtedly, some laws have been enacted. Yet, compared with the legislation in developed countries India is still lagging behind in enacting adequate and scientific legislations. We need to have one simple but specific and detailed legislation dealing with several aspects referable to noise pollution and providing measures of control therefore.
171. There is an equal need of developing mechanism and infrastructure for enforcement of the prevalent laws. Those who are entrusted with the task of enforcing laws directed towards controlling noise pollution, must be so trained as to acquire expertize in the matter of fighting against noise pollution by taking preventive and deterrent measures both. They need to be equipped with the requisite equipments such as audio meters as would help them in detecting the level of noise (J) Appln No.2/2014 Page 26 pollution more so when it crosses the permissible limits and the source thereof.
172. Above all, there is need for creating general awareness towards the hazardous effects of noise pollution....."
30. In substance, it can be observed that there is no effective mechanism for implementation of noise standards for automobiles. Though the Respondents have taken some steps, but they are pointing fingers towards others in the context of duty to perform the Rules. There is lack of synergy and coordination amongst the Respondents. This cannot be allowed to continue, in view of the serious impacts of noise pollution. The Apex court has clearly focused on implementation of existing regulations and also, need of specific regulations while dealing with noise pollution. In para 95 of the above referred Judgment, the Apex court has referred to The Noise Control (Motor Vehicles and Motor Vehicle Accessories) Regulation 1995. This regulation seems to be of New South Wales of Australia which is a comprehensive regulation for noise pollution control from automobile. The Regulation makes provisions for the following matters:
(a) the maximum noise levels in relation to certain classes of motor vehicles and motor vehicle accessories, such that vehicles and accessories capable of emitting those noise levels cannot be sold,
(b) the use of motor vehicles on roads and other places, (J) Appln No.2/2014 Page 27
(c) the use of motor vehicle horns and motor vehicle intruder alarms,
(d) the times during which it is not permissible to use certain motor vehicles if they emit noise that can be heard in other residential premises,
(e) the sounding of sirens and similar devices on vessels,
(f) the emission of noise from the engines or exhausts of vessels,
(g) the times during which it is not permissible to use certain sound systems on vessels if they emit noise that can be heard in any residential premises,
(h) the maintenance of noise control equipment on motor vehicles and vessels,
(i) the issue of defective vehicle notices and defective vessel notices
31. While dealing with local level implementation of such standards, the Learned Counsel for MPCB, invites our attention towards the GR of Govt. of Maharashtra dated 21st April, 2009, which has outlined a scheme of enforcement of various noise related standards and regulations and have identified authorities for implementation of such standards/regulations. Paragraph 8 of Annexure attached to the said GR is reproduced below:
8 (iv) Any officer form the state Home Enforcement and transport Department/Deputy Department maintenance of the Regional Transport officer in (Transport) noise standards laid their respective jurisdiction not down under Environment below the rank of Deputy Superintendent of Police (Protection) Rules, 1986
(v) Head of Maharashtra State and Motor Vehicles Act, Road Transport Corporation or 1989 for the new an any officer/Depot Manager not operating vehicles within below the rank of the Deputy their respective Superintendent of Police jurisdiction.
(vi) Traffic Police Authorities not below the rank of the Deputy Superintendent of Police.
The noise levels granted by the in-use (J) Appln No.2/2014 Page 28 vehicles should be monitored while grant of Pollution Under Control Certificate. 32. We have gone through the provisions of the Air
(Prevention and Control of Pollution) Act, 1981 and have already observed in M.A.No.202/2013 in Application No.30/2014, that the SPCB, is the Competent Authority for prescribing the noise standards under Section 17 (1) (g) of the Air (Prevention and Control of Pollution) Act, 1981. Section 20 of the said Act, deals with enforcement of standards for emissions under the Automobile, which is as under:
20. Power to give instructions for ensuring standards for emission from automobiles:
with a view to ensure that the standards for emission of air pollutants from automobiles laid down by the State Board under clause (g) of sub-section (1) of Section 17 are complied with, the State Government shall, in consultation with the State Board, give such instructions as may be deemed necessary to the concerned authority in charge of registration of motor vehicles under the Motor Vehicles Act, 1939 (4 of 1939) and such authority shall, notwithstanding anything contained in that Act or the rules made thereunder be bound to comply with such instructions.
33. This particular provision clearly implies that once the standard is prescribed by the State-Board for emission of air pollutants from automobiles under Section 17 (1) (g) of the Air (Prevention and Control of Pollution) Act, 1981, State Govt. is required to give such instructions, on recommendations of SPCBs, as may be deemed necessary to the concerned Authority in-charge of registration of the motor vehicles under the Central Motor Vehicles Act and such Authority shall notwithstanding anything containing in (J) Appln No.2/2014 Page 29 that Act, or Rules made there under be bound to comply with such instructions.
34. Govt. of Maharashtra vide GR dated 21st April, 2009, has directed the Transport Authorities to implement the noise standards identified under the Environment (Protection) Rules, 1986. Though we appreciate the initiatives taken by State of Maharashtra and MPCB, we find that this delegation of powers, is not backed up by provisions of Section 17 and 20 of Air Act, 1981 or other regulations. It is also not clear how the Transport department, i.e. R-7 will implement this provision, as they have already filed affidavit that they just rely on the certificate of road worthiness as contemplated under the MV Rules. What we find is that the Authorities need to consider either prescribing new standards for the vehicle noise in the State under the provisions of Air Act or may even like to adopt the standards specified under the Environment (Protection) Rules, 1986 for the purpose under Section 17 (1)
(g) of the Air (Prevention and Control of Pollution) Act, 1981, and then the State Govt. can direct the Transport Authorities, under Section 20 read with Section 17 (1) (g) of the Air (Prevention and Control of Pollution) Act, 1981, which will enable them with legal powers and empower to implement such directions.
(J) Appln No.2/2014 Page 30
35. Noise pollution is primarily a local (urban area) problem, but one which calls for a state-wide solution. The first step in any sustainable noise emissions policy should be to devise measures to reduce sound levels at source. Since the target of this Regulation is the noise source that motor vehicles represent, and given that that noise source is by definition a mobile one, even state level measures alone are not sufficient. At the national level too, it is necessary that the MoEF, needs to delegate the powers to the Respondent No.2, if so deemed fit or any other Authority, as may be required to enforce their standards. Similarly, Respondent No.3 i.e. which has an overall responsibility to maintain the ambient air quality under the provisions of section 16 (1) of Air Act, besides the supervisory and co-coordinating role as empowered under section 18 of the said Act, needs to take national level initiative. We do not agree with the stand taken by CPCB that SPCBs are solely responsible for setting the standards. The section 16 of Air Act, gives a mandate to CPCB to maintain the desired air quality in the country and empowers it to take all necessary measures for that. Besides this Section 18 gives powers to CPCB to issue specific directions to SPCBs to perform functions as specified in the Act. And therefore, we are of the considered view that CPCB has an important role to play when national level air quality related issues needs to be addressed. It cannot just shirk the (J) Appln No.2/2014 Page 31 responsibility by only selective mention of section 17 (i) (g) of Air Act, while conveniently not addressing the provisions of section 16 read with 18 of the said Act.
36. Public awareness, education and information dissemination related to environmental issues have already been identified as important initiatives by various judgments of Apex court. Apex Court in Writ Petition (C) No. 72 of 1998 with Civil Appeal No. 3735 of 2005 [Arising out of SLP (C) No. 2185 (2005) 5 SCC 733 has issued directions as directed in para 179 of the judgment, issued in exercise of power conferred on Apex Court under Articles 141 and 142 of the Constitution of India, which would remain in force until modified by this Court or superseded by an appropriate legislation, which are as under:
" 1. There is a need for creating general awareness towards the hazardous effects of noise pollution. Suitable chapters may be added in the text-books which teach civic sense to the children and youth at the initial/early level of education. Special talks and lectures be organised in the schools to highlight the menace of noise pollution and the role of the children and younger generation in preventing it. Police and civic administration should be trained to understand the various methods to curb the problem and also the laws on the subject.
2. The State must play an active role in this process. Residents Welfare Associations, Service Clubs and Societies engaged in preventing noise pollution as a part of their projects need to be encouraged and actively involved by the local administration.
3. Special public awareness campaigns in anticipation of festivals, events and ceremonial occasions whereat (J) Appln No.2/2014 Page 32 firecrackers are likely to be used, need to be carried out."
37. The provision of information on sound emissions due to automobile to consumers and public authorities has the potential to influence purchasing decisions and accelerate the transition to a quieter vehicle fleet. Accordingly, we hold that the automobile manufacturers should provide information on sound levels of vehicles at the point of sale and in technical promotional material, providing information to the consumers about the sound emissions of a vehicle and also the horns based on Precautionary Principle. It is also necessary that the certificate of compliance issued under rule 120 (2) or even that of horn/silencer etc. for each type approval shall also be provided to the automobile purchaser and also, the same shall be available on automobile manufacturer's website in public domain, for each prototype of vehicle.
38. In the result, the Application is partly allowed with following directions, as per section 14 read with section 20 of NGT Act, 2010:
i) The MPCB shall notify the noise emission standards for vehicles at manufacturing and in-
use stage within a period of three (3) months in State of Maharashtra, shall thereafter issue necessary directions under Section 20 of the Air (Prevention and Control of Pollution) Act, 1981, to (J) Appln No.2/2014 Page 33 the concerned Authorities for enforcement of such standards within next four (4) months.
ii) Respondent-3 i.e. CPCB shall co-ordinate with other state Boards under the provisions of Section 16 and 18 of the Air (P&CP) Act for notifying the noise standards for automobiles within next six (6) months.
iii) Respondent-2 and 7 shall ensure that no vehicle is registered, till such standards are finalized by Respondents- 3 and 4, without ensuring the strict compliance of the noise standards as specified in Rule 120(2) of Motor vehicle Rules, 1989. A compliance report on this direction shall be filed by R-2 and R-7 within two (2) months.
iv) We direct the Respondent Nos.2 and 7, that certificate of compliance issued by the specified agencies under Rule 120 read with rule 126 of the Central Motor Vehicles Rules, 1989, related to compliance of noise standards for horns, vehicle, etc, as notified, shall be made available along with every vehicles which will be sold in the market henceforth and also, a copy of such certificate for each prototype shall be available on the website of the department. This is very important as a citizen, who is consumer/purchaser of the automobile, is entitled to know the level of pollution caused by the vehicle.
v) These Directions shall be brought to the notice of all concerned transport authorities by Respondent 3 i.e. CPCB and Respondent 4 i.e. MPCB immediately.
(J) Appln No.2/2014 Page 34 The Application is accordingly disposed of. No costs. Considering the nature of directions, the Application is listed for compliances on November 27th, 2014.
....................................................., JM (Justice V. R. Kingaonkar) ...................................................., EM (Dr.Ajay A. Deshpande) Date: September 23rd, 2014 (J) Appln No.2/2014 Page 35


# Copyright 2015,2016,2017 Nir Cohen # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. """ The ``distro`` package (``distro`` stands for Linux Distribution) provides information about the Linux distribution it runs on, such as a reliable machine-readable distro ID, or version information. It is the recommended replacement for Python's original :py:func:`platform.linux_distribution` function, but it provides much more functionality. An alternative implementation became necessary because Python 3.5 deprecated this function, and Python 3.8 will remove it altogether. Its predecessor function :py:func:`platform.dist` was already deprecated since Python 2.6 and will also be removed in Python 3.8. Still, there are many cases in which access to OS distribution information is needed. See `Python issue 1322 <https://bugs.python.org/issue1322>`_ for more information. """ import os import re import sys import json import shlex import logging import argparse import subprocess _UNIXCONFDIR = os.environ.get('UNIXCONFDIR', '/etc') _OS_RELEASE_BASENAME = 'os-release' #: Translation table for normalizing the "ID" attribute defined in os-release #: files, for use by the :func:`distro.id` method. #: #: * Key: Value as defined in the os-release file, translated to lower case, #: with blanks translated to underscores. #: #: * Value: Normalized value. NORMALIZED_OS_ID = { 'ol': 'oracle', # Oracle Enterprise Linux } #: Translation table for normalizing the "Distributor ID" attribute returned by #: the lsb_release command, for use by the :func:`distro.id` method. #: #: * Key: Value as returned by the lsb_release command, translated to lower #: case, with blanks translated to underscores. #: #: * Value: Normalized value. NORMALIZED_LSB_ID = { 'enterpriseenterprise': 'oracle', # Oracle Enterprise Linux 'redhatenterpriseworkstation': 'rhel', # RHEL 6, 7 Workstation 'redhatenterpriseserver': 'rhel', # RHEL 6, 7 Server } #: Translation table for normalizing the distro ID derived from the file name #: of distro release files, for use by the :func:`distro.id` method. #: #: * Key: Value as derived from the file name of a distro release file, #: translated to lower case, with blanks translated to underscores. #: #: * Value: Normalized value. NORMALIZED_DISTRO_ID = { 'redhat': 'rhel', # RHEL 6.x, 7.x } # Pattern for content of distro release file (reversed) _DISTRO_RELEASE_CONTENT_REVERSED_PATTERN = re.compile( r'(?:[^)]*\)(.*)\()? *(?:STL )?([\d.+\-a-z]*\d) *(?:esaeler *)?(.+)') # Pattern for base file name of distro release file _DISTRO_RELEASE_BASENAME_PATTERN = re.compile( r'(\w+)[-_](release|version)$') # Base file names to be ignored when searching for distro release file _DISTRO_RELEASE_IGNORE_BASENAMES = ( 'debian_version', 'lsb-release', 'oem-release', _OS_RELEASE_BASENAME, 'system-release' ) def linux_distribution(full_distribution_name=True): """ Return information about the current OS distribution as a tuple ``(id_name, version, codename)`` with items as follows: * ``id_name``: If *full_distribution_name* is false, the result of :func:`distro.id`. Otherwise, the result of :func:`distro.name`. * ``version``: The result of :func:`distro.version`. * ``codename``: The result of :func:`distro.codename`. The interface of this function is compatible with the original :py:func:`platform.linux_distribution` function, supporting a subset of its parameters. The data it returns may not exactly be the same, because it uses more data sources than the original function, and that may lead to different data if the OS distribution is not consistent across multiple data sources it provides (there are indeed such distributions ...). Another reason for differences is the fact that the :func:`distro.id` method normalizes the distro ID string to a reliable machine-readable value for a number of popular OS distributions. """ return _distro.linux_distribution(full_distribution_name) def id(): """ Return the distro ID of the current distribution, as a machine-readable string. For a number of OS distributions, the returned distro ID value is *reliable*, in the sense that it is documented and that it does not change across releases of the distribution. This package maintains the following reliable distro ID values: ============== ========================================= Distro ID Distribution ============== ========================================= "ubuntu" Ubuntu "debian" Debian "rhel" RedHat Enterprise Linux "centos" CentOS "fedora" Fedora "sles" SUSE Linux Enterprise Server "opensuse" openSUSE "amazon" Amazon Linux "arch" Arch Linux "cloudlinux" CloudLinux OS "exherbo" Exherbo Linux "gentoo" GenToo Linux "ibm_powerkvm" IBM PowerKVM "kvmibm" KVM for IBM z Systems "linuxmint" Linux Mint "mageia" Mageia "mandriva" Mandriva Linux "parallels" Parallels "pidora" Pidora "raspbian" Raspbian "oracle" Oracle Linux (and Oracle Enterprise Linux) "scientific" Scientific Linux "slackware" Slackware "xenserver" XenServer "openbsd" OpenBSD "netbsd" NetBSD "freebsd" FreeBSD ============== ========================================= If you have a need to get distros for reliable IDs added into this set, or if you find that the :func:`distro.id` function returns a different distro ID for one of the listed distros, please create an issue in the `distro issue tracker`_. **Lookup hierarchy and transformations:** First, the ID is obtained from the following sources, in the specified order. The first available and non-empty value is used: * the value of the "ID" attribute of the os-release file, * the value of the "Distributor ID" attribute returned by the lsb_release command, * the first part of the file name of the distro release file, The so determined ID value then passes the following transformations, before it is returned by this method: * it is translated to lower case, * blanks (which should not be there anyway) are translated to underscores, * a normalization of the ID is performed, based upon `normalization tables`_. The purpose of this normalization is to ensure that the ID is as reliable as possible, even across incompatible changes in the OS distributions. A common reason for an incompatible change is the addition of an os-release file, or the addition of the lsb_release command, with ID values that differ from what was previously determined from the distro release file name. """ return _distro.id() def name(pretty=False): """ Return the name of the current OS distribution, as a human-readable string. If *pretty* is false, the name is returned without version or codename. (e.g. "CentOS Linux") If *pretty* is true, the version and codename are appended. (e.g. "CentOS Linux 7.1.1503 (Core)") **Lookup hierarchy:** The name is obtained from the following sources, in the specified order. The first available and non-empty value is used: * If *pretty* is false: - the value of the "NAME" attribute of the os-release file, - the value of the "Distributor ID" attribute returned by the lsb_release command, - the value of the "<name>" field of the distro release file. * If *pretty* is true: - the value of the "PRETTY_NAME" attribute of the os-release file, - the value of the "Description" attribute returned by the lsb_release command, - the value of the "<name>" field of the distro release file, appended with the value of the pretty version ("<version_id>" and "<codename>" fields) of the distro release file, if available. """ return _distro.name(pretty) def version(pretty=False, best=False): """ Return the version of the current OS distribution, as a human-readable string. If *pretty* is false, the version is returned without codename (e.g. "7.0"). If *pretty* is true, the codename in parenthesis is appended, if the codename is non-empty (e.g. "7.0 (Maipo)"). Some distributions provide version numbers with different precisions in the different sources of distribution information. Examining the different sources in a fixed priority order does not always yield the most precise version (e.g. for Debian 8.2, or CentOS 7.1). The *best* parameter can be used to control the approach for the returned version: If *best* is false, the first non-empty version number in priority order of the examined sources is returned. If *best* is true, the most precise version number out of all examined sources is returned. **Lookup hierarchy:** In all cases, the version number is obtained from the following sources. If *best* is false, this order represents the priority order: * the value of the "VERSION_ID" attribute of the os-release file, * the value of the "Release" attribute returned by the lsb_release command, * the version number parsed from the "<version_id>" field of the first line of the distro release file, * the version number parsed from the "PRETTY_NAME" attribute of the os-release file, if it follows the format of the distro release files. * the version number parsed from the "Description" attribute returned by the lsb_release command, if it follows the format of the distro release files. """ return _distro.version(pretty, best) def version_parts(best=False): """ Return the version of the current OS distribution as a tuple ``(major, minor, build_number)`` with items as follows: * ``major``: The result of :func:`distro.major_version`. * ``minor``: The result of :func:`distro.minor_version`. * ``build_number``: The result of :func:`distro.build_number`. For a description of the *best* parameter, see the :func:`distro.version` method. """ return _distro.version_parts(best) def major_version(best=False): """ Return the major version of the current OS distribution, as a string, if provided. Otherwise, the empty string is returned. The major version is the first part of the dot-separated version string. For a description of the *best* parameter, see the :func:`distro.version` method. """ return _distro.major_version(best) def minor_version(best=False): """ Return the minor version of the current OS distribution, as a string, if provided. Otherwise, the empty string is returned. The minor version is the second part of the dot-separated version string. For a description of the *best* parameter, see the :func:`distro.version` method. """ return _distro.minor_version(best) def build_number(best=False): """ Return the build number of the current OS distribution, as a string, if provided. Otherwise, the empty string is returned. The build number is the third part of the dot-separated version string. For a description of the *best* parameter, see the :func:`distro.version` method. """ return _distro.build_number(best) def like(): """ Return a space-separated list of distro IDs of distributions that are closely related to the current OS distribution in regards to packaging and programming interfaces, for example distributions the current distribution is a derivative from. **Lookup hierarchy:** This information item is only provided by the os-release file. For details, see the description of the "ID_LIKE" attribute in the `os-release man page <http://www.freedesktop.org/software/systemd/man/os-release.html>`_. """ return _distro.like() def codename(): """ Return the codename for the release of the current OS distribution, as a string. If the distribution does not have a codename, an empty string is returned. Note that the returned codename is not always really a codename. For example, openSUSE returns "x86_64". This function does not handle such cases in any special way and just returns the string it finds, if any. **Lookup hierarchy:** * the codename within the "VERSION" attribute of the os-release file, if provided, * the value of the "Codename" attribute returned by the lsb_release command, * the value of the "<codename>" field of the distro release file. """ return _distro.codename() def info(pretty=False, best=False): """ Return certain machine-readable information items about the current OS distribution in a dictionary, as shown in the following example: .. sourcecode:: python { 'id': 'rhel', 'version': '7.0', 'version_parts': { 'major': '7', 'minor': '0', 'build_number': '' }, 'like': 'fedora', 'codename': 'Maipo' } The dictionary structure and keys are always the same, regardless of which information items are available in the underlying data sources. The values for the various keys are as follows: * ``id``: The result of :func:`distro.id`. * ``version``: The result of :func:`distro.version`. * ``version_parts -> major``: The result of :func:`distro.major_version`. * ``version_parts -> minor``: The result of :func:`distro.minor_version`. * ``version_parts -> build_number``: The result of :func:`distro.build_number`. * ``like``: The result of :func:`distro.like`. * ``codename``: The result of :func:`distro.codename`. For a description of the *pretty* and *best* parameters, see the :func:`distro.version` method. """ return _distro.info(pretty, best) def os_release_info(): """ Return a dictionary containing key-value pairs for the information items from the os-release file data source of the current OS distribution. See `os-release file`_ for details about these information items. """ return _distro.os_release_info() def lsb_release_info(): """ Return a dictionary containing key-value pairs for the information items from the lsb_release command data source of the current OS distribution. See `lsb_release command output`_ for details about these information items. """ return _distro.lsb_release_info() def distro_release_info(): """ Return a dictionary containing key-value pairs for the information items from the distro release file data source of the current OS distribution. See `distro release file`_ for details about these information items. """ return _distro.distro_release_info() def uname_info(): """ Return a dictionary containing key-value pairs for the information items from the distro release file data source of the current OS distribution. """ return _distro.uname_info() def os_release_attr(attribute): """ Return a single named information item from the os-release file data source of the current OS distribution. Parameters: * ``attribute`` (string): Key of the information item. Returns: * (string): Value of the information item, if the item exists. The empty string, if the item does not exist. See `os-release file`_ for details about these information items. """ return _distro.os_release_attr(attribute) def lsb_release_attr(attribute): """ Return a single named information item from the lsb_release command output data source of the current OS distribution. Parameters: * ``attribute`` (string): Key of the information item. Returns: * (string): Value of the information item, if the item exists. The empty string, if the item does not exist. See `lsb_release command output`_ for details about these information items. """ return _distro.lsb_release_attr(attribute) def distro_release_attr(attribute): """ Return a single named information item from the distro release file data source of the current OS distribution. Parameters: * ``attribute`` (string): Key of the information item. Returns: * (string): Value of the information item, if the item exists. The empty string, if the item does not exist. See `distro release file`_ for details about these information items. """ return _distro.distro_release_attr(attribute) def uname_attr(attribute): """ Return a single named information item from the distro release file data source of the current OS distribution. Parameters: * ``attribute`` (string): Key of the information item. Returns: * (string): Value of the information item, if the item exists. The empty string, if the item does not exist. """ return _distro.uname_attr(attribute) class cached_property(object): """A version of @property which caches the value. On access, it calls the underlying function and sets the value in `__dict__` so future accesses will not re-call the property. """ def __init__(self, f): self._fname = f.__name__ self._f = f def __get__(self, obj, owner): assert obj is not None, 'call {} on an instance'.format(self._fname) ret = obj.__dict__[self._fname] = self._f(obj) return ret class LinuxDistribution(object): """ Provides information about a OS distribution. This package creates a private module-global instance of this class with default initialization arguments, that is used by the `consolidated accessor functions`_ and `single source accessor functions`_. By using default initialization arguments, that module-global instance returns data about the current OS distribution (i.e. the distro this package runs on). Normally, it is not necessary to create additional instances of this class. However, in situations where control is needed over the exact data sources that are used, instances of this class can be created with a specific distro release file, or a specific os-release file, or without invoking the lsb_release command. """ def __init__(self, include_lsb=True, os_release_file='', distro_release_file='', include_uname=True): """ The initialization method of this class gathers information from the available data sources, and stores that in private instance attributes. Subsequent access to the information items uses these private instance attributes, so that the data sources are read only once. Parameters: * ``include_lsb`` (bool): Controls whether the `lsb_release command output`_ is included as a data source. If the lsb_release command is not available in the program execution path, the data source for the lsb_release command will be empty. * ``os_release_file`` (string): The path name of the `os-release file`_ that is to be used as a data source. An empty string (the default) will cause the default path name to be used (see `os-release file`_ for details). If the specified or defaulted os-release file does not exist, the data source for the os-release file will be empty. * ``distro_release_file`` (string): The path name of the `distro release file`_ that is to be used as a data source. An empty string (the default) will cause a default search algorithm to be used (see `distro release file`_ for details). If the specified distro release file does not exist, or if no default distro release file can be found, the data source for the distro release file will be empty. * ``include_name`` (bool): Controls whether uname command output is included as a data source. If the uname command is not available in the program execution path the data source for the uname command will be empty. Public instance attributes: * ``os_release_file`` (string): The path name of the `os-release file`_ that is actually used as a data source. The empty string if no distro release file is used as a data source. * ``distro_release_file`` (string): The path name of the `distro release file`_ that is actually used as a data source. The empty string if no distro release file is used as a data source. * ``include_lsb`` (bool): The result of the ``include_lsb`` parameter. This controls whether the lsb information will be loaded. * ``include_uname`` (bool): The result of the ``include_uname`` parameter. This controls whether the uname information will be loaded. Raises: * :py:exc:`IOError`: Some I/O issue with an os-release file or distro release file. * :py:exc:`subprocess.CalledProcessError`: The lsb_release command had some issue (other than not being available in the program execution path). * :py:exc:`UnicodeError`: A data source has unexpected characters or uses an unexpected encoding. """ self.os_release_file = os_release_file or \ os.path.join(_UNIXCONFDIR, _OS_RELEASE_BASENAME) self.distro_release_file = distro_release_file or '' # updated later self.include_lsb = include_lsb self.include_uname = include_uname def __repr__(self): """Return repr of all info """ return \ "LinuxDistribution(" \ "os_release_file={self.os_release_file!r}, " \ "distro_release_file={self.distro_release_file!r}, " \ "include_lsb={self.include_lsb!r}, " \ "include_uname={self.include_uname!r}, " \ "_os_release_info={self._os_release_info!r}, " \ "_lsb_release_info={self._lsb_release_info!r}, " \ "_distro_release_info={self._distro_release_info!r}, " \ "_uname_info={self._uname_info!r})".format( self=self) def linux_distribution(self, full_distribution_name=True): """ Return information about the OS distribution that is compatible with Python's :func:`platform.linux_distribution`, supporting a subset of its parameters. For details, see :func:`distro.linux_distribution`. """ return ( self.name() if full_distribution_name else self.id(), self.version(), self.codename() ) def id(self): """Return the distro ID of the OS distribution, as a string. For details, see :func:`distro.id`. """ def normalize(distro_id, table): distro_id = distro_id.lower().replace(' ', '_') return table.get(distro_id, distro_id) distro_id = self.os_release_attr('id') if distro_id: return normalize(distro_id, NORMALIZED_OS_ID) distro_id = self.lsb_release_attr('distributor_id') if distro_id: return normalize(distro_id, NORMALIZED_LSB_ID) distro_id = self.distro_release_attr('id') if distro_id: return normalize(distro_id, NORMALIZED_DISTRO_ID) distro_id = self.uname_attr('id') if distro_id: return normalize(distro_id, NORMALIZED_DISTRO_ID) return '' def name(self, pretty=False): """ Return the name of the OS distribution, as a string. For details, see :func:`distro.name`. """ name = self.os_release_attr('name') \ or self.lsb_release_attr('distributor_id') \ or self.distro_release_attr('name') \ or self.uname_attr('name') if pretty: name = self.os_release_attr('pretty_name') \ or self.lsb_release_attr('description') if not name: name = self.distro_release_attr('name') \ or self.uname_attr('name') version = self.version(pretty=True) if version: name = name + ' ' + version return name or '' def version(self, pretty=False, best=False): """ Return the version of the OS distribution, as a string. For details, see :func:`distro.version`. """ versions = [ self.os_release_attr('version_id'), self.lsb_release_attr('release'), self.distro_release_attr('version_id'), self._parse_distro_release_content( self.os_release_attr('pretty_name')).get('version_id', ''), self._parse_distro_release_content( self.lsb_release_attr('description')).get('version_id', ''), self.uname_attr('release') ] version = '' if best: # This algorithm uses the last version in priority order that has # the best precision. If the versions are not in conflict, that # does not matter; otherwise, using the last one instead of the # first one might be considered a surprise. for v in versions: if v.count(".") > version.count(".") or version == '': version = v else: for v in versions: if v != '': version = v break if pretty and version and self.codename(): version = u'{0} ({1})'.format(version, self.codename()) return version def version_parts(self, best=False): """ Return the version of the OS distribution, as a tuple of version numbers. For details, see :func:`distro.version_parts`. """ version_str = self.version(best=best) if version_str: version_regex = re.compile(r'(\d+)\.?(\d+)?\.?(\d+)?') matches = version_regex.match(version_str) if matches: major, minor, build_number = matches.groups() return major, minor or '', build_number or '' return '', '', '' def major_version(self, best=False): """ Return the major version number of the current distribution. For details, see :func:`distro.major_version`. """ return self.version_parts(best)[0] def minor_version(self, best=False): """ Return the minor version number of the current distribution. For details, see :func:`distro.minor_version`. """ return self.version_parts(best)[1] def build_number(self, best=False): """ Return the build number of the current distribution. For details, see :func:`distro.build_number`. """ return self.version_parts(best)[2] def like(self): """ Return the IDs of distributions that are like the OS distribution. For details, see :func:`distro.like`. """ return self.os_release_attr('id_like') or '' def codename(self): """ Return the codename of the OS distribution. For details, see :func:`distro.codename`. """ try: # Handle os_release specially since distros might purposefully set # this to empty string to have no codename return self._os_release_info['codename'] except KeyError: return self.lsb_release_attr('codename') \ or self.distro_release_attr('codename') \ or '' def info(self, pretty=False, best=False): """ Return certain machine-readable information about the OS distribution. For details, see :func:`distro.info`. """ return dict( id=self.id(), version=self.version(pretty, best), version_parts=dict( major=self.major_version(best), minor=self.minor_version(best), build_number=self.build_number(best) ), like=self.like(), codename=self.codename(), ) def os_release_info(self): """ Return a dictionary containing key-value pairs for the information items from the os-release file data source of the OS distribution. For details, see :func:`distro.os_release_info`. """ return self._os_release_info def lsb_release_info(self): """ Return a dictionary containing key-value pairs for the information items from the lsb_release command data source of the OS distribution. For details, see :func:`distro.lsb_release_info`. """ return self._lsb_release_info def distro_release_info(self): """ Return a dictionary containing key-value pairs for the information items from the distro release file data source of the OS distribution. For details, see :func:`distro.distro_release_info`. """ return self._distro_release_info def uname_info(self): """ Return a dictionary containing key-value pairs for the information items from the uname command data source of the OS distribution. For details, see :func:`distro.uname_info`. """ return self._uname_info def os_release_attr(self, attribute): """ Return a single named information item from the os-release file data source of the OS distribution. For details, see :func:`distro.os_release_attr`. """ return self._os_release_info.get(attribute, '') def lsb_release_attr(self, attribute): """ Return a single named information item from the lsb_release command output data source of the OS distribution. For details, see :func:`distro.lsb_release_attr`. """ return self._lsb_release_info.get(attribute, '') def distro_release_attr(self, attribute): """ Return a single named information item from the distro release file data source of the OS distribution. For details, see :func:`distro.distro_release_attr`. """ return self._distro_release_info.get(attribute, '') def uname_attr(self, attribute): """ Return a single named information item from the uname command output data source of the OS distribution. For details, see :func:`distro.uname_release_attr`. """ return self._uname_info.get(attribute, '') @cached_property def _os_release_info(self): """ Get the information items from the specified os-release file. Returns: A dictionary containing all information items. """ if os.path.isfile(self.os_release_file): with open(self.os_release_file) as release_file: return self._parse_os_release_content(release_file) return {} @staticmethod def _parse_os_release_content(lines): """ Parse the lines of an os-release file. Parameters: * lines: Iterable through the lines in the os-release file. Each line must be a unicode string or a UTF-8 encoded byte string. Returns: A dictionary containing all information items. """ props = {} lexer = shlex.shlex(lines, posix=True) lexer.whitespace_split = True # The shlex module defines its `wordchars` variable using literals, # making it dependent on the encoding of the Python source file. # In Python 2.6 and 2.7, the shlex source file is encoded in # 'iso-8859-1', and the `wordchars` variable is defined as a byte # string. This causes a UnicodeDecodeError to be raised when the # parsed content is a unicode object. The following fix resolves that # (... but it should be fixed in shlex...): if sys.version_info[0] == 2 and isinstance(lexer.wordchars, bytes): lexer.wordchars = lexer.wordchars.decode('iso-8859-1') tokens = list(lexer) for token in tokens: # At this point, all shell-like parsing has been done (i.e. # comments processed, quotes and backslash escape sequences # processed, multi-line values assembled, trailing newlines # stripped, etc.), so the tokens are now either: # * variable assignments: var=value # * commands or their arguments (not allowed in os-release) if '=' in token: k, v = token.split('=', 1) if isinstance(v, bytes): v = v.decode('utf-8') props[k.lower()] = v else: # Ignore any tokens that are not variable assignments pass if 'version_codename' in props: # os-release added a version_codename field. Use that in # preference to anything else Note that some distros purposefully # do not have code names. They should be setting # version_codename="" props['codename'] = props['version_codename'] elif 'ubuntu_codename' in props: # Same as above but a non-standard field name used on older Ubuntus props['codename'] = props['ubuntu_codename'] elif 'version' in props: # If there is no version_codename, parse it from the version codename = re.search(r'(\(\D+\))|,(\s+)?\D+', props['version']) if codename: codename = codename.group() codename = codename.strip('()') codename = codename.strip(',') codename = codename.strip() # codename appears within paranthese. props['codename'] = codename return props @cached_property def _lsb_release_info(self): """ Get the information items from the lsb_release command output. Returns: A dictionary containing all information items. """ if not self.include_lsb: return {} with open(os.devnull, 'w') as devnull: try: cmd = ('lsb_release', '-a') stdout = subprocess.check_output(cmd, stderr=devnull) except OSError: # Command not found return {} content = stdout.decode(sys.getfilesystemencoding()).splitlines() return self._parse_lsb_release_content(content) @staticmethod def _parse_lsb_release_content(lines): """ Parse the output of the lsb_release command. Parameters: * lines: Iterable through the lines of the lsb_release output. Each line must be a unicode string or a UTF-8 encoded byte string. Returns: A dictionary containing all information items. """ props = {} for line in lines: kv = line.strip('\n').split(':', 1) if len(kv) != 2: # Ignore lines without colon. continue k, v = kv props.update({k.replace(' ', '_').lower(): v.strip()}) return props @cached_property def _uname_info(self): with open(os.devnull, 'w') as devnull: try: cmd = ('uname', '-rs') stdout = subprocess.check_output(cmd, stderr=devnull) except OSError: return {} content = stdout.decode(sys.getfilesystemencoding()).splitlines() return self._parse_uname_content(content) @staticmethod def _parse_uname_content(lines): props = {} match = re.search(r'^([^\s]+)\s+([\d\.]+)', lines[0].strip()) if match: name, version = match.groups() # This is to prevent the Linux kernel version from # appearing as the 'best' version on otherwise # identifiable distributions. if name == 'Linux': return {} props['id'] = name.lower() props['name'] = name props['release'] = version return props @cached_property def _distro_release_info(self): """ Get the information items from the specified distro release file. Returns: A dictionary containing all information items. """ if self.distro_release_file: # If it was specified, we use it and parse what we can, even if # its file name or content does not match the expected pattern. distro_info = self._parse_distro_release_file( self.distro_release_file) basename = os.path.basename(self.distro_release_file) # The file name pattern for user-specified distro release files # is somewhat more tolerant (compared to when searching for the # file), because we want to use what was specified as best as # possible. match = _DISTRO_RELEASE_BASENAME_PATTERN.match(basename) if 'name' in distro_info \ and 'cloudlinux' in distro_info['name'].lower(): distro_info['id'] = 'cloudlinux' elif match: distro_info['id'] = match.group(1) return distro_info else: try: basenames = os.listdir(_UNIXCONFDIR) # We sort for repeatability in cases where there are multiple # distro specific files; e.g. CentOS, Oracle, Enterprise all # containing `redhat-release` on top of their own. basenames.sort() except OSError: # This may occur when /etc is not readable but we can't be # sure about the *-release files. Check common entries of # /etc for information. If they turn out to not be there the # error is handled in `_parse_distro_release_file()`. basenames = ['SuSE-release', 'arch-release', 'base-release', 'centos-release', 'fedora-release', 'gentoo-release', 'mageia-release', 'mandrake-release', 'mandriva-release', 'mandrivalinux-release', 'manjaro-release', 'oracle-release', 'redhat-release', 'sl-release', 'slackware-version'] for basename in basenames: if basename in _DISTRO_RELEASE_IGNORE_BASENAMES: continue match = _DISTRO_RELEASE_BASENAME_PATTERN.match(basename) if match: filepath = os.path.join(_UNIXCONFDIR, basename) distro_info = self._parse_distro_release_file(filepath) if 'name' in distro_info: # The name is always present if the pattern matches self.distro_release_file = filepath distro_info['id'] = match.group(1) if 'cloudlinux' in distro_info['name'].lower(): distro_info['id'] = 'cloudlinux' return distro_info return {} def _parse_distro_release_file(self, filepath): """ Parse a distro release file. Parameters: * filepath: Path name of the distro release file. Returns: A dictionary containing all information items. """ try: with open(filepath) as fp: # Only parse the first line. For instance, on SLES there # are multiple lines. We don't want them... return self._parse_distro_release_content(fp.readline()) except (OSError, IOError): # Ignore not being able to read a specific, seemingly version # related file. # See https://github.com/nir0s/distro/issues/162 return {} @staticmethod def _parse_distro_release_content(line): """ Parse a line from a distro release file. Parameters: * line: Line from the distro release file. Must be a unicode string or a UTF-8 encoded byte string. Returns: A dictionary containing all information items. """ if isinstance(line, bytes): line = line.decode('utf-8') matches = _DISTRO_RELEASE_CONTENT_REVERSED_PATTERN.match( line.strip()[::-1]) distro_info = {} if matches: # regexp ensures non-None distro_info['name'] = matches.group(3)[::-1] if matches.group(2): distro_info['version_id'] = matches.group(2)[::-1] if matches.group(1): distro_info['codename'] = matches.group(1)[::-1] elif line: distro_info['name'] = line.strip() return distro_info _distro = LinuxDistribution() def main(): logger = logging.getLogger(__name__) logger.setLevel(logging.DEBUG) logger.addHandler(logging.StreamHandler(sys.stdout)) parser = argparse.ArgumentParser(description="OS distro info tool") parser.add_argument( '--json', '-j', help="Output in machine readable format", action="store_true") args = parser.parse_args() if args.json: logger.info(json.dumps(info(), indent=4, sort_keys=True)) else: logger.info('Name: %s', name(pretty=True)) distribution_version = version(pretty=True) logger.info('Version: %s', distribution_version) distribution_codename = codename() logger.info('Codename: %s', distribution_codename) if __name__ == '__main__': main()


THE FRIDGE
Dashboard
Products
FRIDGE CONTAINS:
Add products
Show
Summary
Alarms
ALARMS SETINGS:
Add alarm
Show list
Recipies
COOK BOOK:
Find
Add
About
{% if act_alm > 0 %}
{{ act_alm }}
{% endif %}
Alerts Center
{% for alarm in alarm_list %}
{{ alarm }}
{% endfor %}
Show All Alerts
{{user}}
Profile
Settings
Logout
{% block zawartosc %} {% endblock %}
Ready to Leave?
×
Select "Logout" below if you are ready to end your current session.
Settings
×
Settings hire...
Profile
×
Profile info hire...


Submit Cat Pictures:
Cat's Name:
Cat's Age:
Cat's Fur:
🔫 ALL CAT PICS SUBMITTED MUST BE COPYRIGHT FREE OR ELSE 🔫
Cat Pics
|
Dog Pics
|
Cowboy Pics


This Aspirational generation isn’t defined by age, but rather the desire for their actions to meet their needs, have a positive impact on others and connect them with an ideal or community that’s bigger than themselves. Representing 39 percent of the global adult population, Aspirationals are connecting the right thing to do with the cool thing to do, creating new possibilities for brands, business and the society we share.


{% extends "_basenarrow.html" %} {% load staticfiles %} {% block extra_css %}{% endblock %}{% block extra_javascript %} {% endblock %} {% block body %}
Thank you for submitting your ticket. We will review it and get back to you.
You will recieve a confirmation from us.
If you want to reach us, you can call<PHONE_NUMBER> or email us at<EMAIL_ADDRESS>Have a great day!
Infotek Solutions and Support.
{% endblock %}


{%extends 'base.html'%} {% load bootstrap4 %} {%load static%} {% block content %} {{ block.super}}
The Awwards awards award to projects. Tech privileges.


--- layout: api title: "v2.1.4 JavaScript Library: L.Util" categories: api version: v2.1.4 permalink: /api/v2.1.4/l-util/ ---
Various utility functions, used by Leaflet internally.
| Method | Returns | Description |
|---|---|---|
extend(
|
Object |
Merges the properties of the src object (or multiple objects) into dest object and returns the latter. Has an L.extend shortcut. |
bind(
|
Function |
Returns a function which executes function fn with the given scope obj (so that this keyword refers to obj inside the function code). Has an L.bind shortcut. |
stamp( <Object> obj ) |
String |
Applies a unique key to the object and returns that key. Has an L.stamp shortcut. |
requestAnimFrame(
|
Number |
Schedules fn to be executed when the browser repaints. When immediate is set, fn is called immediately if the browser doesn't have native support for requestAnimationFrame , otherwise it's delayed. Returns an id that can be used to cancel the request |
cancelAnimFrame(
|
- | Cancels a previous request to requestAnimFrame . |
limitExecByInterval(
|
Function |
Returns a wrapper around the function fn that makes sure it's called not more often than a certain time interval time , but as fast as possible otherwise (for example, it is used for checking and requesting new tiles while dragging the map), optionally passing the scope (context ) in which the function will be called. |
falseFn() |
Function |
Returns a function which always returns false . |
formatNum(
|
Number |
Returns the number num rounded to digits decimals. |
splitWords(
|
String[] |
Trims and splits the string on whitespace and returns the array of parts. |
setOptions(
|
Object |
Merges the given properties to the options of the obj object, returning the resulting options. See Class options. Has an L.setOptions shortcut. |
getParamString(
|
String |
Converts an object into a parameter URL string, e.g. {a: "foo", b: "bar"} '?a=foo&b=bar' . |
template(
|
String |
Simple templating facility, accepts a template string of the form 'Hello {a}, {b}' and a data object like {a: 'foo', b: 'bar'} , returns evaluated string ('Hello foo, bar' ). You can also specify functions instead of strings for data values — they will be evaluated passing data as an argument. |
isArray(
|
Boolean |
Returns true if the given object is an array. |
trim(
|
String |
Trims the whitespace from both ends of the string and returns the result. |
| Property | Type | Description |
|---|---|---|
emptyImageUrl |
String |
Data URI string containing a base64-encoded empty GIF image. Used as a hack to free memory from unused images on WebKit-powered mobile devices (by setting image src to this string). |


This website contains works I have worked on for this class and previous classes.
Hello, This is my 3rd year at California State East Bay. My major is Multimedia but my main focus or career plans that I want to do with this degree would be Web Developer or maybe Web Design but something to do with web around that field.


{% trans "You are receiving this email because you have requested to reset your password." %}
{% trans 'Set new password' as label %}
{% include "emailing/btn.html" with href=password_reset_confirm_url label=label %}
{% end_content_section %}
{% endblock %}


Conventions¶
WebAssembly code is executed when instantiating a module or invoking an exported function on the resulting module instance.
Execution behavior is defined in terms of an abstract machine that models the program state. It includes a stack, which records operand values and control constructs, and an abstract store containing global state.
For each instruction, there is a rule that specifies the effect of its execution on the program state. Furthermore, there are rules describing the instantiation of a module. As with validation, all rules are given in two equivalent forms:
- In prose, describing the execution in intuitive form.
- In formal notation, describing the rule in mathematical form. [1]
Note
As with validation, the prose and formal rules are equivalent, so that understanding of the formal notation is not required to read this specification. The formalism offers a more concise description in notation that is used widely in programming languages semantics and is readily amenable to mathematical proof.
Prose Notation¶
Execution is specified by stylised, step-wise rules for each instruction of the abstract syntax. The following conventions are adopted in stating these rules.
- The execution rules implicitly assume a given store \(S\).
- The execution rules also assume the presence of an implicit stack that is modified by pushing or popping values, labels, and frames.
- Certain rules require the stack to contain at least one frame. The most recent frame is referred to as the current frame.
- Both the store and the current frame are mutated by replacing some of their components. Such replacement is assumed to apply globally.
- The execution of an instruction may trap, in which case the entire computation is aborted and no further modifications to the store are performed by it. (Other computations can still be initiated afterwards.)
- The execution of an instruction may also end in a jump to a designated target, which defines the next instruction to execute.
- Execution can enter and exit instruction sequences that form blocks.
- Instruction sequences are implicitly executed in order, unless a trap or jump occurs.
- In various places the rules contain assertions expressing crucial invariants about the program state.
Formal Notation¶
Note
This section gives a brief explanation of the notation for specifying execution formally. For the interested reader, a more thorough introduction can be found in respective text books. [2]
The formal execution rules use a standard approach for specifying operational semantics, rendering them into reduction rules. Every rule has the following general form:
A configuration is a syntactic description of a program state. Each rule specifies one step of execution. As long as there is at most one reduction rule applicable to a given configuration, reduction – and thereby execution – is deterministic. WebAssembly has only very few exceptions to this, which are noted explicitly in this specification.
For WebAssembly, a configuration typically is a tuple \((S; F; \href{../syntax/instructions.html#syntax-instr}{\mathit{instr}}^\ast)\) consisting of the current store \(S\), the call frame \(F\) of the current function, and the sequence of instructions that is to be executed. (A more precise definition is given later.)
To avoid unnecessary clutter, the store \(S\) and the frame \(F\) are omitted from reduction rules that do not touch them.
There is no separate representation of the stack. Instead, it is conveniently represented as part of the configuration’s instruction sequence. In particular, values are defined to coincide with \(\href{../syntax/instructions.html#syntax-instr-numeric}{\mathsf{const}}\) instructions, and a sequence of \(\href{../syntax/instructions.html#syntax-instr-numeric}{\mathsf{const}}\) instructions can be interpreted as an operand “stack” that grows to the right.
Note
For example, the reduction rule for the \(\href{../syntax/types.html#syntax-valtype}{\mathsf{i32}}.\href{../syntax/instructions.html#syntax-instr-numeric}{\mathsf{add}}\) instruction can be given as follows:
Per this rule, two \(\href{../syntax/instructions.html#syntax-instr-numeric}{\mathsf{const}}\) instructions and the \(\href{../syntax/instructions.html#syntax-instr-numeric}{\mathsf{add}}\) instruction itself are removed from the instruction stream and replaced with one new \(\href{../syntax/instructions.html#syntax-instr-numeric}{\mathsf{const}}\) instruction. This can be interpreted as popping two value off the stack and pushing the result.
When no result is produced, an instruction reduces to the empty sequence:
Labels and frames are similarly defined to be part of an instruction sequence.
The order of reduction is determined by the definition of an appropriate evaluation context.
Reduction terminates when no more reduction rules are applicable. Soundness of the WebAssembly type system guarantees that this is only the case when the original instruction sequence has either been reduced to a sequence of \(\href{../syntax/instructions.html#syntax-instr-numeric}{\mathsf{const}}\) instructions, which can be interpreted as the values of the resulting operand stack, or if a trap occurred.
Note
For example, the following instruction sequence,
terminates after three steps:
where \(x_4 = -x_2\) and \(x_5 = -x_2 + x_3\) and \(x_6 = x_1 \cdot (-x_2 + x_3)\).
| [1] | The semantics is derived from the following article: Andreas Haas, Andreas Rossberg, Derek Schuff, Ben Titzer, Dan Gohman, Luke Wagner, Alon Zakai, JF Bastien, Michael Holman. Bringing the Web up to Speed with WebAssembly. Proceedings of the 38th ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI 2017). ACM 2017. |
| [2] | For example: Benjamin Pierce. Types and Programming Languages. The MIT Press 2002 |