I haven't documented this yet (depends on the review if it's OK like this) and have tested it only very briefly but it seems to work.

@techee pushed 1 commit.

cf76e8c9d740ab8132d31487f94806e6b5e626d4 Make sure we run a shell as a login shell on macOS

@techee pushed 1 commit.

6f0d0c1b17a8c5499eb38e2effda8fe7d1016532 Make sure we run a shell as a login shell on macOS

See https://github.com/geany/geany/issues/2390 and the solution. We apparently don't need to know/configure the right shell but just have the user to configure their system correctly. Does the solution (set env variables in ~/.xprofile) over there apply on macOS in any way?

I find it inappropriate that Geany depends on the shell that the user likes to use in their terminal emulator. If he likes fish, and incorrectly sets PATH/GOPATH up so that only fish sees it, does that mean we must add (and throughly test) fish to the list of supported shells?

If there is a standard method, like .xprofile, that allow GUI apps to inherit environment independently of the user's preferred shell, then we should adhere (and the user too).

@kugel- has a point that the terminal used in the terminal window should be separate from the shell used to run commands. The shell used to run commands is one of a limited set we know works (and the UI should therefore be a selection) but the shell the user wants should be allowed to be anything.

This pull request apparently got too controversial so I'm closing it.

Re-opening since, only one person has objected, not anyone else, other contributions here and on #2344 have been trying to help sort the issue and solution.

@techee made a good point was made on #2344 that geany should work as well as the maintainer for a specific platform is willing to support, and as I noted above, PATH for spawned commands is not just a mac thing, its a pain in the linux ass too forcing users to set up PATH in several places to make it work (and of course that means that any automatic PATH mods made by software won't work).

And note that solutions like `.xprofile` from #2390 won't work if the user is in wayland.

One is not forced to zsh on macOS right?

If its the default shell then users will want to use it.

What should we do if the user doesn't use zsh but fish and only configures fish?

Well, if they don't configure the same shell as they select in Geany then its their fault, but the point of this PR is to at least make more than one _possible_ in Geany, so at least it can support the default one on the platform without special patches.

Does zsh read ~/.profile?

See my link to zsh docs on #2344, no.

One is not forced to zsh on macOS right? What should we do if the user doesn't use zsh but fish and only configures fish?

This is crazy. You first say you want to have only selected shells configurable

https://github.com/geany/geany/issues/2344#issuecomment-542627093

which I did to make you happy and then start talking about fish. If it were up to me, I'd let users specify whatever shell they want. I just went by the path of the least resistance and in that comment of yours it seemed you'd be fine with having only selected shells. Really, make up your mind what you want.

To all those comments about how dangerous things happen when you use a different shell, I can only say - show me. Here's the challenge for you: use Geany with this patch, select bash as the used shell and create .bashrc such that it satisfies these two conditions:

1. When this .bashrc is used from a terminal, you will be able to perform a build command without any problem. 2. When this .bashrc is used by Geany when running a build command, the build command will fail.

The last thing I want is to do Geany harder to maintain but unless you are able to prove your claims, I'm not convinced and I'm not going to continue this pointless discussion.

Btw, I also find it curious that bash is started as a login shell. bash reads ~/.profile in a non-login shell so PATH/GOPATH should be setup there. I do wild things in my .bashrc that I deliberately do not want in non-interactive shells.

This is a bit screwed up on macOS. The thing is that the default terminal app which is part of the system runs the shell as a login shell and basically everyone else then follows this convention because people (or installers which add some command-line applications) typically update their `.bash_profile` instead of `.bashrc`.

Does zsh read ~/.profile?

I think you are fixated on the "zsh vs bash" problem but the original problem @ruzgarmax was facing was "sh vs bash". Because Geany uses sh, it didn't read his .bash_profile where he (or some fortran installer) put his paths.

Anyway, to your question - this doesn't seem to be the case:

https://superuser.com/questions/187639/zsh-not-hitting-profile

Do you know which solutions are available on wayland?

I don't know. But again, why not do the most obvious thing and let users specify the shell they want to use? Look at @ruzgarmax's reaction here:

https://github.com/geany/geany/issues/2344#issuecomment-542391753

Geany is used and should be easy to use by newbies. We shouldn't require that people reconfigure their system "the right way" and use 10 different config files. It should be easy to get Geany to the state where it behaves the same way as terminal. If problems like #2390 appear, we should just be able to say: "Ah, OK, go to settings and change the shell to /bin/bash and it will work".

So we have to tell users that stuff like PATH should be setup in ~/.profile and that will work without having to introduce this, and it'll work with more than just Geany.

Yeah, arrogantly ignoring all newbies like @ruzgarmax who don't know how to do it and forcing users to reconfigure their system just to make Geany work when all other editors work. Wonderful solution!

I expect that our target audience is perfectly capable of editing these files when we give hints (maybe in the manual). We should not make the configuration matrix that needs to be supported bigger than necessary.

Apparently it isn't as shown in #2344.

I also don't buy that all other editors just work.

I'm not aware of any editor on macOS where you would have to configure something specially outside the editor (not that I used THAT many editors though).

I am also highly worried that we read .bashrc ("by design") which is meant for interactive sessions, when the proper place works already (~/.profile is already consulted as of today).

OK, .bashrc won't be read on linux because calling `/bin/bash -c <some command>` won't make it interactive. I wasn't thinking about the linux case much but there it won't really make much difference which shell is used because no config file is read in that case (unlike macOS where the shell should be login to match the system behavior so e.g. .bash_profile is read). Even .profile won't be read in this case in linux. You'd have to specify e.g. BASH_ENV to read some external config file.

So this patch is actually much more macOS-specific than I originally thought. We shouldn't simulate the broken macOS login shell behavior on linux.

Call me arrogant, but I'm considering the limited man power we have, and I don't want to open a can of worms like this when it's not needed at all.

Sorry if it made the impression I was calling you arrogant, what I meant was the attitude that Geany is doing it right and the rest of the world should modify itself to match its behavior.

Just for reference, I found this

https://what.thedailywtf.com/uploads/files/1462690324423-upload-f8cce917-e33...

because one gets easily confused by what is called when (hopefully the diagram is correct).

Now back to what you suggest - it's not enough I'm afraid. Imagine this situation - you are on macOS and you use zsh as the default shell in your terminal. Now you need to update your PATH. Since you are using zsh in terminal, you have to put it to some file like .zshenv because .profile isn't read in this case (it is only when zsh is used as sh). Now you run Geany but there either zsh is used as sh or there's a regular sh which reads .profile which doesn't contain PATH. So now you would have to duplicate your configuration so it's both in .proile and .zshenv and people shouldn't have to do that and we should have an easy way to switch to the shell they use in their terminal.

(hopefully the diagram is correct)

ummm, in the bash case the non-login/non-interactive case (dark blue) line stops at BASH_ENV and never gets to running :grin:

So now you would have to duplicate your configuration so it's both in .profile and .zshenv

This is what I see as the primary issue, and, despite @kugel-'s protests, even on Linux users (or some install scripts) will set stuff up in .bashrc not in .profile, so again it doesn't work.

And then there are those places where /bin/sh is actually dash not bash or zsh. I do hope it is actually sh compliant?

(Premise: let's assume we want the shells to read their config files for the question below)

Question: Don't we actually want to run the shells as **login** non-interactive shells even on linux? The reason I'm asking is that: 1. For sh, it's impossible to specify any config file to be used when run as non-login non-interactive so we can't read .profile. The ENV variable is used to specify sh equivalent of .bashrc for non-login interactive shells so it cannot be used for this purpose. 2. For bash, we can set BASH_ENV to point to .bash_profile (and possibly fall back to .profile when it doesn't exist), but it won't read for us /etc/profile which might contain something important.

In the plots, login non-interactive shells are represented by yellow arrows and IMO this is exactly what we want to happen.

I've reuploaded the patch where shell is configurable to be arbitrary shell and where the shells are started as login shells. There's much more detailed explanation in the commit message.

As I almost know what I'm doing now compared to the times I made the previous commit, I understand now why macOS terminals run as login shell. The thing is that on linux ~/.profile is loaded on login by display manager, e.g. here for LightDM:

https://wiki.archlinux.org/index.php/LightDM#Environment_variables

There's nothing like that on macOS so nothing from .profile is loaded until we run shell as a login shell.