Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Installation of ungoogled-chromium with "-appDir" parameter fails #14

Closed
engelhro opened this issue May 21, 2021 · 2 comments
Closed

Installation of ungoogled-chromium with "-appDir" parameter fails #14

engelhro opened this issue May 21, 2021 · 2 comments
Assignees
Labels

Comments

@engelhro
Copy link

Hello,

This issue seems to be related to issue #13 I created before.

When using the -appDir parameter to install the browser into the %AppData% directory (i.e., the respective subfolder), the script has problems as editor is used with both meanings "author" (person who provides a browser build) and "name" (browser variant to be used).

I tried to install the ungoogled-chromium variant, by calling the script as follows:

chrupd.cmd -appDir -editor Ungoogled -arch 64bit -channel stable

This results in the following output:

[...]
ERROR: Shortcut target "C:\Users\<Username>\Desktop\Marmaduke\chrome.exe" does not exist
ERROR: Could not create shortcut on Desktop
[OK] Done. New Chromium version extracted to "C:\Users\<Username>\Desktop\Marmaduke".

So the editor "Marmaduke" (person) is used here, where probably the term "Ungoogled" (name) should've been used instead (to avoid confusion).

But:

  1. The installation should have happened to %AppData%, not the desktop?

  2. The actual installation was done to a folder on the desktop called ungoogled-chromium-<version>, not "Marmaduke", as the script output implies.

So apparently neither the "editor" (as person, i.e. "Marmaduke") nor the "name" (as variant, i.e. just "Ungoogled") interpretation were considered completely correct. Is this intended?

The help suggests otherwise… It mentions a parameter $editor which clearly should've resulted in one of the both interpretations above.

And of course the browser should've landed in the %AppData% folder, not on the desktop.

@mkorthof mkorthof added the bug label May 26, 2021
@mkorthof mkorthof self-assigned this May 26, 2021
@mkorthof
Copy link
Owner

mkorthof commented May 26, 2021

Thanks for the detailed report, I'll look into it.
Folder could be right, see /docs/Archives.md

mkorthof added a commit that referenced this issue Jun 12, 2021
mkorthof added a commit that referenced this issue Jun 12, 2021
mkorthof added a commit that referenced this issue Jun 12, 2021
mkorthof added a commit that referenced this issue Jun 12, 2021
@mkorthof
Copy link
Owner

Fixed in latest commit. If you use v20210109 or newer script will autoupdate

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants