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

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’?

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

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 ]
    cat /etc/upstream-release/lsb-release
// do stuff

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

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

DISTRIB_DESCRIPTION=“Linux Mint 19.3 Tricia”
NAME=“Linux Mint”
VERSION=“19.3 (Tricia)”
PRETTY_NAME=“Linux Mint 19.3”
cat: /etc/upstream-release: Is a directory

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 :slight_smile:

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 :slight_smile:

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

[quote=472351:@Jerry Fritschle]cat: /etc/upstream-release: Is a directory
That’s your culprit.

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 :slight_smile:

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

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.” :slight_smile:

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

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.