获取自定义 bash 脚本的可接受方式是什么？

Question

I am at beginning the process of automating some documentation functionality on my MBP and would like to learn a few good ways to source custom scripts for use with bash. I have (within the last year) picked up a MBP and been learning the ropes for package management and how shell invocation is happening. I have a 5.x version of bash from brew and originally started my config.dot-file with a.bash_profile. I have built a script with a function that will touch a readme.md from a newly created working directory that helps me automatically create an associated readme when creating a new directory- which looks like so:

function mkr() {
    touch $1/readme.md
    if [ $? -eq 0 ]
    then
        echo "Successfully created file" # stdout
        # exit 0 # success but it kills the shell?
    else
        echo "Could not create file" >&2 # out to stderr
        # exit 1 # they killed kinney
    fi
}

######CLI to invoke the above script named .mk_readme.sh
$ mkdir ~/path/to/new/dir
$ mkr !!:1

My concerns are:

1. Is there more efficient ways to handle a simple task to speed up workflow like the above?
2. When sourcing the file would it be best just to source the individual script or directory of custom scripts as needed. My guess is the solution depends on use case. Maybe we are needing devs to document their work and all needed scripts for them to make use of and get sourced from this aggregated directory. Then we look at the application side of sourcing and aggregate those separately?
3. I am sourcing the file currently in the.bash_profile with source./.mk_readme.sh . I read an article that addresses doing this through the.bashrc. What is the ramifications of this and is it best practice to place a source.bashrc into the.bash_profile for this to occur, or just leave the directories from ~ that need sourcing done straight from the.bash_profile.
4. Can anyone give me a quick ironing out on the best way to handle the exit status here? I am using VSCode and it kills the inner terminal after successfully creating the readme. In my current thought process if there was a problem with calling mkr::.1 (maybe I called !!:2 by accident) I might want a warning that the file creation was unsuccessful but it doesn't clobber my currently running shell from within there.

I may have started thinking of the answer, as it may lay in what loads when on a Mac or Posix/Unix/Linux machine. I am new to Mac and have dabbled in Ubuntu Debian and Fedora/RHEL/CentOS on both cloud and bare metal machines- I'm just trying to learn more about this laptop that costs more than my car does right now:) Thanks for your time ahead of it.

Answer 1

Feedback, per concern:

1. Is there more efficient ways to handle a simple task to speed up workflow like the above?

The script is simple. Consider testing if the file already exists before touch , if there are any side effect from bumping the timestamp, or executing other one time commands. [ -f $1/readme.md ] && return

2. When sourcing the file would it be best just to source the individual script...

Both options are reasonable, and bash will handle both in efficient way. Setting up a shared folder which will be included in the 'PATH' make it easier to make changes, add scripts, etc. I think it's more efficient (from management point of view), vs. sourcing individual files during bash startups.

3. I am sourcing the file currently in the.bash_profile with source./.mk_readme.sh.

While adding a single function definition to each bash startup is small, this will usually not scale well. On surface, this function will be used sporadically (one time per folder). I suggest adding reference to the script. If it's only needed for interactive sessions, you can use aliases in '~/.bashrc'. Very tempting to fall into slippery slope, where additional 3 letter commands will show up.

4. Can anyone give me a quick ironing out on the best way to handle the

Unfortunately, I do not have experience with running bash scripts from VS. The below is based google/stack overflow:

* Alternative, instead of running window 'pause', use 'read', to wait for standard input.
* Modify the launcher to pass env var "EXIT_PAUSE=1", add '[ "$PAUSE" ] || trap 'echo 'echo "exit $?" ; pause' EXIT' to the top your script