Feature: Allow dotfiles to target root

[RaphGL]

While stow allows changing where to deploy dotfiles via flags tuckr does not, this makes so that one still needs stow to be installed on the system despite tuckr being as capable as it to track and manage dotfiles.

Root targeting should be implemented and allow users to manage global configuration from their home if they so wish. Note: This has to take into account that when run as sudo the home path becomes the root's

Possible idiom for targeting root:

├── root
│   └── tuckrfiles
│       └── usr
│           └── local
│               └── etc
└── tuckrfiles

[RaphGL]

When targetting root, an easy way to mark a group as "root targeting" is by provide a sigil

@ seems to be a decent sigil option not used by any of the major shells So groups that are targeting root could be used like so:

$ tuckr status
                                        
     ╭────────────┬───────────────╮     
     │ Symlinked  │ Not Symlinked │     
     ├────────────┼───────────────┤     
     │ alacritty  │ @pacman       │     
     │ bash       │               │     
     │ bspwm      │               │     
     │ zathura    │               │
     │ zsh        │               │     
     ╰────────────┴───────────────╯   

when using @ one has to be in running as root, tuckr knows that you're running as root by using system calls to know which user called sudo

$ sudo tuckr add @pacman

Globbing should ignore root targeting groups. If root groups are used without root permissions an error should be emitted.

[SlyCedix]

In powershell the @ is reserved as the splat operator

https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_splatting?view=powershell-7.4&viewFallbackFrom=powershell-6

Also, I don't think that root groups should be limited to root permissions, since it is not necessarily true that a user does not have access to the directory being configured, even when it is relative to the root. Say for example the destination directory exists in a mounted drive under /mnt.

This is probably doubly an issue for windows since configuration files tend to exist in a wide variety of places, not relative to the %USERPROFILE% directory. Accessing another drive without explicitly creating a sym-link that can be followed relative to the %USERPROFILE% is currently impossible, for example.

[RaphGL]

In powershell the @ is reserved as the splat operator

I haven't used powershell extensively so I didn't know that. My unix bias really is showing :P

Also, I don't think that root groups should be limited to root permissions

You're 100% correct, I was just laser focused on being able to symlink binaries into one of the root $PATH directories. I'm definitely take that into consideration.

[RaphGL]

I've been looking into which sigils are valid in the major shells out there and using something like ^group seems to work. Shells tested: powershell, tcsh (used by BSDs), zsh (default on MacOS), bash (default on Linux), fish and dash.

Besides using ^group, I think I can get rid of the Configs/root directory altogether. While fixing a previous issue I saw that ^group is a valid file name on pretty much all the file systems and OSes we target. So we can just have something like this instead:

├── ^tuckrfiles
│       └── usr
│           └── local
│               └── etc
└── tuckrfiles

[SlyCedix]

I haven't used powershell extensively so I didn't know that. My unix bias really is showing :P

If I had my way I'd not touch windows at all. Unfortunately, a lot of software approved by the government/military only ever supports windows, so high-security environments tend to only use unix for servers and embedded systems.

Another thing to note is that on windows, drives are mounted next to eachother, rather than as mounted directories relative to root. so you may need special provisions for users on windows selecting the drive. Perhaps treating each drive letter as a folder relative to the root. C:\Users\Public\... => /c/Users/Public/.... This is essentially how wine handles its emulated windows file system.

[SlyCedix]

Another thing that that should be considered is some way to reference a folder by an environment variable, for example, %. This would allow for deployment of something where the path is not necessarily known.

Groups
└── cargo
    └── %CARGO_HOME
        └── config.toml

Using this embedded group mnemonic style means you could have single groups that access both the root directory, an env variable directory, and a home directory folder all at once.

Groups
└── cargo
    ├── %CARGO_HOME # Value of $CARGO_HOME
    ├── ^.cargo     # /.cargo/
    └── .cargo      # $HOME/.cargo/

Note that while % is the environment variable special character in cmd.exe on windows, the name must be fully enclosed: %CARGO_HOME%, so it can be used here.

[RaphGL]

That's a very smart idea. I think that's much better than what I had in mind :)

[RaphGL]

This commit is fixed by 942e67ab7579288e4f649d764b61060d798f1a3c but user experience isn't very good yet. switching to root by doing sudo changes the assumed path of TUCKR_HOME to /root. So one has to do

TUCKR_HOME=$HOME/.config sudo tuckr a <group>

I'll need to find a way to do user privilege escalation for this. But for paths that don't need root permissions in root should just work in theory. This issue is being tracked here: https://github.com/RaphGL/Tuckr/issues/73