When a command containing the {F} control sequence is launched from the MenuPopup it is repeated for each selected file, so instead of launching 'cmd a b c' once, it launches 'cmd a b c && cmd a b c && cmd a b c'.
Boilerplate: I'd like to point out that gentoo development is not stopped; it has lost a lot of momentum due to a hard drive crash that ate the revision control system. I have off-site backups, but need to find the time to retrieve them and attempt a restore.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Even with the unselect character some commands still launch multiple times (e.g. gvim), although it did stop this behaviour in others (e.g. mplayer), but the problem remains in most, also if i didn't uncheck the "require source selection" option, some commands don't launch at all!
I know this is a bug because launching the same user-command from the Run menu doesn't result in this behaviour, only launching it from the MenuPopup (and Buttons) does this. Also, requiring the user to use the {u} control is not really practical, since, in some situations, a user needs a visual indicator of where he stands in a huge file list (especially after launching an external program).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think either the user has to be able to specify whether they want the command to be repeated once for every selected item, or once. Though it might make more sense to do this automatically. Just run the command on all selected files unless 'F' is encountered, at which point the cycle should break.
The reason it "works" with mplayer is that after unselecting the files, the following mplayer commands do nothing (because they are invoked without any files to play).
The problem is that file_command() (where the command is executed over multiple selected files) doesn't actually has any way of checking past executions or halting its looping.
Looking at the way the code is structured, it seems like the most sensible way to "solve" this is to use an attribute flag for the command sequence, then check for this flag in csq_execute after the call to cmdseq_execute(), and return some error value that signals file_command to stop. I'll add a patch in a sec.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This patch shows how you could fix the behaviour by using a "execute once" flag attached to the command definition. For testing purposes I just stole the "Repeat until no selection is left" option and made it toggle this new flag instead.
I am uncertain if cfs_execute returning -1 rather than 1 cause any problems anywhere else (probably not since it is boolean logic).
The only thing that needs really be done is: how should this flag be turned on? Should the user have the option (as they have for the "repeat until no selection is left" option)? Or should it be automatically done when the {F} sequence is detected in any of the rows for an external command?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think the "proper" fix for this is to correct the "require source selection" behavior, as pointed out by Skotlex in another bug.
With such a fix in place, any command that uses both an 'u' to unselect files in any {f} or {F} codes *and* the require source selection-flag will only run once, even if run from the pop-up menu. At least if "MenuPopup" here is a reference to the Action-menu you get when right-clicking the selected files in a pane.
If that's not it, what do you mean by MenuPopup in this context?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A related artifact I filed earlier thinking this was the intended behaviour:
https://sourceforge.net/tracker/index.php?func=detail&aid=3231960&group_id=32880&atid=406766
Thanks for reporting this, it sounds like a bug.
Boilerplate: I'd like to point out that gentoo development is not stopped; it has lost a lot of momentum due to a hard drive crash that ate the revision control system. I have off-site backups, but need to find the time to retrieve them and attempt a restore.
Hi!
Could you please provide some additional detail, like *how* you launch the command?
This is maybe a bit weird, but also pretty much the expected behavior since you don't include the 'u' (unselect) character in the brace code.
Even with the unselect character some commands still launch multiple times (e.g. gvim), although it did stop this behaviour in others (e.g. mplayer), but the problem remains in most, also if i didn't uncheck the "require source selection" option, some commands don't launch at all!
I know this is a bug because launching the same user-command from the Run menu doesn't result in this behaviour, only launching it from the MenuPopup (and Buttons) does this. Also, requiring the user to use the {u} control is not really practical, since, in some situations, a user needs a visual indicator of where he stands in a huge file list (especially after launching an external program).
I think either the user has to be able to specify whether they want the command to be repeated once for every selected item, or once. Though it might make more sense to do this automatically. Just run the command on all selected files unless 'F' is encountered, at which point the cycle should break.
The reason it "works" with mplayer is that after unselecting the files, the following mplayer commands do nothing (because they are invoked without any files to play).
The problem is that file_command() (where the command is executed over multiple selected files) doesn't actually has any way of checking past executions or halting its looping.
Looking at the way the code is structured, it seems like the most sensible way to "solve" this is to use an attribute flag for the command sequence, then check for this flag in csq_execute after the call to cmdseq_execute(), and return some error value that signals file_command to stop. I'll add a patch in a sec.
I can't attach files here ¬¬' Anyway, here it is at pastebin: http://pastebin.com/9q0azmXD
This patch shows how you could fix the behaviour by using a "execute once" flag attached to the command definition. For testing purposes I just stole the "Repeat until no selection is left" option and made it toggle this new flag instead.
I am uncertain if cfs_execute returning -1 rather than 1 cause any problems anywhere else (probably not since it is boolean logic).
The only thing that needs really be done is: how should this flag be turned on? Should the user have the option (as they have for the "repeat until no selection is left" option)? Or should it be automatically done when the {F} sequence is detected in any of the rows for an external command?
I think the "proper" fix for this is to correct the "require source selection" behavior, as pointed out by Skotlex in another bug.
With such a fix in place, any command that uses both an 'u' to unselect files in any {f} or {F} codes *and* the require source selection-flag will only run once, even if run from the pop-up menu. At least if "MenuPopup" here is a reference to the Action-menu you get when right-clicking the selected files in a pane.
If that's not it, what do you mean by MenuPopup in this context?