Skip to content
This repository has been archived by the owner on Jul 6, 2023. It is now read-only.

1 Configuration

aurtzy edited this page Nov 28, 2021 · 8 revisions

[Last edited for v2.1.1]

Creating a Config File

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.

Configuration Options

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.

Adding Apps

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.g apt install github-desktop might come from apt install "$app", App github-desktop).

  • "install_command" - installation command used when installing app. If empty, the app defaults to DEFAULT_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 or app_group_name.install - performs installation of the specified.
    • app_name.installBackups - performs installation of only the backups of an app.
    • app_name.backup or app_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 with sudo -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.g yay="sudo -u $SUDO_USER yay" ... App someapp "$yay someapp" ...). Note that alias 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.

Adding Archives

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.

Adding App Groups and Archive Groups

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.

Event Functions

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.g onInstallApps; 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, while onBackupArchivesFinish 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 using onInstallApps.
  • archive___ functions - e.g archiveCopy; 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.