Geek Answers Handbook

Shell scripting and automation instructions

I am currently working on some scenarios that automate a lot of things and have a fairly average size. I began to follow some things to make my scripts universal and portable, for example:

  • administrator login for script planning
  • use of absolute paths
  • use of configuration files
  • use write-host when developing and switching to logging during deployment (debugging)

I would be very interested to know if there are any standard methods and recommendations for scripts that aim to make the life of script developers simple. I am working on perl and powershell, so more generalized tips would be welcome and appreciated.

Thanks for any help in advance. steeluser

+4
source share
2 answers

It is quite broad, and I am sure that it is subjective. However, I have done some scripting work and can offer some things that I have learned from experience.

  • Make data for your scripts. Hardcode as little as possible. All things, such as paths, resource locations, etc., must be changed from the configuration file, and not by editing the main script. This is related to your point about absolute paths. Hardcoding all the way - it is not. To do everything relative imposes too many restrictions. It would be nice to have one variable, called, for example, DATA_ROOT , which you can change, and then all the routines refer to things like ${DATA_ROOT}/resources/images , etc. It is also useful to use $ {PROGRAM_ROOT} so that you can have multiple installations of your package for testing, etc.
  • Error checking. Scripting languages ​​are often dynamically printed, so make sure you check the return value of every thing you do. It might make sense to create a library where you can do things like call_safely(fn, arg0, arg1,.. ) and call_and_abort_on_failure(fn, arg0, arg1,...) .
  • Commentary and document are liberal. Scripts are easier to modify compiled programs, so they are often corrected incorrectly when people want to expand them. Make sure your APIs are well-documented, so when people want to add a new command line option, for example, they know how to do it, rather than writing a script wrapper on top of yours.
  • Make one script, do one and write aggregators if you need to. scripts with if(FLAG) {do_something} else {do_something_completely_different} will kill you. Make your scripts one thing and do it well, and if you want, you can write wrappers that delegate these scripts as needed (for better user convenience).
  • Use third-party tools, not invent your own. Parsing syntax, text processing, etc. - All the old areas, and there are many libraries that make them well. Use them, not redefine. The most error-free program is one that has never been written.
  • Make your logging and test frameworks robust. When bad things happen, you should know everything without overwriting scripts. From day one, use the standard logging structure and make it customizable from a file that you can reload on demand. Make sure that your code is checked by the module, so that when making new changes, regression errors are not entered. Also, log metrics so you know over time when your scripts slow down. It will be useful in the future.
  • Make your scripts as free as possible. It's hard to describe, but I can give you an example. I had several scripts for tracking various metrics in assemblies for different branches and transferring them to a directory. I wrote this so that if you want to track the foo branch you only need to create a directory called foo in a specific place and it will track this. You didn't have to bother with a lot of things, and managers who really wanted to track performance could create directories as needed.

These are the moments that I can think of from my head.

+6
source

just a few practices that I think are good:

  • Using absolute paths in order is how much you catch them at runtime. See question .
  • Use some easily processable format for configuration files, such as xml or yaml .
  • DO NOT use write-host , use write-output or write-log better, or, better, implement a user-defined function that allows you to switch between the console / log as configured in the configuration files. For more information, see My answer to this question .

These are just a few suggestions based on your points.

EDIT Note on accepting XML configuration file

Use XML, because your configuration file will contain several settings, and you will only manage it through a script.

Hope for this help

Greetings

+1
source

More articles:


All Articles