I created some scripts for administrative tasks etc, I made them to be independent from environment - every dependency is injected through arguments. However it is annoying to provide to script commonly used dependencies every time I run it, and I don't want to hardcode in it any local information, so I created wrappers. I put my general scripts in $HOME/bin but where should I put wrappers that contain local information and are only for speeding up invocation?

Example: Think about script that makes and sends to given ftp server encrypted system backup. It was made as a generic script that can be used with any gpg public keys or ftp servers, however I'm using always only specific public key and uploading it only to specific ftp server, so I created a wrapper with this information. This generic script is actually in /root/bin as this is administrative tool, but where to put that wrapper?

  • "local" to what? What could be more "local" than your $HOME? Maybe show a few lines of example code to illustrate, I can't really understand. – grebneke Feb 9 '14 at 12:05
  • You may think of "local" as "wrapped for specific use case, that is common for me" . – Łukasz Zaroda Feb 9 '14 at 12:06
  • Please illustrate with a minimal example – grebneke Feb 9 '14 at 12:08
  • Think about script that makes and sends to given ftp server encrypted system backup. It was made as a generic script that can be used with any gpg public keys or ftp servers, however I'm using always only specific public key and uploading it only to specific ftp server, so I created a wrapper with this information. This generic script is actually in /root/bin as this is administrative tool, but where to put that wrapper? – Łukasz Zaroda Feb 9 '14 at 12:14
  • @Anthon Thanks. I added example to the body of the question. – Łukasz Zaroda Feb 9 '14 at 13:08
up vote 2 down vote accepted

Forget the wrapper stuff:-)

All you need is a .file (dot file) with the user configuration options, in the $USER directoy. You can have one in /etc for system wide config options as well.

Make your script check for these .fils (dot file) and if they exist, use them.

HTH, .

  • This actually sounds brilliant :) , when I will have some free time I will give it a shot and tell you how it went. – Łukasz Zaroda Feb 18 '14 at 9:48

You could use aliases or functions

Given a general script $HOME/bin/foo which needs to be called in different ways, assuming shell bash:

Aliases

# ~/.bashrc
alias foo1="$HOME/bin/foo -a -b"
alias foo2="$HOME/bin/foo -c -d"

Functions

# ~/.bashrc
foo1() { $HOME/bin/foo -a -b; }
foo2() { $HOME/bin/foo -c -d; }
export -f foo1 foo2

export -f makes the functions available in the environment, for other scripts run from your shell. So you could make a script foo_all run the functions foo1 and foo2 without the need to define them inside the script.

Extra note

I believe the traditional way for many is to put the general scripts in /usr/local/bin/ and put your wrappers as regular scripts in $HOME/bin/.

I believe you should abstract 1 more layer, so that you end up with this sort of pattern.

GenericName 
    calls -> Architecture_or_Server_or_Domain_or_User_specific
                calls -> AllArchServer Script

Example using backup

do_machine_backup is one name for people to use (run, add to cron jobs etc)

It's task is to workout which environment/server (maybe user) it's being run in/on/by. Say you have 3 environments dev/test/prod, it could work that out and then call the Environment_Specific script.

do_dev_machine_backup -type user | db | web
do_test_machine_backup ...
do_prod_machine_backup ...
or
do_centos_machine_backup -env dev|test|prod ...
...

This works out knowing the domain/environment, which is the backup_host, what is the to be backed-up, which keys to use, where the logfiles should go, etc

do_gen_machine_backup <src dir> <dst host> dst dir> <host_key> ... many args

I would make these scripts (not aliases or functions), mixing it up (having both) will only serve to make it more complicated to debug/develop/maintain, as it develops. You are only saving milliseconds compare that with the frequency you use them and length of run time of the scripts, it will probably make it insignificant that these are functions/aliases and not scripts.

I would put everything in one place, where ever you want, but one top level, this makes setup of new server easy, install one directory and optionally, add one directory to a path. eg /usr/local/CompanyShortName and from here, you can expand depending on your requirements now and future ./bin ./sbin/ ./config ./keys ...

It's difficult to be specific, so my suggestions have been a little generic, hopefully some of the principles of setting up an environment come accross and may be fruit for further comments.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.