darcs patch: XMonad.Core: make spawn smarter

gwern0＠gmail.com

21 Sep 2008 21 Sep '08

5:33 a.m.

Sun Sep 21 01:30:17 EDT 2008 gwern0@gmail.com * XMonad.Core: make spawn smarter Have spawn examine $SHELL if it exists. $SHELL is the user's preferred shell, and may do many things the user wants but the default /bin/sh does not.

Attachments:

xmonad_core_-make-spawn-smarter.dpatch (text/x-darcs-patch — 5.7 KB)

Show replies by date

Spencer Janssen

26 Sep 26 Sep

9:56 p.m.

On Sun, Sep 21, 2008 at 01:33:38AM -0400, gwern0@gmail.com wrote:

...

Sun Sep 21 01:30:17 EDT 2008 gwern0@gmail.com * XMonad.Core: make spawn smarter Have spawn examine $SHELL if it exists. $SHELL is the user's preferred shell, and may do many things the user wants but the default /bin/sh does not.

I don't really see the advantage to this patch, convince me.

Gwern Branwen

10:04 p.m.

On 2008.09.26 16:56:08 -0500, Spencer Janssen scribbled 0.4K characters:

...

On Sun, Sep 21, 2008 at 01:33:38AM -0400, gwern0@gmail.com wrote:

...
Sun Sep 21 01:30:17 EDT 2008 gwern0@gmail.com * XMonad.Core: make spawn smarter Have spawn examine $SHELL if it exists. $SHELL is the user's preferred shell, and may do many things the user wants but the default /bin/sh does not.

I don't really see the advantage to this patch, convince me.

A user's shell when invoked as /bin/sh throws away a lot of their customizations and addons; I wrote this patch for a user on #xmonad who was perplexed why some of his scripts and other shell things were simply Not Working. -- gwern acid DSNET1 MP40 Club SAW 3848 SARL ANZUS TDR Internet

Devin Mullins

27 Sep 27 Sep

1:11 a.m.

On Fri, Sep 26, 2008 at 06:04:54PM -0400, Gwern Branwen wrote:

...

A user's shell when invoked as /bin/sh throws away a lot of their customizations and addons; I wrote this patch for a user on #xmonad who was perplexed why some of his scripts and other shell things were simply Not Working.

Hrm, that makes sense. If you're used to some particular bash-only syntax, you might expect it to work inside spawn.

Brandon S. Allbery KF8NH

1:38 a.m.

On 2008 Sep 26, at 21:11, Devin Mullins wrote:

...

On Fri, Sep 26, 2008 at 06:04:54PM -0400, Gwern Branwen wrote:

...
A user's shell when invoked as /bin/sh throws away a lot of their customizations and addons; I wrote this patch for a user on #xmonad who was perplexed why some of his scripts and other shell things were simply Not Working.

Hrm, that makes sense. If you're used to some particular bash-only syntax, you might expect it to work inside spawn.

Traditional Unix behavior is that something spawned programmatically should use /bin/sh to get a consistent environment, while something spawned via user interaction should use the user's $SHELL. Quite possibly the core spawn should stay as is and the prompt one should use a new $SHELL-based spawn (note that this can be done as a wrapper around the existing spawn). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Gwern Branwen

3:15 p.m.

On 2008.09.26 21:38:54 -0400, "Brandon S. Allbery KF8NH" scribbled 0.9K characters:

...

On 2008 Sep 26, at 21:11, Devin Mullins wrote:

...
On Fri, Sep 26, 2008 at 06:04:54PM -0400, Gwern Branwen wrote:

...
A user's shell when invoked as /bin/sh throws away a lot of their customizations and addons; I wrote this patch for a user on #xmonad who was perplexed why some of his scripts and other shell things were simply Not Working.

Hrm, that makes sense. If you're used to some particular bash-only syntax, you might expect it to work inside spawn.

Traditional Unix behavior is that something spawned programmatically should use /bin/sh to get a consistent environment, while something spawned via user interaction should use the user's $SHELL. Quite possibly the core spawn should stay as is and the prompt one should use a new $SHELL-based spawn (note that this can be done as a wrapper around the existing spawn).

-- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com

Sticking to hardcore traditional Unix behavior would be fine if we were unpleasant Dwm developers. We could be all 'ROFL n00b, don't u know if you don't want /bin/sh you should write your own keybinding which uses "spawnObscure"? Why would you think the default spawn would act smart and work with your existing setup?' Or, we could be friendly & helpful & make a simple 1 or 2 line change and never have to discuss it again. I don't see any real upside to the 'consistent environment' of /bin/sh; if anything, going through $SHELL is what would provide a 'consistent environment', since what the user is actually using and running in is $SHELL. -- gwern

Brandon S. Allbery KF8NH

4:54 p.m.

On 2008 Sep 27, at 11:15, Gwern Branwen wrote:

...

On 2008.09.26 21:38:54 -0400, "Brandon S. Allbery KF8NH"
...
scribbled 0.9K characters: On 2008 Sep 26, at 21:11, Devin Mullins wrote:

...
On Fri, Sep 26, 2008 at 06:04:54PM -0400, Gwern Branwen wrote:

...
A user's shell when invoked as /bin/sh throws away a lot of their customizations and addons; I wrote this patch for a user on #xmonad who was perplexed why some of his scripts and other shell things were simply Not Working.

Hrm, that makes sense. If you're used to some particular bash-only syntax, you might expect it to work inside spawn.

Traditional Unix behavior is that something spawned programmatically should use /bin/sh to get a consistent environment, while something spawned via user interaction should use the user's $SHELL. Quite

Or, we could be friendly & helpful & make a simple 1 or 2 line change and never have to discuss it again. I don't see any real upside to the 'consistent environment' of /bin/sh; if anything, going through $SHELL is what would provide a 'consistent environment', since what the user is actually using and running in is $SHELL.

I think you misunderstood what I was getting at: the stuff you're talking about is user interaction-based, so should use $SHELL. The other case is for if you're writing code to launch an xmobar or xset, etc. and don't want to have to worry if the user's shell needs more quoting than /bin/sh does (or possibly isn't compatible with /bin/sh at all; what happens if $SHELL is rc?) --- this is the "consistency" part. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Spencer Janssen

5:50 p.m.

On Sat, Sep 27, 2008 at 11:15:10AM -0400, Gwern Branwen wrote:

...

On 2008.09.26 21:38:54 -0400, "Brandon S. Allbery KF8NH" scribbled 0.9K characters:

...
On 2008 Sep 26, at 21:11, Devin Mullins wrote:

...
On Fri, Sep 26, 2008 at 06:04:54PM -0400, Gwern Branwen wrote:

...
A user's shell when invoked as /bin/sh throws away a lot of their customizations and addons; I wrote this patch for a user on #xmonad who was perplexed why some of his scripts and other shell things were simply Not Working.

Hrm, that makes sense. If you're used to some particular bash-only syntax, you might expect it to work inside spawn.

Traditional Unix behavior is that something spawned programmatically should use /bin/sh to get a consistent environment, while something spawned via user interaction should use the user's $SHELL. Quite possibly the core spawn should stay as is and the prompt one should use a new $SHELL-based spawn (note that this can be done as a wrapper around the existing spawn).

-- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com

Sticking to hardcore traditional Unix behavior would be fine if we were unpleasant Dwm developers.

We could be all 'ROFL n00b, don't u know if you don't want /bin/sh you should write your own keybinding which uses "spawnObscure"? Why would you think the default spawn would act smart and work with your existing setup?'

Or, we could be friendly & helpful & make a simple 1 or 2 line change and never have to discuss it again. I don't see any real upside to the 'consistent environment' of /bin/sh; if anything, going through $SHELL is what would provide a 'consistent environment', since what the user is actually using and running in is $SHELL.

-- gwern

Here is a keybinding in defaultConfig: spawn "exe=`dmenu_path | dmenu` && eval \"exec $exe\"" I'm not an expert, but I believe there are shells where this is incorrect syntax. This is why it is important to have a consistent environment -- we ought to be able to write spawn expressions in the core and contrib and expect them to work everywhere. This is how I propose we move forward: * reject this patch to the core * document the fact that XMonad.spawn uses /bin/sh * add spawnShell (or some better name) to XMonad.Util.Run which executes its argument in $SHELL. Also, this insinuation that we hate our users is not fair, and certainly doesn't further discussion in any meaningful way. Cheers, Spencer Janssen

Gwern Branwen

8 Oct 8 Oct

9:20 p.m.

On 2008.09.27 12:50:24 -0500, Spencer Janssen scribbled 2.5K characters:

...

This is how I propose we move forward: * reject this patch to the core * document the fact that XMonad.spawn uses /bin/sh * add spawnShell (or some better name) to XMonad.Util.Run which executes its argument in $SHELL.

These seem reasonable to me. I believe the spawn doc has been improved, so that's done. How do you suggest spawnShell be written? As essentially the slightly modified spawn my patch suggests? Or would it be something like 'spawnShell a = do sh <- getEnv "SHELL"; spawn (sh ++ " -c" ++ a)' (if you follow me)? -- gwern assasinate SEMTEX CATO AVN morse AC spook Verint PEM Psyops

Devin Mullins

9 Oct 9 Oct

4:28 a.m.

On Wed, Oct 08, 2008 at 05:20:48PM -0400, Gwern Branwen wrote:

...

How do you suggest spawnShell be written? As essentially the slightly modified spawn my patch suggests? Or would it be something like 'spawnShell a = do sh <- getEnv "SHELL"; spawn (sh ++ " -c" ++ a)' (if you follow me)?

Ugh, quoting issues.

6112

Age (days ago)

6130

Last active (days ago)

List overview

Download

9 comments

5 participants

participants (5)

Brandon S. Allbery KF8NH
Devin Mullins
Gwern Branwen
gwern0＠gmail.com
Spencer Janssen