Hi,
in macos catalina the folders Desktop und Documents are normally locked by the operating system. If i add geany to the "Full Disk Access" list, the access to these folders ist still not possible ... Is macos catalina buggy or geany ? ;-)
thx
additional info: If other application try to access these folders the OS recognizes this and the user is asked for an exemption. But geany displays immediately an error dialog ...
But geany displays immediately an error dialog ...
... which says ...
Error msg: Could not read the contents of Desktop Error opening directory '/Users/myusernme/Desktop': Operation not permitted
Looks like a Catalina speific issue. Should be move to geany-osx project. @techee Any opinion about cause?
Can also confirm disk access issues in macOS Catalina. Screenshots attached.
<img width="1233" alt="Screenshot 2019-10-11 at 09 21 24" src="https://user-images.githubusercontent.com/56431586/66636904-f3c2c700-ec09-11e9-9268-bae93b7c6785.png"> <img width="1189" alt="Screenshot 2019-10-11 at 09 21 45" src="https://user-images.githubusercontent.com/56431586/66636907-f45b5d80-ec09-11e9-8145-fce63659b6e6.png"> <img width="780" alt="Screenshot 2019-10-11 at 09 22 13" src="https://user-images.githubusercontent.com/56431586/66636908-f45b5d80-ec09-11e9-9ca0-bcd18b295fa0.png">
IIUC Catalina has a bunch of new security extensions including needing the app to be notarized or something (I'm not a mac developer but it came up somewhere else).
Somebody should examine whats needed.
Yeah, I know what's going on - basically Geany is launched by a bash script which sets the environment variables needed by GTK and Geany. So for macOS, it's /bin/bash which needs to get the full disk access privileges - see e.g. this answer for more details:
https://emacs.stackexchange.com/questions/53026/how-to-restore-file-system-a...
(just use /bin/bash for Geany).
Anyway, this is clumsy and has potential security implications. I've been working on a binary launcher for Geany to workaround this and in addition to use GTK3 instead of GTK2 because I had some rendering problems on Catalina. Here's the result:
https://download.geany.org/snapshots/geany-1.36_osx.dmg
Please give it a try and let me know if you run into any problems. In future Geany releases I'd like to switch to GTK3 and use the binary launcher.
What is this binary launcher, can't this stuff be done in geanys main()?
The original launcher was this bash script
https://github.com/geany/geany-osx/blob/master/launcher-gtk3.sh
which sets various environment variables and command-line parameters of the Geany executable. I've rewritten it in Objective C with some improvements as we now have access to the full OS X API:
https://github.com/geany/geany-osx/blob/master/LauncherGtk3/geany/geany/main...
The result is a compiled binary which is signed by my development certificate like the rest of the binaries so from the point of view of macOS it's one application rather than two (bash and Geany).
We could probably set the environment variables in Geany too but we wouldn't have access to macOS API because we don't link against the Objective C runtime so we would miss some stuff like the locale detection.
Yeah, I know what's going on - basically Geany is launched by a bash script which sets the environment variables needed by GTK and Geany. So for macOS, it's /bin/bash which needs to get the full disk access privileges - see e.g. this answer for more details:
https://emacs.stackexchange.com/questions/53026/how-to-restore-file-system-a...
(just use /bin/bash for Geany).
Anyway, this is clumsy and has potential security implications. I've been working on a binary launcher for Geany to workaround this and in addition to use GTK3 instead of GTK2 because I had some rendering problems on Catalina. Here's the result:
https://download.geany.org/snapshots/geany-1.36_osx.dmg
Please give it a try and let me know if you run into any problems. In future Geany releases I'd like to switch to GTK3 and use the binary launcher.
This build appears to work for me. Many thanks! :)
Dear all, I faced the same problem of "Access to Desktop,Documents" due to Catalina update, which I solved installing the new version of Geany by techee (thank you very much). Now I am able to access "Desktop and Documents", but when I try to compile a fortran program I get the following result: "/bin/sh: gfortran: command not found" even if fortran is installed... could you help me in fixing what's going wrong? I am new to programming: so I would really appreciate if one of you could teach me the steps to fix the problem. Many thanks in advance. Have a nice day.
@ruzgarmax go to the Terminal app and try typing `gfortran --version` to see if it's actually installed somewhere your `$PATH` environment variable refers to.
Hi, first of all thank you for your help. Typing "gfortran --version" in the Terminal I get the following "GNU Fortran (Homebrew GCC 9.2.0_1) 9.2.0 Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE." I suppose this means it is installed, right?
@ruzgarmax OK, I think I know what's going on. Previously Geany was launched using a bash script so it inherited all the environment variables defined in a bash config file. This isn't the case any more. Geany launches all the build commands using /bin/sh which is different than /bin/bash on macOS and it doesn't read the bash config files. Try setting the PATH to fortran inside `~/.profile` (right now it's probably set inside `~/.bashrc` or `~/.bash_profile`).
It's a little stupid Geany uses the hard-coded `/bin/sh` inside build.c. Any objections if I make this configurable inside the Various section and make it default to `/bin/bash` for macOS?
By the way, I have re-uploaded the snapshot binary at
https://download.geany.org/snapshots/geany-1.36_osx.dmg
with various fixes and improvements. It is now possible to use a dark theme for the widgets by creating `.config/gtk-3.0/settings.ini` and adding the following lines to it: ``` [Settings] gtk-application-prefer-dark-theme=1 gtk-icon-theme-name=Papirus-Dark ```
The only issue I'm aware of with this release is that when dragging a file e.g. from Finder to the icon of Geany in the dock, it doesn't open the file. This is some issue specific to Catalina as it works on older releases. Right now I don't know what the problem is, I suspect it's either some security-related thing which isn't configured correctly for Geany or a bug in Catalina.
@techee thank you for the answer. Theoretically speaking, I understood what is happening in terms of shells and paths. In practice, I really don't know where to put my hands to set the path of fortran inside "~/.profile" (honestly, given I am new to this kind programming, I fear a little bit in touching the Terminal). What I can say is that all my university-colleagues who use Mac and Geany are facing my very same issue.
The tilde means home directory so you just have to edit the file called `.profile` in your home directory and enter the PATH definition from either `.bashrc` or `.bash_profile` also in home.
In any case, if you don't wish to edit these files, as a temporary workaround, you can open the terminal app, type ``` bash ``` to be sure you use bash (Catalina switched the default shell to zsh) and then type ``` /Applications/Geany.app/Contents/MacOS/geany ``` The executed Geany should be able to execute the fortran compiler.
Being able to specify which shell to use for executing compilers would be the right solution but it will have to wait until the next Geany release.
@techee I don't know how to edith the PATH but the "temporary workaround" works perfectly. By the way, just to let you know, even if MacOS Catilina suggests to adopt zsh as default, my login shell has never changed: it is still /bin/bash. Thank you very much for your help!
It's a little stupid Geany uses the hard-coded /bin/sh inside build.c.
I dislike hardcoding as well, but on a properly configured system, AFAIK, `/bin/sh` should refer to a POSIX compatible shell (be it bash, dash, etc.), so it's not totally unreasonable for Geany to use it.
Any objections if I make this configurable inside the Various section and make it default to /bin/bash for macOS?
None here.
I didn't look into it much, but I noticed there's already [a hack for same/similar issue](https://github.com/geany/geany/blob/75def8a24eb2dab8d376ae051806128827d34fbe...) in the VTE code that might be worth re-visiting when making the changes, or just copy and paste that code again :smile:
It might be nice in the future to make the Shell configurable in the Tools tab and have it inherited by the arguments used for the "Terminal" command arguments in that tab, the "Shell" command in the VTE preferences, and anywhere else that uses a shell too.
@ruzgarmax a possible more convenient and permanent workaround would be to change the VTE preferences to have "Execute programs in the VTE" ticked as well as "Don't use run script". That will make it use the built-in Terminal tab in the messages window area, and the shell can also be configured there as well. Personally I like this better than an external popup window anyway.
@ruzgarmax a possible more convenient and permanent workaround would be to change the VTE preferences to have "Execute programs in the VTE" ticked as well as "Don't use run script".
I don't think it will work - the problem isn't about running but compiling where we use the hard-coded /bin/sh.
It might be nice in the future to make the Shell configurable in the Tools tab and have it inherited by the arguments used for the "Terminal" command arguments in that tab, the "Shell" command in the VTE preferences, and anywhere else that uses a shell too.
That's even nicer place to put the configuration than the Various tab. I'll do it this way.
If bash is always present on macOS I would rather hardcode it instead of opening the can of worms to allow arbitrary shells on all systems.
After the change to zsh I got the feeling Bash will go away with 10.16+
After the change to zsh I got the feeling Bash will go away with 10.16+
Yes, that's my feeling too (may take a few more releases though). They've already announced that in 10.16 they'll remove python, perl and ruby and those will have to be installed separately. I watched their presentation from this year's WWDC and they basically said "we want macOS to be as secure as iOS by default" and they are removing all ways an unsigned code can be executed. I think they'll keep zsh as the only way to run scripts and add per-application permissions allowing/disallowing to run scripts using it.
If bash is always present on macOS I would rather hardcode it instead of opening the can of worms to allow arbitrary shells on all systems.
The issue isn't if it's present or not - even if they keep it, people will probably move more and more towards zsh and set their environment variables in zsh config files and then when you e.g. run compilation using bash, it won't find your compiler like in the case of @ruzgarmax . If you worry people will mess with the settings too much, I can just add it to Various instead of Tools so it's more hidden.
Okay, then zsh, as long as it's a defined environment. I fear arbitrary the option for shells because each has its own gotchas that we'd need to support.
Making it more hidden doesn't save us from supporting the cases where the user selects an awkward option.
I agree with @kugel- that there are issues changing the shell that Geany generates commands for, unless all Geany does is generate really simple commands. Commands with options and such could be an issue, for eg do all shells support `shell_name -c "command"`?
Okay, then zsh, as long as it's a defined environment. I fear arbitrary the option for shells because each has its own gotchas that we'd need to support.
No, you don't understand - we can't hard-code neither, we just don't know which one the user uses. On older macOS versions it will probably be bash, on newer ones (over time) probably zsh. But at this moment it's configurable.
What exactly do you fear? Right now it runs something like
``` /bin/sh -c fortran ```
what could go wrong if it runs
``` /bin/zsh -c fortran ```
What exactly do we have to support in this case?
Commands with options and such could be an issue, for eg do all shells support shell_name -c "command"?
I checked the major ones and all do.
Right now it runs something like `/bin/sh -c fortran`
Yes, I know Geany generates `-c` thats why I mentioned it, but is that all? I don't have the time to search out what options Geany adds to the shell when it builds commands. If thats the only option Geany uses, then thats likely to be fine, but if it uses something more obscure that only a few shells support then that becomes a trap for users. On the other hand I guess you could only modify those places that are safe to use the new setting.
@techee For the build commands, it's irrelevant which shell the user uses. We need one that behaves as expected and that is installed on the system.
Since the build commands are configurable itself (with all the issues around escaping and such), we must be sure that the shell that we pass the build commands does the right thing.
The shell used in the terminal tab is a different matter.
We can also have a (hardcoded) list of shells that we test for existence, if we know they all work (e.g. "zsh > bash > sh"), but I'm really afraid of letting the user assign arbitrary shell programs.
The user could also configure a shell wrapper that messes things up. While it would be his fault essentially, it will take us time to find that out.
Selecting the shell for build commands is something that we ought to do on behalf of the user and not require him to tune hidden down prefs in case of problems.
Just to let you know (probably you know it already): updating the shell from "bash" to "zsh" does not change the practical result, in that fortran keeps on being "not found" (a colleague of mine tried it today).
By the way, this is the Terminal of a MacBook Air after Catalina.
this is the link suggested by Apple with info concerning the shift from "bash" to "zsh":
https://support.apple.com/en-us/HT208050
Have a nice day
For the build commands, it's irrelevant which shell the user uses.
Good, so one thing is clear now - you haven't understood the problem at all ;-). I'll try to explain again on @ruzgarmax's case:
He installed fortran on his machine and because standard paths like /usr/bin are read-only on macOS, it's probably installed somewhere in his home directory. He uses bash and his `.bash_profile` was updated with something like ``` PATH=$PATH:~/path/to/the/fortran/directory ``` Now when he runs terminal with his default bash shell, he can just type `fortran` and it is found because bash reads `.bash_profile` upon initialization. However, when he runs Geany and Geany is configured to use `/bin/sh` for compile command execution, it runs ``` /bin/sh -c fortran ``` Here, `sh` reads the `.profile` config file only and not the `.bash_profile` config file so PATH isn't updated and fortran isn't found.
Clear? It DOES MATTER which shell is is used for running compile commands. On linux binaries are usually installed in standard paths so you usually won't run into issues like that but it may still matter for some other environment variables.
We can also have a (hardcoded) list of shells that we test for existence, if we know they all work (e.g. "zsh > bash > sh"), but I'm really afraid of letting the user assign arbitrary shell programs.
I'm totally fine with that.
The user could also configure a shell wrapper that messes things up. While it would be his fault essentially, it will take us time to find that out.
Yep, that could happen but it would be just one of the thousands other things he can misconfigure on his system.
@techee and probably it doesn't even read any startup files since it is being invoked as a __non-__ interactive shell without --login.
The shell startup rules are rather messy, each shell reads different files, `sh`, `bash` and `zsh` and then they depend on being interactive and login, sheesh.
Maybe we should standardise on `csh` or `tsh` ... just kidding :)
@techee and probably it doesn't even read any startup files since it is being invoked as a non- interactive shell without --login.
Yeah, right, it reads `.bashrc` in this case which is often sourced by `.bash_profile` so you can define the environment variables just once.
Maybe we should standardise on csh or tsh ... just kidding :)
Yeah, Geany shell, `gsh`. The true and only!
Yeah, right, it reads .bashrc in this case ...
Except Geany invokes it as `sh` so it follows the sh rules.
Note that it isn't just a macos problem, there are many things installed as user on Linux, and Geany on Linux invoked from the desktop menus may not inherit any environment variables or paths, and there have been issues about that in the past IIRC.
I've created #2363 with a simple implementation. Let me know if it looks OK this way.
I've once again reuploaded the snapshot with the contents of https://github.com/geany/geany/pull/2363 which should make the shell configurable, default to /bin/bash on macOS and use login shell for execution. @ruzgarmax Would you give it a try? This should fix your problem.
@techee thank you very much for your effort, I really appreciated it... but, as I stated in my very first message, I am only a beginner in programming (you overestimated my skills ;-)) and, honestly, I do not know how I could give a try to the snapshot you uploaded unless somebody guides me....
Ok sorry for the misunderstanding.... now I understood what you were saying: I re-downloaded the file, and the shell is changed into /bin/bash... however it goes on not working when I do compile a program with fortran: can it be a problem related with "building" the program....? 
OK, yeah, I screwed up. I reuploaded the snapshot once again and this time it should work.
@techee thank you very much for all your effort.... it works perfectly!!!! You are the best!!!
I've reuploaded the snapshot binary once more to fix https://github.com/geany/geany-osx/issues/13. I'm not aware of any major issues with the GTK3 build at this point.
I've uploaded the snapshot one more time with various fixes. I really hope this is the last version - if nobody here experiences any problem with it, I'll post a message to the mailing list to get some more feedback.
I had to reupload the snapshot once again because there was a problem with page up/down keys - for now I had to disable the quartz input method from GTK and this will have to be fixed in GTK itself:
https://gitlab.gnome.org/GNOME/gtk/merge_requests/1148
So once more I created a new snapshot. The main feature of this release is that I made a few things configurable (probably the most interesting one is the dark/light theme) using a config file which is created when you start Geany under `~/.config/geany/geany_mac.conf`. The default value for the theme is to use your macOS settings so if you use the dark theme system-wise, it will be picked automatically for you. Note that if you previously set the theme using the `.config/gtk-3.0/settings.ini` file, you'll have to remove this file first, otherwise it overrides the settings specified in `~/config/geany/geany_mac.conf`.
See https://github.com/geany/geany/issues/2390 for a similar issue on Linux. .bashrc is not the right place to configure things that should be visible in arbitrary GUI apps. Having users configure the shell so we can source the wrong files seems wrong to me.
@kugel- So what do you suggest we should do instead?
Does macOS have an equivalenet of .xprofile, that is understood by whatever runtime environment that starts Geany? Geany starts sill under X on macOS doesn't it?
No, Geany doesn't use X - it uses native quartz backend. There's nothing like .xprofile and even if there was, it isn't really user-friendly for people having to edit some additional config files when all they need is in their shell's config file. (And we can eliminate bug reports like "it works in my terminal but not in Geany")
I still don't get what's wrong with configurable shell in your opinion. You say
.bashrc is not the right place to configure things that should be visible in arbitrary GUI apps.
but according to this logic, Geany should never be started from the command line where it gets all the environment variables from the shell (and people clearly do it and I haven't heard about any problem because of that). And of course, when we have `/bin/sh` hard-coded, its config file like `.profile` still gets loaded which is probably "wrong" based on your logic too.
Well... I guess with Catalina zsh is become the default. Not sure about future, but I think they will drop Bash at some point.
Personally I'm fine when macOS port is not doing exact the same as Linux version is doing. But even on macOS I think such things should go to .profile -- using .bashrc or .zshrc is just not the correct level.
Personally I'm fine when macOS port is not doing exact the same as Linux version is doing. But even on macOS I think such things should go to .profile -- using .bashrc or .zshrc is just not the correct level.
Maybe I miss something but why is .bashrc or .zshrc not the correct level?
Maybe I miss something but why is .bashrc or .zshrc not the correct level?
I think what @frlan is saying is that `.bashrc` and `.zshrc` are shell specific setup files and wherever possible things should be set up in a common file, but I don't know what that would be since [zsh](http://zsh.sourceforge.net/Doc/Release/Files.html#Startup_002fShutdown-Files) files all start with `z` and [bash](https://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html) files don't.
Also of course depends on login vs interactive vs neither.
Yepp. General settings should not go to shell specific config files unless they are needed also on non-interactive sessions. (e.g. scripts called via /bin/sh) -- but might be wrong and too much of a fundamentalist ;)
I'm tempted to close this bug (it's been hijacked since the original "full disk acess" was solved, and have the shell discussion over at #2363
But...I found https://apple.stackexchange.com/questions/106355/setting-the-system-wide-pat... to set system-wide environment.
but according to this logic, Geany should never be started from the command line where it gets all the environment variables from the shell (and people clearly do it and I haven't heard about any problem because of that).
Huh? Where did I say that? If Geany is started on the command line, and it happens to inherit environment from there, that's fine with me. We must not depend on getting the environment as if we were launched on the command line.
We use /bin/sh as a helper to spawn processes, not as a tool to read further configuration. I don't suggest to put anything to ~/.profile to make things work in Geany.
Geany is not a shell application, and consequenetly must not depend on configuring one's shell and then configure Geany to use that shell. Instead, the OS's standard ways of setting system/user session wide environment varriables should be consulted as for any other application as well (e.g. on Windows there is this extra dialog where you can set user and system environment variables).
We have enough trouble supporting different OSes, I do not want to get even more trouble by supporting different shells on each of the OSes.
Closed #2344.
But...I found https://apple.stackexchange.com/questions/106355/setting-the-system-wide-pat... to set system-wide environment.
Yeah, totally user-friendly ;-). I really just want things to work automatically for users and do what other editors on macOS do.
We have enough trouble supporting different OSes, I do not want to get even more trouble by supporting different shells on each of the OSes.
Again, we just launch commands using the shells so when they have the `-c` option, there's nothing we have to worry about.
I'm tempted to close this bug (it's been hijacked since the original "full disk acess" was solved, and have the shell discussion over at #2363
This is a good point and I'm closing this bug report. I'm also closing #2363 as this whole thing changed into the competition in "who is more right" instead of trying to solve the problem for users.
I want this to work for macOS users so I'll apply the patch every time I create the release bundle using the jhbuild patch mechanism. For reference, the patch I'll use is here:
https://github.com/geany/geany-osx/blob/master/patches/01-geany_config_shell...
github-comments@lists.geany.org