Shell under Linux Mint returns non-zero exit code, but works anyway

  1. 3 months ago

    Jerry F

    Jan 22 Pre-Release Testers, Xojo Pro Florissant MO USA

    On Linux, my cross-platform project runs a shell command when the main window opens--specifically, 'cat /etc/*-release' to get the Linux distro on which we're running. Of the several distros on which I've tested, it worked on all but Mint Cinnamon.

    The code following the shell command ran under 'if myShell.ExitCode=0 Then'. I determined that, under Mint, the error being returned was 1, hence the nested code did not run. Eliminating the error checking is my present workaround, and it now works fine.

    This is certainly a curiosity. Why would Mint give me what I want even while throwing an 'error'?

    Thank you, Norman. This is the output I got from the Mint terminal:

    DISTRIB_ID=LinuxMint
    DISTRIB_RELEASE=19.3
    DISTRIB_CODENAME=tricia
    DISTRIB_DESCRIPTION="Linux Mint 19.3 Tricia"
    NAME="Linux Mint"
    VERSION="19.3 (Tricia)"
    ID=linuxmint
    ID_LIKE=ubuntu
    PRETTY_NAME="Linux Mint 19.3"
    VERSION_ID="19.3"
    HOME_URL="https://www.linuxmint.com/"
    SUPPORT_URL="https://forums.ubuntu.com/"
    BUG_REPORT_URL="http://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/"
    PRIVACY_POLICY_URL="https://www.linuxmint.com/"
    VERSION_CODENAME=tricia
    UBUNTU_CODENAME=bionic
    cat: /etc/upstream-release: Is a directory
    1

    This is fixed by doing '/etc/os-release' instead of using the wildcard version that was one of the samples I'd seen. Now I just have to make sure that that doesn't break the other distros :-)

    Incidentally, the prime reason I was doing this was that, on non-Ubuntu releases, it seems I have to widen my window a tad or it truncates my toolbar. While Mint was ignoring the nested code in the error test, since it counts as Ubuntu it didn't have to do anything special anyway. But then I decided to get a string with the distro name, to add to the app's logging feature (which previously only reported "Linux".) That's when I caught this :-)

    Thank you too, Tim. Your reply also came in while I was typing :-)

  2. Norman P

    Jan 22 Pre-Release Testers, Xojo Pro outside enjoying the fresh air
    Edited 3 months ago

    check what the result itself is ?
    there should be some kind of error message or something

    or try it manually in terminal (which should be _close_ but not identical)

    something like

    cat /etc/*-release ; echo $?

    should run the command and print the exit code

  3. Tim J

    Jan 22 Pre-Release Testers, Xojo Pro N. Phoenix, AZ
    Edited 3 months ago

    Your getting the error because Mint has the lsb-release file in the upstream-release folder that is not a file. Thus:

    cat: /etc/upstream-release: Is a directory

    and $? = 1

    You will need to do it in two steps:

    cat /etc/os-release
    // do stuff
    cat /etc/lsb-release
    if [ $? -ne 0 ]
    then
        cat /etc/upstream-release/lsb-release
    fi
    // do stuff

    You will find that the majority of all distros have the /etc/os-release file.

  4. Jerry F

    Jan 22 Pre-Release Testers, Xojo Pro Answer Florissant MO USA
    Edited 3 months ago

    Thank you, Norman. This is the output I got from the Mint terminal:

    DISTRIB_ID=LinuxMint
    DISTRIB_RELEASE=19.3
    DISTRIB_CODENAME=tricia
    DISTRIB_DESCRIPTION="Linux Mint 19.3 Tricia"
    NAME="Linux Mint"
    VERSION="19.3 (Tricia)"
    ID=linuxmint
    ID_LIKE=ubuntu
    PRETTY_NAME="Linux Mint 19.3"
    VERSION_ID="19.3"
    HOME_URL="https://www.linuxmint.com/"
    SUPPORT_URL="https://forums.ubuntu.com/"
    BUG_REPORT_URL="http://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/"
    PRIVACY_POLICY_URL="https://www.linuxmint.com/"
    VERSION_CODENAME=tricia
    UBUNTU_CODENAME=bionic
    cat: /etc/upstream-release: Is a directory
    1

    This is fixed by doing '/etc/os-release' instead of using the wildcard version that was one of the samples I'd seen. Now I just have to make sure that that doesn't break the other distros :-)

    Incidentally, the prime reason I was doing this was that, on non-Ubuntu releases, it seems I have to widen my window a tad or it truncates my toolbar. While Mint was ignoring the nested code in the error test, since it counts as Ubuntu it didn't have to do anything special anyway. But then I decided to get a string with the distro name, to add to the app's logging feature (which previously only reported "Linux".) That's when I caught this :-)

    Thank you too, Tim. Your reply also came in while I was typing :-)

  5. Tim J

    Jan 22 Pre-Release Testers, Xojo Pro N. Phoenix, AZ

    @Jerry F cat: /etc/upstream-release: Is a directory

    That's your culprit.

  6. Norman P

    Jan 22 Pre-Release Testers, Xojo Pro outside enjoying the fresh air
    Edited 3 months ago

    when I wrote similar code for checking vresions etc for the IDE it was a pain in the rear for linux because there was no consistent place to find it (and appears there still may not be)

    Centos desktop had it in one spot
    Mint another
    etc etc

    hey - its linux
    Dont like something fork it and make a new distro :)

  7. Tim J

    Jan 22 Pre-Release Testers, Xojo Pro N. Phoenix, AZ
    Edited 3 months ago

    Actually, the standard is that you should provide an "os-release" file that is pertinent to your distro, and an "lsb-release" to disclose what parts of the "Linux Standard Base" you use or are based upon. Many teams have been misusing the lsb-release file.

    There is also an "lsb_release" command that is supposed to list the LSB-derived modules that you use. I've not seen that implemented on any newer distros. You can cure your insomnia here:
    Linux Standard Base Documents

  8. Jerry F

    Jan 22 Pre-Release Testers, Xojo Pro Florissant MO USA

    Well, /etc/os-release is working on my whole VM farm, which are up to date distros of Ubuntu, Mint, Debian, CentOS and openSUSE. For now, if that's not enough, I can only quote a late friend: "Eff 'em if they can't take a joke." :-)

  9. Norman P

    Jan 22 Pre-Release Testers, Xojo Pro outside enjoying the fresh air

    that is what I love about standards- there are so many to pick from
    with the IDE, when I wrote that, trying to get that info from all the versions that were supported tried the "standard" ways first and often had to resort to fallbacks on several of them

  10. Robert W

    Jan 22 Western Canada
    Edited 3 months ago

    There can be other reasons why a shell command may return a non zero error value, and it has nothing to do with errors in your Xojo application.

    An example that I encountered recently, on MacOS, is the osascript command that is used to run applescripts from the command line. In this case, there was a corrupted scripting additions file that osascript tried to load automatically when it fired up. It issued a warning message about the bad file, and then it successfully executed the applescript that I wanted executed. However, the error code it returned was 1 instead of 0, and the result text that I was looking for was appended to the end of the warning message. My workaround was to ignore the error code, and discard everything except the last line of the script result. As you might imagine, this was a less than satisfactory solution. My workaround works for now, but who knows for how long?

    The point of all this is that you need to be aware of what kind of trouble your shell commands are capable of getting into, and be prepared to deal with it.

or Sign Up to reply!