Theory of Correct Scripts
What is the difference between the script and the program? Not at all used by the language or the presence of the interface.
The main difference is that the program has a vast shell that is not bound by the "contents" of the program. Depending on the platform, these may be manual pages, support for several languages, availability of installation / uninstallation functions, execution of interface agreements (command line, or other means of interaction), interfaces in the common registry, etc. ... The program should be able to work in any documented environment, to provide for different situations (the coolest with this is for unix programs that use ./configure to determine, in fact, where they are, what is possible and what is not on this (next) platform).
The script, in the strictly opposite sense: it is designed to solve a specific problem "here and now." No one expects a script that sends statistics to be able to do it simultaneously on solaris, freeBSD, and windows embedded standard with cygwin on board.
')
There are no differences between math and program ideas, between administration scripts and programs. They work on the same principles, generally speaking, they perform almost the same thing.
The difference between the script and the program is administrative .
Almost any program has in itself THREE important components:
Let's learn more about these components ...
1) Algorithm. Any program has, firstly, a certain idea (what the program actually does), and secondly, binding. Reading configs, output to syslog, notification by mail and another thousand operations not related to the main task. But the program is used not for the sake of reading configs and writing to the log, but for the sake of what it DOES. Accordingly, usually the idea is to perform some actions on some algorithm. Nontrivial idea. In the actual code, this may be less than reading the xml-config, but it is the working algorithm that is the essence of the program. It can be either “processing the data” (like SQL), or mathematical (like md5sum), or working with the specific features of a particular piece of hardware (file format) - but it always requires high qualifications in the subject area to adequately understand the principles of operation. It is clear that any programmer can read the OpenSSL code. It is clear that the algorithm of the OpenSSL can only understand a good mathematician.
But we are not writing about programs - about scripts. So, the script should not implement non-trivial algorithms. If you write a base64 analog in your script, this is a bad script. If you write in your script sending messages on smtp using the “open socket, write” method, this is a disgusting script. If you are in your script, catch the data from the com-port and write the answer there (to manage the UPS) - this is a scribe, and not a script.
The script MUST NOT contain an algorithm in terms of the "domain". The script does not have a subject area, the script is a binding around programs that already work with subject areas. In some cases, the scripting language can provide all the tools:
This is a script. Just a script. Despite the fact that it implements an awesome amount of work. But if you have md5 - the class declared in the script 5 lines above with the implementation of md5 (or url, or open, or smtp, etc) - this is an attempt at the program. But the program is much more complicated than the algorithm that makes it up - and the like should not be implemented in scripts. NEVER.
2) Any program must have known behavior. Mathematicians suggest describing program behavior in comprehensive terms; Practice says that, besides the algorithm, the program still contains bugs and features that influence its behavior, to which it is necessary to adapt. Adapting to them is much easier when there is some practice of using the program.
“KDC has been valid once but invalid now” - if this is a message from a script - that’s all, bury it. Right here, on the spot. The program is quite a reasonable message by which you can google and find out exactly what is wrong. This is a direct consequence of the presence in the program of some substantive logic, which is specific and requires users not to study it through, but to accept behihiristicheski. I mean as a set of statements about the behavior of the program. "This version of the program does not understand files larger than 2 GB in size." It does not fit into the algorithm (and if it fits - it will take this way with the volume of discrete mathematics) - but this needs to be known in a practical sense. “This program behaves badly under the conditions of symmetrical load on the apload / download, it is better to run two copies, each of which will work in its own direction symmetrically” - understanding _SUCH_ will require titanic efforts, it is easier to take it for granted. The more complex the algorithm, the more life you need to spend on its research, adaptation and in-depth study. There is not enough life for everything, it is easier to accept as given and concentrate on the important.
The script, on the contrary, should be crystal clear for everyone who looks at it (with amendments to the knowledge of the scripting language). No
3) The script solves the problem _ HERE_NOWN. The program solves the problem _TAM_I_EVERGDA_ (adjusted for operating experience from item 2). When you write a script, you make it work on your system. It is not suitable for free use in other systems (although it may be EASY (see Clause 1) adapted). The program must be adaptable to a heap of applications, the implementation of this adaptation in the script leads to the loss of its simplicity and its transformation into a program. In addition (alas and ah), but knowledge of how to write a program correctly is not equivalent to writing the correct algorithm. You can write an amazing library, but if you can't run it on a machine that has Monday, the first day of the week (or the second, as lucky as anyone), then your library is worthless. The need to think about it - this is already writing programs - the script is valid (although not desirable).
Well, another important difference between scripts and programs. Programs (in the form of libraries) can "layered" on each other. This program needs libYYY, which uses libZZZ and libAAA, with libAAA using libZZZ and libc. This is normal.
Scripts MUST NOT DEPEND FRIEND FROM A FRIEND. The situation when the script depends on the services of another script that depends on the third is abnormal.
Note that we are talking about addiction. It is quite possible to imagine a script that calls other scripts and produces a generalized result on them, but this is a side. Slightly more difficult (for example, “run the script And if the script B did not work”) - already beyond the limits of a foul. Not good. And if the script A did not work, but did not report it? Or he worked a little bit, but then he fell off so that script B could not be completed (and we, as the authors of script A, could not have thought of such a thing)?
So what should a good script do? Splicing multiple programs into a specific system. You can consider the program for the details of the designer. And the designer himself - for the script. You should NOT cut the screw thread on the spindle - take the threaded spindle. You should not make an elliptical roller out of this elastic - it will still work poorly. If you do not have a square plate in the constructor with holes at the edges, then this is a problem of lack of details. You can try to make a square plate of a pair of rectangular, but you should not make it and hundreds of long strips.
It so happens that the scripts are reborn into programs. Suddenly, a certain logic (algorithm) appears in the script, which becomes nontrivial (and useful). At this point, you need to catch it - and do not be lazy to spend three times more time, but make it a program. Provide it with "meat", which distinguishes the program from the script. Add a hundred condition checks, replace all constants with configurable variables, prepare it to work in “unusual” conditions. It is desirable to make it public (then the practice of using it can be gained).
An ordinary pipe is almost an ideal tool for constructing simple programs:
The edge in which the script ends is difficult to find. Let's just say, the cycle is still tolerable. Check condition - normal. But checking conditions in a cycle (more than exiting the cycle) is already bad. If you have a cycle in which a cycle is launched to check the conditions, this is a 100% program. If it does not have all the things that a program should have, then it’s just a very bad program . But not a script.
When I look at the “useful scripts” collections ( here (forum.sysadmins.ru), for example), I understand that these are programs. Terrible programs without supporting documentation, installation procedures, without checking the conditions ... It’s impossible.
The use of such scripts is a sign of extreme cutsti working environment. I once tried to get along with them, but came to the conclusion that this was a mistake. It is much more correct to have a set of toolkits (i.e., full-fledged programs that implement specific things completely and well) than a set of similar scripts (I repeat once again - the program can be written in the same scripting language - the difference between the script and the program in a non-program binding: documentation and adaptability to life in a wide range of systems).
The use of copy-pasted scripts is a kind of early-dos copying on diskettes of useful programm programs. Works - rejoice, does not work - do not care, broke everything - get angry. In terms of the choice between a copy-and-paste script and a program (and minimal binding), programs should be chosen. Even if the implementation of the program will require additional efforts to study, build, etc. Having adjusted the program, you will receive the program. Having debugged the script, you will only get a crutch, the strength and durability of which even the author does not know.
Every time a similar situation arises: make a script or search for a program, you should start by searching for a program. Because programming is fascinating (yes, nagios are for us, we ourselves will write a bunch of monitoring scripts), and studying someone else is tiring (well, why the hell does it not work as I expect?). But the consequences of “underprogramming” are the lack of documentation for the “chimney” you made. And the consequence of the implemented solution is a system that can work by itself.
The main difference is that the program has a vast shell that is not bound by the "contents" of the program. Depending on the platform, these may be manual pages, support for several languages, availability of installation / uninstallation functions, execution of interface agreements (command line, or other means of interaction), interfaces in the common registry, etc. ... The program should be able to work in any documented environment, to provide for different situations (the coolest with this is for unix programs that use ./configure to determine, in fact, where they are, what is possible and what is not on this (next) platform).
The script, in the strictly opposite sense: it is designed to solve a specific problem "here and now." No one expects a script that sends statistics to be able to do it simultaneously on solaris, freeBSD, and windows embedded standard with cygwin on board.
')
There are no differences between math and program ideas, between administration scripts and programs. They work on the same principles, generally speaking, they perform almost the same thing.
The difference between the script and the program is administrative .
Almost any program has in itself THREE important components:
- Nontrivial algorithm.
- Technical support, best practices of use, typical implementation schemes and ready-made configurations.
- Proper integration into the work environment in any permitted (documented) configuration.
Let's learn more about these components ...
1) Algorithm. Any program has, firstly, a certain idea (what the program actually does), and secondly, binding. Reading configs, output to syslog, notification by mail and another thousand operations not related to the main task. But the program is used not for the sake of reading configs and writing to the log, but for the sake of what it DOES. Accordingly, usually the idea is to perform some actions on some algorithm. Nontrivial idea. In the actual code, this may be less than reading the xml-config, but it is the working algorithm that is the essence of the program. It can be either “processing the data” (like SQL), or mathematical (like md5sum), or working with the specific features of a particular piece of hardware (file format) - but it always requires high qualifications in the subject area to adequately understand the principles of operation. It is clear that any programmer can read the OpenSSL code. It is clear that the algorithm of the OpenSSL can only understand a good mathematician.
But we are not writing about programs - about scripts. So, the script should not implement non-trivial algorithms. If you write a base64 analog in your script, this is a bad script. If you write in your script sending messages on smtp using the “open socket, write” method, this is a disgusting script. If you are in your script, catch the data from the com-port and write the answer there (to manage the UPS) - this is a scribe, and not a script.
The script MUST NOT contain an algorithm in terms of the "domain". The script does not have a subject area, the script is a binding around programs that already work with subject areas. In some cases, the scripting language can provide all the tools:
if md5.md5sum (open. ($ check) .read ())! = url.openurl ($ control) .read ():
smtp.sendmail ($ from, $ to, "data check failed", "md5sum of $ check does not match control sum form $ contol.").
This is a script. Just a script. Despite the fact that it implements an awesome amount of work. But if you have md5 - the class declared in the script 5 lines above with the implementation of md5 (or url, or open, or smtp, etc) - this is an attempt at the program. But the program is much more complicated than the algorithm that makes it up - and the like should not be implemented in scripts. NEVER.
2) Any program must have known behavior. Mathematicians suggest describing program behavior in comprehensive terms; Practice says that, besides the algorithm, the program still contains bugs and features that influence its behavior, to which it is necessary to adapt. Adapting to them is much easier when there is some practice of using the program.
“KDC has been valid once but invalid now” - if this is a message from a script - that’s all, bury it. Right here, on the spot. The program is quite a reasonable message by which you can google and find out exactly what is wrong. This is a direct consequence of the presence in the program of some substantive logic, which is specific and requires users not to study it through, but to accept behihiristicheski. I mean as a set of statements about the behavior of the program. "This version of the program does not understand files larger than 2 GB in size." It does not fit into the algorithm (and if it fits - it will take this way with the volume of discrete mathematics) - but this needs to be known in a practical sense. “This program behaves badly under the conditions of symmetrical load on the apload / download, it is better to run two copies, each of which will work in its own direction symmetrically” - understanding _SUCH_ will require titanic efforts, it is easier to take it for granted. The more complex the algorithm, the more life you need to spend on its research, adaptation and in-depth study. There is not enough life for everything, it is easier to accept as given and concentrate on the important.
The script, on the contrary, should be crystal clear for everyone who looks at it (with amendments to the knowledge of the scripting language). No
(if every in self.__datarange__ is not in any map(__systable__.lang, __localtable__.map, lambda (a,b):[a in b or b in a for every __sys__.pair(a,b)])) raise "Missed i18n constitution".3) The script solves the problem _ HERE_NOWN. The program solves the problem _TAM_I_EVERGDA_ (adjusted for operating experience from item 2). When you write a script, you make it work on your system. It is not suitable for free use in other systems (although it may be EASY (see Clause 1) adapted). The program must be adaptable to a heap of applications, the implementation of this adaptation in the script leads to the loss of its simplicity and its transformation into a program. In addition (alas and ah), but knowledge of how to write a program correctly is not equivalent to writing the correct algorithm. You can write an amazing library, but if you can't run it on a machine that has Monday, the first day of the week (or the second, as lucky as anyone), then your library is worthless. The need to think about it - this is already writing programs - the script is valid (although not desirable).
Well, another important difference between scripts and programs. Programs (in the form of libraries) can "layered" on each other. This program needs libYYY, which uses libZZZ and libAAA, with libAAA using libZZZ and libc. This is normal.
Scripts MUST NOT DEPEND FRIEND FROM A FRIEND. The situation when the script depends on the services of another script that depends on the third is abnormal.
Note that we are talking about addiction. It is quite possible to imagine a script that calls other scripts and produces a generalized result on them, but this is a side. Slightly more difficult (for example, “run the script And if the script B did not work”) - already beyond the limits of a foul. Not good. And if the script A did not work, but did not report it? Or he worked a little bit, but then he fell off so that script B could not be completed (and we, as the authors of script A, could not have thought of such a thing)?
So what should a good script do? Splicing multiple programs into a specific system. You can consider the program for the details of the designer. And the designer himself - for the script. You should NOT cut the screw thread on the spindle - take the threaded spindle. You should not make an elliptical roller out of this elastic - it will still work poorly. If you do not have a square plate in the constructor with holes at the edges, then this is a problem of lack of details. You can try to make a square plate of a pair of rectangular, but you should not make it and hundreds of long strips.
It so happens that the scripts are reborn into programs. Suddenly, a certain logic (algorithm) appears in the script, which becomes nontrivial (and useful). At this point, you need to catch it - and do not be lazy to spend three times more time, but make it a program. Provide it with "meat", which distinguishes the program from the script. Add a hundred condition checks, replace all constants with configurable variables, prepare it to work in “unusual” conditions. It is desirable to make it public (then the practice of using it can be gained).
An ordinary pipe is almost an ideal tool for constructing simple programs:
lssomething | grep "bla-bla" | sendmail root@host.ru -s "bla-bal for something".
The edge in which the script ends is difficult to find. Let's just say, the cycle is still tolerable. Check condition - normal. But checking conditions in a cycle (more than exiting the cycle) is already bad. If you have a cycle in which a cycle is launched to check the conditions, this is a 100% program. If it does not have all the things that a program should have, then it’s just a very bad program . But not a script.
When I look at the “useful scripts” collections ( here (forum.sysadmins.ru), for example), I understand that these are programs. Terrible programs without supporting documentation, installation procedures, without checking the conditions ... It’s impossible.
The use of such scripts is a sign of extreme cutsti working environment. I once tried to get along with them, but came to the conclusion that this was a mistake. It is much more correct to have a set of toolkits (i.e., full-fledged programs that implement specific things completely and well) than a set of similar scripts (I repeat once again - the program can be written in the same scripting language - the difference between the script and the program in a non-program binding: documentation and adaptability to life in a wide range of systems).
The use of copy-pasted scripts is a kind of early-dos copying on diskettes of useful programm programs. Works - rejoice, does not work - do not care, broke everything - get angry. In terms of the choice between a copy-and-paste script and a program (and minimal binding), programs should be chosen. Even if the implementation of the program will require additional efforts to study, build, etc. Having adjusted the program, you will receive the program. Having debugged the script, you will only get a crutch, the strength and durability of which even the author does not know.
Every time a similar situation arises: make a script or search for a program, you should start by searching for a program. Because programming is fascinating (yes, nagios are for us, we ourselves will write a bunch of monitoring scripts), and studying someone else is tiring (well, why the hell does it not work as I expect?). But the consequences of “underprogramming” are the lack of documentation for the “chimney” you made. And the consequence of the implemented solution is a system that can work by itself.
Source: https://habr.com/ru/post/92590/
All Articles