-
Notifications
You must be signed in to change notification settings - Fork 0
1 Configuration
[Last edited for v2.1.1]
Configuration files should be located in the ./config directory. This script provides a few examples that may be useful for making your own, notable a template file if you'd like to start from scratch. The sections below describe what and how you can configure.
Note that conig files are read as as actual Bash scripts, so you can add a .sh extension to your file if you'd like it to automatically recognize the syntax - this is not required, though.
With the exception of DEFAULT_APP_INSTALL_COMMAND
, all configuration options have proper fallbacks and are completely optional to include in your config.
App Config Options:
-
APP_BACKUP_DIR
defaults to"./app-backups"
. This tells the script where the application backups should be located. -
APP_INSTALL_BACKUPS
is""
as a fallback. This tells the script whether or not it should prompt the user when installing app backups.
""
gives another pre-prompt for the user to choose one of the following:-
"-1"
- never install backups. -
"1"
- always install backups. -
"0"
or otherwise - prompt user to install backups whenever installing an app with backups detected.
-
-
DEFAULT_APP_BACKUP_TYPE
defaults to"COPY"
. This is the default backup type used for apps that do not have a specified backup type. See the entry on"backup_type"
in Adding Apps for more information on this option. -
DEFAULT_APP_INSTALL_COMMAND
should be set by the user. This is the default command used when the install_command parameter is omitted. See more information on how this can be set up in the"install_command"
entry of Adding Apps.
Archive Config Options:
-
ARCHIVE_BACKUP_DIR
defaults to"./archives"
. This indicates where archives should be located. -
DEFAULT_ARCHIVE_BACKUP_TYPE
defaults to"COPY"
. This is the default backup type used for archives that do not have a specified backup type. See the entry on"backup_type"
in Adding Archives for more information on this option.
Miscellaneous Config Options:
-
DUMP_DIR
defaults to"./dump"
. This tells the script where to dump old backups.
"$HOME/.local/share/Trash/files/linux-autosetup/dump"
is a viable alternative path if dumping to Trash is preferred.
If there is an option you would like to configure that was not shown here, there is a chance it may exist in the main script file. in the CONFIGURABLE VARIABLES
section.
App objects can be initialized by using the following command in the config file:
App "app_name" "install_command" "backup_type" "backup_path1" "backup_path2" ...
The only required parameter is "app_name"
. All other parameters can be omitted, or skipped by using an empty string ""
.
-
"app_name"
- name of the app. This can be anything that does not have special characters or spaces, which also means that the quotes are not required. The name should also be unique, not overlapping with any other app names. This is the string used as substitution for$app
, however, so be sure to provide the correct name if it is used for any commands (e.gapt install github-desktop
might come fromapt install "$app"
,App github-desktop
). -
"install_command"
- installation command used when installing app. If empty, the app defaults toDEFAULT_APP_INSTALL_COMMAND
. This string is evaluated as an actual command, so users can put virtually anything in this parameter, including calling script functions like appname.install (may be useful for things like making sure certain dependencies are installed before another command). The following are some script functions that may be of interest:-
app_name.install
orapp_group_name.install
- performs installation of the specified. -
app_name.installBackups
- performs installation of only the backups of an app. -
app_name.backup
orapp_group_name.install
- performs backup of the specified.
Tips:
- If certain commands have to be run as a normal user (e.g
yay
), prepend it withsudo -u $SUDO_USER
since the script is run as root. If you want to shorten repetitive commands, consider using substitution with a variable in the config (e.gyay="sudo -u $SUDO_USER yay"
...App someapp "$yay someapp" ...
). Note thatalias
will not work here. - Often times package managers will prompt users to confirm installs, which the user might not want. This is something that has to be handled on the user-end, however the next bullet will provide some examples that may be of use.
- Here are some examples of substitutions I've used:
flatpak="sudo -u $SUDO_USER flatpak -y --noninteractive"
yay="sudo -u $SUDO_USER yay --noconfirm"
-
-
"backup_type"
- what method to use when backing up apps. There are two valid options:"COPY"
and"HARDLINK"
."COPY"
uses the traditional method of backing up by copying files, while"HARDLINK"
creates hard-links. The latter saves space, but has limitations that should be recognized before using this backup type. -
"backup_path#"
- backup source paths associated with the app. Each app can have as many backup sources as desired (until Bash's function argument limit is hit).
Tip:$HOME
can be used as a shortcut to the user home directory; note that~/
will not work.
Archives are similar to apps, but focus more on files rather than dealing with things like app installation processes. Archive objects can be initialized by the following command:
Archive "archive_name" "backup_type" "backup_path1" "backup_path2" ...
-
"archive_name"
- name of the archive. The same naming rules apply as setting an"app_name"
. Archive names cannot overlap with app names. -
"backup_type"
- method of archival used for creating and extracting archive. There are three valid options:"COPY"
,"COMPRESS"
, and"ENCRYPT"
. Each reference the archiveCopy, archiveCompress, and archiveEncrypt functions, respectively (including their De-archive equivalents), which can be modified in the config. This script defaults to compressing to .xz and using .gpg symmetric encryption. -
"backup_path#"
- backup source paths associated with the archive.
App and archive groups let users categorize apps and archives for different use-cases. For example, a user might want to install and back up gaming stuff on their main pc, but don't need it on their laptop.
App groups can be set with the following format:
appGroups=(
[app_group_name1]="
app_name1
app_group_name2
app_name2
"
[app_group_name2]="
app_name2
app_name3
"
)
Similarly, archive groups require setting to the archiveGroups
array:
archiveGroups=(
[archive_group_name1]="
archive_name1
archive_name2
"
...
)
-
app_group_name
/archive_group_name
- names shouldn't overlap with each other or other apps and archives. A suggestion would be to capitalize group names to avoid this issue. Names are also limited to the naming scheme of apps (no special characters, no spaces). - Adding to groups - Apps and app groups can be nested in appGroups, while archives and archive groups can be nested in archiveGroups.
It's recommended that you have at least some knowledge in Bash or programming in general before attempting to use these functions.
-
on____
functions - e.gonInstallApps
; these functions are initially empty. Users can utilize these functions to easily inject code they want to run at certain events.onInstallApps
runs right before the autosetup begins installing apps, for example, whileonBackupArchivesFinish
will run after the autosetup finishes creating archive backups.
One particular use-case would be running an update with the package manager before installing apps usingonInstallApps
. -
archive___
functions - e.garchiveCopy
; these functions have fallbacks. The template config here shows these defaults if the user is interested in using these functions and would like a guide.