@Brush: "Have you tried running the script from a regular terminal (or even Geany's builtin terminal in the message window)?"
Perhaps I made this overly complicated. My scripts work perfectly. I have fifteen of them for different current working library sets. My scripts are not a problem. Those consoles/terminals work no problem. No blocking. Only when starting a console from geany. ---------------------------------------------- I do not use F5 key.
When starting a new instance of geany, this is the command line:
geany -i --config=/rdkl/.config/geany
I work from multiple systems; this helps keep them all the same. Not perfect, but better.
Version is 1.27 -------------------------------------------
@Trotman(7/26): "Because the output of build commands is parsed and displayed in the compiler output tab only one build command can be running at a time or their output will get mixed up and confused."
per geany instance only, right?
"So the build menu is blocked whilst a command is running. So as I said before, the command needs to start your terminal as a detached process and exit immediately to get the menu back. Did you try using &? On *x commands are run in sh so it should work."
re: & Yes, did that - no defference.
Normally: I have unchecked 'Load virtual terminal support'
I have unchecked 'msgwin_compiler_visible' I have unchecked 'msgwin_scribble_visible'
-------------------- ************ -------------------- Starting fresh this am:
Single instance of geany: I re-enabled 'msgwin_compiler_visible' Dropped geany restarted - verified 'msgwin_compiler_visible' enabled
Looked at the debug messages screen - no sign of a problem.
Project build section looks like:
[build-menu] NF_03_LB=console NF_03_CM=lxterminal --geometry=130x30& --working-directory=%d NF_03_WD=
My geany .config build section looks like:
[build-menu] number_ft_menu_items=0 number_non_ft_menu_items=0 NF_02_LB=file manager NF_02_CM=pcmanfm& NF_02_WD= NF_03_LB=console NF_03_CM=lxterminal --geometry=130x30& --working-directory=%d& NF_03_WD= number_exec_menu_items=0
Loaded one project.
click 'console' button in build drop down
compiler message window:
lxterminal --geometry=130x30& --working-directory=/rdkl/FB_common/defines (in directory: /rdkl/FB_common/defines) /bin/sh: 1: --working-directory=/rdkl/FB_common/defines: not found /usr/share/themes/Lubuntu-dark-panel/gtk-2.0/gtkrc:682: Unable to find include file: "apps/xfce4-notifyd.rc"
However, the terminal did start in the correct directory.
Leave this up, change desktop, open a second geany instance, load a profile, start a console
compiler message window: lxterminal --geometry=130x30& --working-directory=/rdkl/FB_generic/rlib_small& (in directory: /rdkl/FB_generic/rlib_small) /bin/sh: 1: --working-directory=/rdkl/FB_generic/rlib_small: not found Compilation finished successfully.
console opened correctly no status indicator, no build menu block
First instance of geany still up, console running, build menu blocked drop console in that first instance, the status indicator stays, build menu still blocked. Drop geany - reopen. (second geany instance still open) drop console on second geany instance
now: Whichever geany I open a console on, it will block - the other will open correctly I can drop and alternate which geany has the block. Any subsequent geany instance will NOT have the build menu block as long as one is blocked.
David
[...]
compiler message window:
lxterminal --geometry=130x30& --working-directory=/rdkl/FB_common/defines (in directory: /rdkl/FB_common/defines) /bin/sh: 1: --working-directory=/rdkl/FB_common/defines: not found /usr/share/themes/Lubuntu-dark-panel/gtk-2.0/gtkrc:682: Unable to find include file: "apps/xfce4-notifyd.rc"
Looks like the '&' on the geometry option is being interpreted by the shell as a trailing '&' so its running 'lxterminal --geometry=130x30&' as one command and then trying to run ' --working-directory=/rdkl/FB_common/defines' as another command and not surprisingly it isn't found.
Try "" around the geometry argument.
However, the terminal did start in the correct directory.
As the "(in directory: /rdkl/FB_common/defines)" says the command is run in that directory, it must be the directory of the current file. So you didn't need the "--working-directory=/rdkl/FB_common/defines"
Is the build menu blocked now?
Leave this up, change desktop, open a second geany instance, load a profile,
When reporting problems please always provide the commands you used to do something so it is possible to reproduce your actions.
Whats a profile?
start a console
compiler message window: lxterminal --geometry=130x30& --working-directory=/rdkl/FB_generic/rlib_small& (in directory: /rdkl/FB_generic/rlib_small) /bin/sh: 1: --working-directory=/rdkl/FB_generic/rlib_small: not found Compilation finished successfully.
The command successfully completed, so the menu is unblocked, but you will notice that message did not occur in the first instance so the menu remained blocked in that one.
Geany is behaving as expected, the thing you need to look at is why the command behaves differently in the two cases, but since you havn't provided details on how you started Geany in each case its not possible to suggest possible causes.
console opened correctly no status indicator, no build menu block
First instance of geany still up, console running, build menu blocked drop console in that first instance, the status indicator stays, build menu still blocked. Drop geany - reopen. (second geany instance still open)
What do you mean "drop"? Do you mean close the program?
drop console on second geany instance
now: Whichever geany I open a console on, it will block - the other will open correctly I can drop and alternate which geany has the block. Any subsequent geany instance will NOT have the build menu block as long as one is blocked.
You need to provide this as a set of actions that someone can reproduce, but note that I don't think any contributors use lx desktop, so if the problem is specific to that we may not be able to reproduce.
Cheers Lex
David
-- If you don't try - you lose - automatically.
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
same commands - open one instance, then open another
lxterminal --geometry=130x30 & (in directory: /rdkl/FB_common/defines) /usr/share/themes/Lubuntu-dark-panel/gtk-2.0/gtkrc:682: Unable to find include file: "apps/xfce4-notifyd.rc"
lxterminal --geometry=130x30 & (in directory: /rdkl/FB_generic/rlib_small) Compilation finished successfully.
Both find their directory and open a console.
Also, a **PROJECT** is not going to have all their files in one 'working directory' that someone thinks is related to this problem. If your program enforces that, then it is a bit short-sighted.
Your issue.
I have work to do. Until this different behavior with 2 instances of your program is fixed, it isn't worth my chasing this. If it annoys me too much, I will move to another editor.
Thanks
David
On Thu, Jul 27, 2017 at 5:54 PM, Lex Trotman elextr@gmail.com wrote:
[...]
compiler message window:
lxterminal --geometry=130x30& --working-directory=/rdkl/FB_
common/defines
(in directory: /rdkl/FB_common/defines) /bin/sh: 1: --working-directory=/rdkl/FB_common/defines: not found /usr/share/themes/Lubuntu-dark-panel/gtk-2.0/gtkrc:682: Unable to find include file: "apps/xfce4-notifyd.rc"
Looks like the '&' on the geometry option is being interpreted by the shell as a trailing '&' so its running 'lxterminal --geometry=130x30&' as one command and then trying to run ' --working-directory=/rdkl/FB_common/defines' as another command and not surprisingly it isn't found.
Try "" around the geometry argument.
However, the terminal did start in the correct directory.
As the "(in directory: /rdkl/FB_common/defines)" says the command is run in that directory, it must be the directory of the current file. So you didn't need the "--working-directory=/rdkl/FB_common/defines"
Is the build menu blocked now?
Leave this up, change desktop, open a second geany instance, load a
profile,
When reporting problems please always provide the commands you used to do something so it is possible to reproduce your actions.
Whats a profile?
start a console
compiler message window: lxterminal --geometry=130x30& --working-directory=/rdkl/FB_generic/rlib_small& (in directory: /rdkl/FB_generic/rlib_small) /bin/sh: 1: --working-directory=/rdkl/FB_generic/rlib_small: not found Compilation finished successfully.
The command successfully completed, so the menu is unblocked, but you will notice that message did not occur in the first instance so the menu remained blocked in that one.
Geany is behaving as expected, the thing you need to look at is why the command behaves differently in the two cases, but since you havn't provided details on how you started Geany in each case its not possible to suggest possible causes.
console opened correctly no status indicator, no build menu block
First instance of geany still up, console running, build menu blocked drop console in that first instance, the status indicator stays, build
menu
still blocked. Drop geany - reopen. (second geany instance still open)
What do you mean "drop"? Do you mean close the program?
drop console on second geany instance
now: Whichever geany I open a console on, it will block - the other will open correctly I can drop and alternate which geany has the block. Any subsequent geany instance will NOT have the build menu block as long
as
one is blocked.
You need to provide this as a set of actions that someone can reproduce, but note that I don't think any contributors use lx desktop, so if the problem is specific to that we may not be able to reproduce.
Cheers Lex
David
-- If you don't try - you lose - automatically.
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
On 29 July 2017 at 06:43, David Barnes dnsenrab@gmail.com wrote:
same commands - open one instance, then open another
You still have not said what the actual commands you use to start Geany instances are.
lxterminal --geometry=130x30 & (in directory: /rdkl/FB_common/defines) /usr/share/themes/Lubuntu-dark-panel/gtk-2.0/gtkrc:682: Unable to find include file: "apps/xfce4-notifyd.rc"
lxterminal --geometry=130x30 & (in directory: /rdkl/FB_generic/rlib_small) Compilation finished successfully.
Both find their directory and open a console.
But they still do something different, but not knowing what you have different between the two instances, how they were started, what directories they are in, projects and files they have open etc it is not possible to suggest why they are different. At the very least they run in different directories so something is different.
Also, a **PROJECT** is not going to have all their files in one 'working directory' that someone thinks is related to this problem. If your program enforces that, then it is a bit short-sighted.
Geany projects don't enforce anything, I am not sure what this comment is apropos?
Your issue.
What? Please interleave your replies below the items you are commenting about so they can be followed (like I have here). When you click reply, gmail copies the original mail pre-quoted (preceded by
s), but annoyingly hides it behind a little [...] in the bottom left
corner, if you click that you will have the original message to interleave replies into.
I have work to do. Until this different behavior with 2 instances of your program is fixed, it isn't worth my chasing this. If it annoys me too much, I will move to another editor.
Your choice.
Cheers Lex
Thanks
David
Le 28/07/2017 à 13:43, David Barnes a écrit :
Until this different behavior with 2 instances of your program is fixed, it isn't worth my chasing this.
It's highly likely the difference is simply that lxterminal is a single process application and thus that when it is already open calling it simply messages the existing instance to open a new window and returns immediately. Just like Geany, gnome-terminal, GEdit, and countless other applications do in the common case.
And the problem at hand IIUC is that you cannot run a build command that returns immediately yet has some things in background. And indeed, I'm afraid it's not possible in the current situation, because Geany waits on the child (on purpose, as it's supposed to be a build tool and wants to read the output and more or less control the child); and that whatever you do the shell it launches will wait on any child before quitting (yes, even if you use "&", because of job control). Unless I'm missing something somewhere, I see 2 solutions:
- have an option in Geany not to wait on the child, e.g. a general-purpose command launcher (I started a plugin for that kind of things, but never had time to get it to a really usable point yet -- it would be easy to make a dumb one though). - have a command that does return immediately and somehow still starts a new process. To achieve that, you probably need a daemon somewhere, or be able to communicate with your desktop shell if it can do that for you.
Or of course, have the single process application be started initially somewhere outside Geany (e.g. launch a lxterminal window before starting Geany).
Regards, Colomban
[...]
And the problem at hand IIUC is that you cannot run a build command that returns immediately yet has some things in background. And indeed, I'm afraid it's not possible in the current situation, because Geany waits on the child (on purpose, as it's supposed to be a build tool and wants to read the output and more or less control the child); and that whatever you do the shell it launches will wait on any child before quitting (yes, even if you use "&", because of job control). Unless I'm missing something somewhere, I see 2 solutions:
The shell should return immediately when the & is used, thats what its for, but one thing I discovered is that Geany doesn't look for the process to have finished until the pipe is closed, to make sure we read all the output.
So unless the daemon closes its stdout (which is rare) then Geany will still wait for it, since it has inherited the shells stdout which is the pipe to Geany.
Cheers Lex
Le 28/07/2017 à 22:09, Lex Trotman a écrit :
[...]
And the problem at hand IIUC is that you cannot run a build command that returns immediately yet has some things in background. And indeed, I'm afraid it's not possible in the current situation, because Geany waits on the child (on purpose, as it's supposed to be a build tool and wants to read the output and more or less control the child); and that whatever you do the shell it launches will wait on any child before quitting (yes, even if you use "&", because of job control). Unless I'm missing something somewhere, I see 2 solutions:
The shell should return immediately when the & is used, thats what its for, but one thing I discovered is that Geany doesn't look for the process to have finished until the pipe is closed, to make sure we read all the output.
So unless the daemon closes its stdout (which is rare) then Geany will still wait for it, since it has inherited the shells stdout which is the pipe to Geany.
Oooooh damn, you're right. So it's super easy to fix, just redirect somewhere, like /dev/null:
porgram >/dev/null 2>&1 &
and that does work indeed.
I somehow thought that the shell waited for the children because of its job control abilities, but indeed it doesn't and we simply inherit the pipes.
On 30 July 2017 at 09:47, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 28/07/2017 à 22:09, Lex Trotman a écrit :
[...]
And the problem at hand IIUC is that you cannot run a build command that returns immediately yet has some things in background. And indeed, I'm afraid it's not possible in the current situation, because Geany waits on the child (on purpose, as it's supposed to be a build tool and wants to read the output and more or less control the child); and that whatever you do the shell it launches will wait on any child before quitting (yes, even if you use "&", because of job control). Unless I'm missing something somewhere, I see 2 solutions:
The shell should return immediately when the & is used, thats what its for, but one thing I discovered is that Geany doesn't look for the process to have finished until the pipe is closed, to make sure we read all the output.
So unless the daemon closes its stdout (which is rare) then Geany will still wait for it, since it has inherited the shells stdout which is the pipe to Geany.
Oooooh damn, you're right. So it's super easy to fix, just redirect somewhere, like /dev/null:
porgram >/dev/null 2>&1 &
and that does work indeed.
I somehow thought that the shell waited for the children because of its job control abilities, but indeed it doesn't and we simply inherit the pipes.
I think job control is only active in interactive shells, which this isn't.
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users