A starting point

As some wise american farmer once said...

It ain't much, but it's honnest work.

At this point, Sh:erpa is getting closer to the minimal viable form, from which the essential tasks can be performed without needing much more aditions. The goal is not to have a "kitchen-sink" type of software, but rather a small and tested core, plus external Libraries and BashBoxes.

Big lines of v0.3.0 Sh:erpa

• Oneline install
• Self-update command
• Create/Remove Local Library
• Create/Remove Local BashBox
• Install/Update/Unistall Remote Lib or BashBox
• Home dashboard with packages recap'
• Aliases to quickly move around
• UnitTests and DocsGeneration
• Quick-edit key files
• The ScriptToBinary for completion sake
• Homemade toolbox for key features

Oneline install

All examples are using thse standard sherpa command, or the short alias. You can set it to whatever else via Aliasman, the sherpa aliases command is a shortcut for aliasman -e opening the file storing all aliases.

Installation/QuickInstall

bash -c "$(curl -sLo- https://sherpa-cli.netlify.app/install.sh)"

Self update

package/update

sherpa self-update

While at it, you can run some tests from $SDD/tests

commands/self-test

sherpa self-test

Local Library & BashBox

commands/package/new

# Create/Remove local Bashbox
sherpa new <name>
sherpa rmBox <name>

# Create/Remove local Lib
sherpa new <name> lib
sherpa rmLib <name>

Edit

Open key files with the default editor specified in basecamp.sh and defaulting to vim. Other expected editor codes are nvim or code. To add more editors without breaking the tests, come on Discord tell us about what you are using instead.

I'm comming from the future, and the short alias for sherpa is now just s for fresh installs. If you have some sort alias troubles check sherpa aliases to midify them.

commands/general/edit

# /from/a/BashBox/root

sherpa edit bin
s e bin      # Edit src/bin.sh
s e opt      # Edit src/_options.sh
s e yaml     # Edit Sherpa.yaml
s e basecamp # Edit $SDD/basecamp.sh

Build

commands/build/build

# /from/a/BashBox/root

sherpa build
s b

Run

commands/build/run

# /from/a/BashBox/root

sherpa run
s r

Test

commands/package/test

# /from/a/BashBox-orLib/root

sherpa test
s t

Doc

commands/build/doc

# /from/a/BashBox/root

sherpa doc
s d

Compile

commands/build/compile

# /from/a/BashBox/root

sherpa compile
s compile

Remote BashBox & Lib

• commands/package/install
• commands/package/update
• commands/package/uninstall

# Install/Update/Uninstall
s install -n <name> -u <repoUrl>
s update <name>
s uninstall <name>

Dashboard

Date, hour, List of local Boxes & Libs or remote Boxes, plus the links to: Docs, Github, Discord.

commands/sherpa

# /from/anywhere/

sherpa
s

Aliases

Upon installation, some default aliases are created, but they can be adjusted or completed with others with sherpa aliases via Aliasman.

# /from/anywhere/

s    # Same as typing the full 'sherpa'
sdd   # SherpaDotDir    'cd $HOME/.sherpa'
scd   # SherpaCustomDir 'cd $HOME/sherpa'
boxes # localBoxesDir   'cd $HOME/sherpa/boxes'
libs  # localLibsDir    'cd $HOME/sherpa/lib'

YAML CRUD

A serie of helpers are enabeling simple data manipulation from yaml files. Can be used for logging, manipulating registers or creating little apps running from the terminal.

# /src/bin.sh

main() {
  # Persistance from the data/ directory
  file="${ROOT}/data/someFile.yaml"

  get_yaml_item "key" "$file"
  add_yaml_parent "key" "$file"
  add_yaml_item "key.nestedKey" "value" "$file"
  update_yaml_item "key" "newValue" "$file"
  delete_yaml_item "key" "$file"
}

Source local or CDN-like

tools/cargo

# /src/bin.sh

# Source    ${SCD}/lib/std/fmt.sh
# fallback  ${SDD}/lib/std/fmt.sh
use "std/fmt"

main() {
  h1 "I'm a bold, colored title"
  p "A simple ${txtBlue}formated${x} mini-paragraph."
}

tools/cdn

# /src/bin.sh

use "std/fmt"
import -r "user/repo" -f "file.sh" # Defaut to github and -b "master"
import -u "https://codeberg.org/AndiKod/someRepo/raw/branch/master/someFile.sh"

main() {
  h1 "Testing the import() function"
  p "Print $(stuff_from_importedFile "arg1")"
  p "Or $(stuff_from_Codeberg "arg1" "arg2")"
}

Pug semantics & Styles

Text is never 'just text', and having some semantics is nice.

tools/pug

# /src/bin.sh

use "std/fmt"

main() {
  h1 "I'm a bold, txtPrimary colored Title"
  hr "+" "-" # Fill the screen as ----+----
  text-center "Some centered text"
  br
  h2 "Normal, txtPrimary h2 Title"
  p "Some ${em}italic${x} text."
  br
  h3 "Like h2, but italic Title"
  p "${btnSuccess} Done! ${x} Well played."
  br
  em "check lib/std/fmt.sh"
}

# Load the main fn if no arguments
[[ "$#" == 0 ]] && main; exit 0

Now, imagine a localLib in $SCD/lib/bob/style.sh with that code:

# /lib/bob/style.sh

link="${txtBlue}${u}${em}"

then, we import and use

# /src/bin.sh

use "bob/style"

main() {
  # The url is now blue, underlined & italic
  p "Visit ${link}https://acme.com${x}" now!
}

There are so far 8 tags, 8 text colors, 8 background colors and 4 font styles, plus some functions that we can mix toger to compose our output.

Fetch API

tools/fetchapi

# /src/bin.sh

use "std/fmt"
article="https://someapi.com/post/77"

main() {
  # Get the article, and print the Title
  h1 "$(fetch "$article" | jq ".title" )"
}

...could go further, but that's the core of features that should be enough to get creative and imagine some neat BashBox to share with the community or for self-use.

What Next?

This is obviously far from over, and just a little beginning to get things started.

The BashBoxRegistry

To continue the integration of Cargo-like workflow, and to help with the promotion and dicoverability of the public BashBoxes from around git platforms, we'll find a way to reference/regroup those projects.

It will be somehow the cargo publish side of Sh:erpa, with meta-data like author, licence, description, in the Sherpa.yaml manifest and we'll see what else.

Unix philosophy ForTheWin! Build simple programs that do one thing, tested, and able to integrate with the other programs. Building things together is always better and way more Fun!

There are also some thoughts around per-project dependencies and a Lock-file to ensure stability of the builds despite evolving dependencies.

Discord & Contribution

If you have questions or not, come say hi on the Sh:erpa comunity server. When was the last time you was able to talk about Bash, CLI & Dev' with a random person? :) We are also strange.