2020-12-30 11:24

Juli path is not recognized correctly on Linux

Webcatalog does not detect juli, when you installed it into a folder and added it to the path. In the source it seems, that it expects juli to be installed as a snap package instead of just running "juli" to get whatever binary is in the current $PATH.

Juli on the other hand contains a hardcoded /Applications/WebCatalog.app which cannot be found on linux either.

I can run both commands from the same terminal, but both are not able to find each other.


  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答


  • weixin_39864101 weixin_39864101 4月前
    • I think I'll add options for users to change the browser paths.
    点赞 评论 复制链接分享
  • weixin_39793708 weixin_39793708 4月前

    A workaround is this patch:

    diff --git a/public/libs/install-app-async/appify-linux.sh b/public/libs/install-app-async/appify-linux.sh
    index 582db91..cb0f0af 100755
    --- a/public/libs/install-app-async/appify-linux.sh
    +++ b/public/libs/install-app-async/appify-linux.sh
    @@ -30,7 +30,7 @@ elif [ "${APPMODE}" == "juli" ]; then
    -/snap/juli/current/juli --id="${APPID}" --name="${APPNAME}" --url="${APPURL}";
    +juli --id="${APPID}" --name="${APPNAME}" --url="${APPURL}";
    diff --git a/public/listeners/generic.js b/public/listeners/generic.js
    index fb08cc2..70a87c4 100755
    --- a/public/listeners/generic.js
    +++ b/public/listeners/generic.js
    @@ -48,8 +48,8 @@ const loadGenericListeners = () => {
             if (process.platform === 'linux') {
    -          const juliPath = path.join('/snap', 'juli', 'current', 'juli');
    -          e.returnValue = fs.existsSync(juliPath);
    +          const juliPath = path.join('juli');
    +          e.returnValue = true; //fs.existsSync(juliPath);
    点赞 评论 复制链接分享
  • weixin_39864101 weixin_39864101 4月前

    Thanks a lot. I'm sure but I remember there was a reason behind this. I'll need some time to test this more carefully.

    点赞 评论 复制链接分享
  • weixin_39793708 weixin_39793708 4月前

    I think the reason may be (I did not use snap very much), that snap apps are not started by their installed path, but using the snap binary and /snap/juli/current/juli is not in the $PATH.

    On the other hand, /snap/juli/current/juli --id="${APPID}" --name="${APPNAME}" --url="${APPURL}"; looks like you're starting a snap app without using snap.

    Possibly there should be two options, using juli in the $PATH (e.g. using /usr/bin/env juli) or running it via a binary like snap or flatpak, which will need specific implementations (and should have a list-command to test if it is installed).

    点赞 评论 复制链接分享
  • weixin_39864101 weixin_39864101 4月前

    Thanks a lot, -. You're right. Also, the reason why I call /snap/juli/current/juli instead of juli is because the snap app doesn't take and transfer parameters to the binary. Do you have any suggestions? I'm not very familiar with Linux (I'm a Mac user) so I would need some help.

    点赞 评论 复制链接分享
  • weixin_39793708 weixin_39793708 4月前

    I do not use snap either and it is a rather new technique.

    Personally I still prefer software systemwide installed via (rpm/deb) package, which then is distributed over /usr/{bin,share,lib} or in an appdir for single-user installations, like ~/apps/juli for the linux-unpacked directory. The AppImage format is rather uncommon in linux, but has the advantage that everything works from a single file.

    Maybe the npm installer module can build templates for the package formats as well? I know nodejs only as user, but this looks promising:

    https://www.npmjs.com/package/node-deb https://www.npmjs.com/package/electron-installer-debian https://wiki.debian.org/Javascript/Nodejs/Npm2Deb/Tutorial

    The way to find a program there would be to call /usr/bin/env juli. env is from the file system hierarchy guaranteed to be installed there and then uses the $PATH variable, such that every program the user can start will start without knowing the full path.
    This is e.g. a best practice for python scripts, which often are run with interpreter binaries in a virtual environment (a directory somewhere, where the python libraries are installed, probably like a environment built by npm install)

    I am not sure what's the best way to test before running via env if the program exists (A simple solution is to iterate through the elements of $PATH, which also is part of the output of /usr/bin/env without parameters), but trying to run it and checking the return code may be an easy option as well.

    The advantage of packing as snappy app or flatpak is the sandbox, which is a good idea for a browser. For building, the predictable system runtime has advantages, too.

    For snap: https://askubuntu.com/questions/1026378/how-do-i-add-start-parameter-to-a-program-installed-via-snap - This looks a bit like you can indeed call snap apps by their full path. I will need to check this.

    For flatpak: flatpak run com.example.App --parameter should do.

    点赞 评论 复制链接分享
  • weixin_39812186 weixin_39812186 4月前

    Currently, I'm using the program from AppImage. However, being on the practical side, AppImage don't update with the rest of the system so I have to be on constant lookout for the new version. I'm used to having everything in pacman database so having everything updated automatically, so probably I will switch to snap since AUR version is not there. Besides, snap is far more universal then deb and rpm package so releasing this as a snap is a good idea from user and developer point of view (no need to produce new .deb and .rpm versions all the time).

    So far, I wanted to like flatpaks but I have much better experience with snaps as they tend to integrate with a system better and are not having such huge runtime bloat. Plus, from those two package formats snaps have a much richer library so all speaks for snaps being better format at the moment. At least that's my experience so far.

    点赞 评论 复制链接分享
  • weixin_39793708 weixin_39793708 4月前

    It looks like Snap programs can really be (correctly) started by their path in /snap: https://docs.snapcraft.io/getting-started/3876

    : For most systems, using .deb or .rpm with a simple repository (PPA for ubuntu and ubuntu forks) is the best way, as it really integrates with the package manager.

    I suspect that the npm package which currently produces the appimages is able to build rpm/deb/flatpak as well, so this may be less efford than we think to just add more formats. If not, packaging the appdir or appimage can be done separately with a rather simple package e.g. installing it in /opt/juli.

    In all cases, we need a stable test if it is installed and how to run it.

    点赞 评论 复制链接分享
  • weixin_39812186 weixin_39812186 4月前

    I tried snap and it has unforeseen consequences, namely, it didn't recognize installed browsers so I would have to install them again as snaps which I don't want to do. So I installed juli snap and it worked but... juli didn't switch its icon for the chosen website which is a bit annoying. Having multiple such apps with the same juli icon beats the purpose of the whole idea of having a separate webapp.

    So I guess I'll stick to AppImage for now.

    As to the issue on this topic, isn't it corrected in the latest version? There was no issue with juli in snap version aside this icon thing.

    点赞 评论 复制链接分享
  • weixin_39812186 weixin_39812186 4月前

    Keeping in the topic, did I get it right that it's about snap version not recognizing juli installed natively? If so, the same happens for all browser engines. I had to use juli as a snap to make it work and would have to install snap Chrome/Chromium/Firefox to work with snap version of this program, which not many would want to do (why having the same program installed twice, it's a waste of space).

    So if it could correctly recognize and use system native (non-snap) browsers, it would be the best. Or actually, in theory, it should look for all kind of installs, so native packages, snaps or flatpaks, so that complicates things.

    EDIT: Or maybe add an option to chose a browser manually? Sort of dialog like you have when you want to point to a program to run a certain file type? So the idea is to trigger system dialog for that so system would take care of providing the right path.

    点赞 评论 复制链接分享
  • weixin_39812186 weixin_39812186 4月前

    To continue topic (sorry for multiple posts, the browser keeps showing me the old version of this topic and I can't rid of it, even after clearing cache), I meant that kind of dialog that you invoke when you want to open a file with a specific program and then choose "different". From what I know, most mature DEs offer that option or at least Plasma and Gnome have it and it works in the same way.

    On Plasma such dialog looks like this and as far I remember, it's not much different from Gnome's one:


    So if Webcatalog wants to install browsers and we know we have them installed, let us manually provide the path with such dialog, instead of making gimmicks to make it work on all kinds of formats and all kinds of distros.

    点赞 评论 复制链接分享
  • weixin_39793708 weixin_39793708 4月前

    I see these solutions:

    • Check the environment ($PATH / %PATH%) for juli, then run juli
    • Should work at least for systemwide installations, user-installations with correct PATH and snap (not tested, but it is documented that the snaps should be in the PATH).
    • For flatpak and other installations which do not neccessarily change the PATH, you have .application files in linux, in windows probably some .lnk files and I do not know how OSX handles this.
    • Allow the user to specify a path (probably with filechooser) or just a command like juli.appimage (then the user is responsible, that juli.appimage is in the path).
    点赞 评论 复制链接分享
  • weixin_39793708 weixin_39793708 4月前

    I just checked and tested for .deb packages: It is no problem to build regular linux packages, which are then available in the $PATH (e.g. a symlink in /usr/local/bin/webcatalog), I just added

    targets = Platform.LINUX.createTarget(['AppImage', 'deb'], Arch.x64);

    see https://www.electron.build/configuration/linux

    The installation in /opt then looks similar to different chromium-based browsers. It did not generate other debian meta-files like .dsc, which are useful for building a repository which can be added to sources.list, but I guess there are ways to generate them as well.

    点赞 评论 复制链接分享