runOrRaiseNext lost functionality in xmonad 0.9?
I used to have the following line in my xmonad.hs to bind Win+F to either open a new firefox or switch to an existing one in a way that would work across multiple Ubuntu versions: ((modMask, xK_f), runOrRaiseNext "firefox-3.5 || firefox3 || firefox" (className =? "Firefox" <||> className =? "Shiretoko")) The ||'s would be interpreted by the shell, first trying firefox-3.5, then if it didn't work firefox3, etc. This worked great. But upgrading to xmonad 0.9.1-2 (installed Lucid Lynx) this functionality broke. Now nothing happens when I press Win+F, and I receive no errors. If I just put "firefox" then it works, but "firefox || firefox" does not, leading me to believe the command is no longer executed through the shell. Is this intentional? If it is, is there a way that xmonad provides for me to query what's in $PATH so I can bind the right version of firefox?
* On Sunday, July 11 2010, Joseph Garvin wrote:
I used to have the following line in my xmonad.hs to bind Win+F to either open a new firefox or switch to an existing one in a way that would work across multiple Ubuntu versions:
((modMask, xK_f), runOrRaiseNext "firefox-3.5 || firefox3 || firefox" (className =? "Firefox" <||> className =? "Shiretoko"))
The ||'s would be interpreted by the shell, first trying firefox-3.5, then if it didn't work firefox3, etc. This worked great. But upgrading to xmonad 0.9.1-2 (installed Lucid Lynx) this functionality broke. Now nothing happens when I press Win+F, and I receive no errors.
The change is intentional: Mon Jun 22 15:32:55 EDT 2009 gwern0@gmail.com * XMonad.Actions.WindowGo: switch to safeSpawn, since everyone just passes a prog name (no shell scripting)
If I just put "firefox" then it works, but "firefox || firefox" does not, leading me to believe the command is no longer executed through the shell. Is this intentional? If it is, is there a way that xmonad provides for me to query what's in $PATH so I can bind the right version of firefox?
You can call out to the shell to check with 'which' with the following expression you can put where you had runOrRaiseNext: do (_,paths,_) <- io $ readProcessWithExitCode "which" ["firefox-3.5","firefox3","firefox"] "" -- run the first one that exists case lines paths of firefox : _ -> runOrRaiseNext firefox ... _ -> return () -- or something else? -- Adam
On Sun, Jul 11, 2010 at 7:53 PM, Joseph Garvin
If I just put "firefox" then it works, but "firefox || firefox" does not, leading me to believe the command is no longer executed through the shell. Is this intentional?
This is documented in the haddocks:
-- | 'action' is an executable to be run via 'safeSpawnProg' (of
"XMonad.Util.Run") if the Window cannot be found.
-- Presumably this executable is the same one that you were looking for.
On Sun, Jul 11, 2010 at 10:30 PM, Adam Vogt
can call out to the shell to check with 'which' with the following expression you can put where you had runOrRaiseNext:
do (_,paths,_) <- io $ readProcessWithExitCode "which" ["firefox-3.5","firefox3","firefox"] "" -- run the first one that exists case lines paths of firefox : _ -> runOrRaiseNext firefox ... _ -> return () -- or something else?
Another solution is to look at the current code: runOrRaise = raiseMaybe ○ safeSpawnProg XMonad.Util.Run.safeSpawnProg is defined as: safeSpawnProg ∷ MonadIO m ⇒ FilePath → m () safeSpawnProg = flip safeSpawn [] In comparison, XMonad.Util.Run.unsafeSpawn: unsafeSpawn ∷ MonadIO m ⇒ String → m () unsafeSpawn = spawn And String == FilePath, so these type signatures are identical. So to restore the old behavior is as simple as swapping B for A: runOrRaise' = raiseMaybe ○ unsafeSpawn I thought this was all clear in the haddocks, but I guess not. I've expanded the haddock for runOrRaise to point out raiseMaybe's greater generality. -- gwern
* On Monday, July 12 2010, Gwern Branwen wrote:
I thought this was all clear in the haddocks, but I guess not. I've expanded the haddock for runOrRaise to point out raiseMaybe's greater generality.
-- gwern
Hello gwern, I didn't look at the documentation. Perhaps that's more likely to be the problem, rather than how they are written. -- Adam
participants (3)
-
Adam Vogt -
Gwern Branwen -
Joseph Garvin