Reading the about page in a script
-
I came across this forum post which outlines how to backup your user profile. To find the location of your user profile, you have to check the vivaldi://about page. Is the user profile location displayed on the vivaldi://about page stored anywhere else? Preferably in a file where a Powershell script could access it?
I'm writing a Powershell script to make backing up and transferring profiles a lot easier (which I would be happy to make available :D).
Goals:
-
I want to limit user input as much as a can, this way I can limit the code that I use to filter and validate the input.
-
I want to keep it simple as possible, and use resources that are available out of the box on windows(this means scripts are written as Powershell or Batch), the users don't need to download and install any additional frameworks or software.
-
-
Thus far I'm just figuring out what folders in the install directory match a version number pattern, and then sort them to get the highest. Vivaldi seems to delete old folder versions now, so it might be possible to just find the first folder that matches a pattern and read that.
Something to match this:
/(\d+\.){3}\d+/
-
@nexusfactor I've just done some digging, from this chrome bug windows can't get it from the command line directly, but you can use the
wmic
command to extract the information:wmic datafile "C:\\Program Files\\Vivaldi\\Application\\vivaldi.exe" get Version
works in powershell and prints:
Version 1.15.1104.3
-
@lonm - Thanks for this but I'm after the profile location, for example, if I go to vivaldi://about, I want to extract the profile path.
I could make the assumption that the APPDATA is the default location for a user's profile, I don't think you can change that, or at least I don't think during installation it prompted for profile location, just the install location. I can then just concatenate the rest of the path, problem is if Vivaldi restructures the folder paths in later versions it could be a problem. I think reading the profile location is reliable option, but it might hard. Need to research more.
-
@nexusfactor Couldn't you just let the user pick the location from a file explorer? I don't think members who aren't somewhat knowledgeable would use such a tool anyway. After all sync is on its way.
-
@luetage - I could, but if I wanted to keep it strictly command line, it means I either allow the user to enter the path or I read the path(I prefer this approach). As you pointed out, sync is on it's way, and anyone without knowledge of the command line will most likely wait for that feature, for those who are knowledgeable about cmd, you can easily copy the folder from APPDATA, however, I want to make a script for everyone (yes, I understand most sysadmins probably have a backup script of some sort for themselves, but I'm doing it for the simple fun of doing it).
I just launched the Vivaldi exe, and it presents 3 options for installation, all of which differ in folder location:
For all users: Program files
Per user: App Data
Standalone: User chooses during installationIs the profile location the same regardless of install location? I don't see why not, but I could be wrong, need to experiment more.
-
@nexusfactor said in Reading the about page in a script:
Is the profile location the same regardless of install location?
No, for Standalone option, the profile is stored under the Vivaldi install path
e.g.
Executable Path E:\Program Files\Vivaldi\Application\vivaldi.exe
Profile Path E:\Program Files\Vivaldi\User Data\Default -
@nexusfactor Ah, sorry. I jumped the gun a bit before reading fully.
The default locations can be accessed using things like %localappdata% on windows - that way you don't need to know the username.
There's some details here for google chrome, but it is much the same for vivaldi: https://chromium.googlesource.com/chromium/src/+/master/docs/user_data_dir.md
-
With the described logic and a function to determine OS (provided the script runs on multiple OSs) you can infer the "regular" profile path (for the current user) just fine.
Maybe you add a command line switch or environment variable to provide for standalone installations which can be absolutely un-findable as they can be stored anywhere.
This seems the best option - and someone who persistently uses standalone installations is bound to know about this and might be forced to "give up" his installation hideout
-