[Solved] making custom user script more flexible & easy to share

Lone_Wolf · 2024-08-31 13:12:14

Until now I store my custom user scripts under ~ .
Their number and complexity is slowly increasing (currently I have 9) and there are atleast 4 more I would like to add but don't because it's getting to crowded there.

The scripts are meant to be executed in an interactive non-login shell .

Moving them to /usr/local/bin seems like an improvement, but I also want to make them flexible enough to be used on other systems and/or by other people .

Currently I'm thinking to use env vars for adding flexibilty. The scripts could then check for the existence of the vars they need and abort if they are not present .

The environment vars would be stored/set in a text-file in users home that can be sourced in .bashrc or equivalent.

This is the first time I try to setup something like this. What drawbacks/dangers do you see in such a setup ?

Last edited by Lone_Wolf (2024-09-14 12:15:17)

Trilby · 2024-09-01 23:14:05

I'm not sure I really understand your goals / needs, but does the storage location need to be systemwide? ~/.local/bin/ would be the "appropriate" place for user scripts.

As for environment variables, if they're specific to the script, the script could just source the "config" file at it's start.

Lone_Wolf · 2024-09-02 13:24:03

I'm not sure I really understand your goals / needs

I was hoping there is a general setup that does what I need, so kept the description a bit vague.
The lack of replies and your post clarify this has not worked.

but does the storage location need to be systemwide? ~/.local/bin/ would be the "appropriate" place for user scripts.

/usr/local/bin is in default PATH, ~/.local/bin isn't .
Adding to PATH is something I prefer to avoid.

the script could just source the "config" file at it's start.

I prefer very much to keep configuration in one place, sourcing the config-file in .bashrc or equivalent comes close to that.
(I still mourn the removal of rc.conf from archlinux)

The goal / setup I want

Manage building packages

I use 3 methods to build stuff , makepkg, ccm , devtools . The first 2 are tweaked to fit my needs, the 3rd uses upstream defaults .

The packages will be stored in several custom repos (f.e. lw-extra, lw-multilib, lw-mesa, lw-everything-not-in-other-repos )

To build with devtools succesfully I need to use the -I option a lot to add the correct packages from my custom repos.
(example : mesa-minimal-git requires 8 -I options)

adding the build packages to the custom repos is done by customized scripts.

There are also helper scripts I need like the inc_pkgrel I asked about not long ago .

Many of the envvars in the 'config'-file (though not all) will be used to determine the location of the custom repos.

Adding/removing repos or changing their location should be easy and mainly require editing the config-file .

The setup needs to be flexible enough to be useful on other systems and by multiple users on the same system.

Stretch goal (distant future) : adjustments to use a remote build server, container or VM instead of or in addition to the local machine

Last edited by Lone_Wolf (2024-09-02 13:28:55)

seth · 2024-09-02 15:02:37

What exactly prevents you from having the scripts in /usr/local/bin, some shared functions in /usr/local/lib, the default config (ie. mostly variable assignment) in /etc and the user augementation in ~/.config (or the corresponding XDG paths) - guaranteed by a shared function to load the config?
The way shell scripts work, you can even allow isolated redefinition of functions through the config.

I'd even consider collecting the prenset scripts in functions and make them accessible through a shared archpuppy executable, so you can "archpupy help", "archpuppy build …", "archpuppy publish …" etc et pp.

Lone_Wolf · 2024-09-02 16:27:01

Knowing those possibilities exist.

My limited coding experiences were application targeted, not cli .
The most complex private hobby projects I worked on were :
- filemanager for windows using borland pascal/delphi (abandoned when I found total commander did 80% of what I wanted and it would take way to long to get close to them)
- client/server framework in js for specific tasks in a game (changes in the game code made the framework obsolete before it was halfway finished)
- a mod for that same game, a few hundred LoC in 4 js files that was used by approx 10% of the player base .

Overtime I have seen too many software projects where the design had severe flaws that only became clear much later.
(Almost everytime I encounter a bug report closed with 'works as intended' the cause of the bug turns out to be a design flaw) .

This is my first serious sw project in years and I want it to have it a good design.

I'd even consider collecting the prenset scripts in functions and make them accessible through a shared archpuppy executable, so you can "archpupy help", "archpuppy build …", "archpuppy publish …" etc et pp.

Functions will definitely be considered, but I'm much more likely to create tiny executables .

I prefer master of craft X over jack-of-all-trades .

seth · 2024-09-02 19:48:15

I prefer master of craft X over jack-of-all-trades .

This is largely about scale, scope and distributability.
Of course you don't want to tie a script that cooks rice with one that autogenerates taylor swift songs.
But if you've a dozen small scripts that all kinda revolve around the same task and you want to distribute them, you
a) require people to remember them by name, but also
b) crowd their /usr/bin, occupying executable names
Sooner or later you might find yourself at least prefixing stuff to avoid name collisions and at that point it it might be beneficial to just bundle them.
Eg. take a look at git, you've git-commit etc in /usr/lib/git-core (all symlinking the git binary, but that's secondary) but the tool is "git" and you can "git commit".

This does not require you to turn this into one unmaintaninable spaghetti-script with a convoluted interdependency of features.

Lone_Wolf · 2024-09-14 12:14:15

I have done some more reading/thinking and figured out how to pass paramaters to bash functions which makes using them a lot more attractive.

Seems the cli capabilities of bash made me forget that programming languages tend to have lots of things in common, especially basic concepts.

There are still questions, but I have learned enough from this thread and reading to start a high level design.

Thanks for the answers Trilby & Seth.
Marking as solved.

Trilby · 2024-09-14 12:19:26

Lone_Wolf wrote:

I have done some more reading/thinking and figured out how to pass paramaters to bash functions which makes using them a lot more attractive.

If that's the stage you're at, I'd strongly recommend following a good bash tutorial. Gregg's wiki is commonly recommended, but once I found https://ryanstutorials.com that's been my goto recommendation.

Lone_Wolf wrote:

programming languages tend to have lots of things in common, especially basic concepts.

http://www.catb.org/esr/writings/unix-k … uiter.html

Last edited by Trilby (2024-09-14 12:35:37)

Arch Linux

#1 2024-08-31 13:12:14

[Solved] making custom user script more flexible & easy to share

#2 2024-09-01 23:14:05

Re: [Solved] making custom user script more flexible & easy to share

#3 2024-09-02 13:24:03

Re: [Solved] making custom user script more flexible & easy to share

#4 2024-09-02 15:02:37

Re: [Solved] making custom user script more flexible & easy to share

#5 2024-09-02 16:27:01

Re: [Solved] making custom user script more flexible & easy to share

#6 2024-09-02 19:48:15

Re: [Solved] making custom user script more flexible & easy to share

#7 2024-09-14 12:14:15

Re: [Solved] making custom user script more flexible & easy to share

#8 2024-09-14 12:19:26

Re: [Solved] making custom user script more flexible & easy to share

Board footer