A concise cli launcher / project manager using env files.
The main goal it's readability and time saving with commands use in your project. Short it's command-line tool that allow to run program (usually sh script) with environment variables mapping from .env files. - It take care to synchronize and to check the format of all environment files to each other. - Allow multiple setups in the same project. - Allow to store example of no critical environment file in your source code with an public env directory. - Allow to store prod/stage/etc.. and critical environment file in your source code with an private env directory 🔒. - You can apply a mapping in order to select, group and add custom formats / cases on the fly on the environment variables. - The result of mapping will be inject as environment variables in the output .sh script that will be executed.
It's include an index/registry that allow to share project templates: 🌱 template-index.
cargo install short
✨ PS1 (BASH/ZSH)
Example with PS1 configure by .bashrc
shell script
export PS1="$(sht show -f):\w\$ "
Example with PS1 configure by .zshrc
shell script
⚠️ TODO ...
✨ starship
Example with custom pre-prompt : starship.
Here the custom script that starship run before display prompt.
```shell script
function blastoff(){ sht show -f } starshipprecmduser_func=blastoff ```
🌱 Example with Node && ExpressJs
Generate an simply aws sam project base on this template node-express.
Requirement : You have installed node and npm.
$> sht init
$> sht generate node-express -d -t
$> sht run
-t: generate from template.
-d: create a sub directory (optional).
🌱 Example with AWS SAM
Generate an simply aws sam project base on this template aws-node-sam.
Requirement : You have installed SAM and AWS_CLI.
$> sht init
$> sht generate aws-node-sam -d -t
$> sht run
-t: generate from template.
-d: create a sub directory (optional).
You can list all templates available with sht generate -l and add a new one here.
Generate a simply bash script who display variables. You can use this base for do as you want.
$> sht init
$> sht generate setup_1 test -d
$> sht run
-d: create a sub directory (optional).
WIP README - ⚠️ tutorials step by step.
init project.Create an empty short.yaml configuration file. This one define the your project directory.
All short command inside of this folder and his child's folders take for references this configuration file.
$> sht init
short.yaml (generated)
yaml
setups: {}
generate setup.Generate an empty setup or a setup from the project templates repository, this command can be also list all available project templates.
✍ Generate an empty setup ️
| Arguments | Required | Description |
| ---------- | -------- | ----------- |
|
| Options | Allow empty* | Default | Description |
| ---------- | -------- | ------- | ----------- |
| -d , --directory | yes | run.sh generation. |
| -f , --file| no | run.sh | Path script, create directory if they miss. [conflict with "-d"] |
| -e , --env-directory| no | . | Public env directory. [conflict with "-d"] |
Example : create a setup named my_setup with .test environment file.
$> sht generate my_setup test
short.yaml (generated) : Configuration file.
setups:
my_setup:
file: run.sh
array_vars:
all: ".*"
vars: []
.test (generated) : Environment file.
VAR1=VALUE1
VAR2=VALUE2
run.sh (generated) : Runnable file.
```
declare -A all && eval all=($ALL)
declare -p all
``
The seconds linedeclare -A all && eval all=($ALL)` allow to use bash associative array.
🌱 List all project templates
$> sht generate -l
🌱 Generate setup from projects template
| Arguments | Required | Description |
| ---------- | -------- | ----------- |
|
| Options | Allow empty* | Default | Description |
| ---------- | -------- | ------- | ----------- |
| -t , --template | yes | -l |
| -d , --directory | yes |
Example : create a setup node-express with its associated envs.
$> sht generate node-express -t
👉 short.yaml (generated) and run.sh (generated) with generate from the following project template : node-express.
rename setupRename setup. e.g my_setup -> another_setup.
$> sht rename my_setup another_setup
new envCreate new env. e.g dev
$> sht new dev
Or private env. e.g prod
$> sht new dev -p
🔒 -p save the file in the private directory.
sync envSync all environment and ask you for each diff what to do.
$> sht sync
edit envEdit an environment file with your default text editor.You can choose different editor with --editor <editor> or EDITOR env vars.
$> sht edit
dir env directorySet or unset env directory.
$> sht dir ./envs/
$> sht dir --unset
pdir env private directorySet or unset env directory.
$> sht pdir ../private_envs/
$> sht pdir --unset
use select/switch your setup / environmente.g. Select my_setup with dev environment.
$> sht use my_setup dev
e.g. Switch from dev to prod environment.
$> sht use prod
👉 If an setup and environment if already selected,you can avoid to provide the setup and just indicate the environment that you want.
show your current setup / environment
$> sht show
💁 your current setup is `my_setup`:`dev`
ls list all setups and environmentsList all setups / environments and indicated the current one like sht show.
```
$> sht ls
myproject (run.sh)
prod (.prod)
dev (.dev)
mysubproject1 (mysubproject1/run.sh)
prod (subenv/.prod)
staging (subenv/.staging)
test (subenv/.test)
mysubproject2 (mysubproject2/run.sh)
prod (subenv/.prod) staging (subenv/.staging) test (sub_env/.test) ```
vars display/compare mapping environment variablese.g. Display variables mapping of test current environment
$> sht vars
| test
all | ALL (.*)
| VAR1 | VALUE1
| VAR2 | VALUE2
var1 | VAR1 | VALUE1
var2 | VAR2 | VALUE2
short_setup | SHORT_SETUP | my_sub_project_2
short_env | SHORT_ENV | test
e.g Compare variables mapping of test and prod environment
$> sht vars -e prod test
| prod | test
all | ALL (.*)
| VAR1 | VALUE1 | VALUE1
| VAR2 | VALUE2_OF_PROD | VALUE2
var1 | VAR1 | VALUE1 | VALUE1
var2 | VAR2 | VALUE2_OF_PROD | VALUE2
short_setup | SHORT_SETUP | my_sub_project_2 | my_sub_project_2
short_env | SHORT_ENV | prod | test
envs display/compare environment variablese.g. Display variables of test current environment
$> sht vars
| test
VAR1 | VALUE1
VAR2 | VALUE2
e.g. Compare variables of test and prod environment
$> sht vars -e prod test
| prod | test
VAR1 | VALUE1 | VALUE1
VAR2 | VALUE2_OF_PROD | VALUE2
short.yamlyaml
setups:
my_setup: # Setup.name : String
file: run.sh # Setup.file : Path - Required
public_env_dir: env/ # Setup.public_env_dir : Path - Optional
array_vars: # Map<ArrayVar.name,ArrayVar|Regex> : Optional
group1: ".*" # String, It's a short way to set only ArrayVar.pattern.
group2: # ArrayVar
pattern: PREFIX_.* # ArrayVar.pattern : Regex - Required
case: CamelCase # ArrayVar.case : Enum<Case> - Optional
format: "{key}={value}" # ArrayVar.format : String - Optional
delimiter: ";" # ArrayVar.delimiter : String - Optional
vars: # Array[EnvVar]
- VAR1 # Vars.env_var : String
Setup name
Path towards to a subdirectory of the project.
This configuration allow to group and apply custom format and mapping in one environment variables.
Environment file
VAR1=VALUE1
VAR2=VALUE2
PREFIX_VAR1=P_VALUE1
PREFIX_VAR2=P_VALUE2
Environment variable will be injected, see ArrayVar.format for more details.
GROUP1 => [VAR1]='VALUE1' [VAR2]='VALUE2' [PREFIX_VAR1]='P_VALUE1' [PREFIX_VAR2]='P_VALUE2'
GROUP2 => PrefixVar1=P_VALUE1;PrefixVar2=P_VALUE2
All variables match with this pattern will be grouped.
For more indications see the lib(regex)* that it's used.
Apply a case for each variables.
| Available cases | | ------------------- | | CamelCase | | snakecase | | SHOUTYSNAKE_CASE | | mixedCase | | Title Case |
For more indications see the lib(heck)* that it's used.
Format that it's apply on each variables.
There is two data who can used : {key} and {value}.
- key it's the variables name that is specified in the environment file.
- value it's the variables value that is specified in the environment file.
👉 By default it apply an format bash associative array format [{key}]='{value}' (doc).
A string that it's injected between each variables of the array.
👉 By default it's one space "".
Variables as set here, are selected for injection.
👉 Must match with environment variables.
👉 If it's no specified or empty, all variables are selected.
``` USAGE: sht [SUBCOMMAND]
FLAGS: -h, --help Prints help information -V, --version Prints version information
SUBCOMMANDS:
init Init project, create an empty "short.yaml" configuration file.
generate Generate empty setup or from template setup repository.
run Run setup [ARGS...].
rename Rename setup.
new Create env file ".
short.yamlIt's a directory with the configuration file short.yaml inside it : that defined the project root.
All short command inside of this folder and his child's folders take for references this configuration file.
init command.Setup it's is main concept of short. The setup configuration is describe in short.yaml
and take a name, a runnable file, public env directory and mapping options.
This is how short gets an easily way to simplify run command.
👉 Each setup one and only one one runnable file.
generatels command.vars command.These directories store .<env> files.
Env files presents in this directories will be synchronised to each other.
if these belong to the same setup.
This directory must be inside of your project (The default value it's the root folder of the project).
That can be a sub folder like ./env/ see setup configuration for more details.
So if you had configured git or another code versioning solution, public directory allow to save with your code
no critical configuration files like example configuration file.
.
└── project
├── envs # public env directory
│ └── .dev
├── ...
└── short.yaml
dir command. This directory must be outside of your project. The path of the private directory will be not store in project configuration ✅ ! So if you had configured git or another code versioning solution that will be never commit with your code.
.
├── envs # private env directory
│ └── .dev
└── project
├── run.sh
└── short.yaml
pdir command. .<environment_name>Each environment file define one environment in order to the environment name come from the file name like .<my_env> environment file => my_env environment name.
👉 The prefix . is mandatory.
The file formatting must be follow the RFC 2 – .env file guide line. ```
VAR1=VALUE1 VAR2=VALUE2 ```
Each environment inside on the same setup (public environment directory/private environment directory), are synchronised to each other.
new command.ls command.envs command.edit command.Option like -d who can found in sht generate my_template my_env -d can have three state.
1) Deactivate you not specified the option : e.g. sht generate my_template my_env
2) Activate; take the value by default : e.g. sht generate my_template my_env -d
The value of -d is my_template.
3) Activate with value : e.g. sht generate my_template my_env -d foo.
The value of -d is foo.