";cmd" results in "bash: cannot set terminal group..."

[carlobaldassi]

After 1f3289c this is what I get for every shelled-out command (except cd):

julia> ;cd /tmp
/tmp

julia> ;pwd
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
/tmp

As can be seen, the commands do work, they just keep printing this annoying error at every invocation. From what I understand, this is a consequence of using the -i option (which is not used in cd). A quick googling around didn't help solving the issue (I tried using the +m option, to no effect). The only fix I found is removing the -i option.

[StefanKarpinski]

Ok, @JeffBezanson was seeing this too. For what it's worth, I'm shelling out to bash as well, but don't see this. On a different os, of course (OS X).

[StefanKarpinski]

So this change could work:

diff --git a/base/client.jl b/base/client.jl
index 52874d1..970f62f 100644
--- a/base/client.jl
+++ b/base/client.jl
@@ -45,7 +45,7 @@ function repl_callback(ast::ANY, show_value)
 end

 function repl_cmd(cmd)
-    shell = get(ENV,"SHELL","/bin/sh")
+    shell = shell_split(get(ENV,"JULIA_SHELL",get(ENV,"SHELL","/bin/sh")))
     if isempty(cmd.exec)
         error("no cmd to execute")
     elseif cmd.exec[1] == "cd"
@@ -59,7 +59,7 @@ function repl_cmd(cmd)
         end
         println(pwd())
     else
-        run(@windows? cmd : detach(`$shell -i -c "$(shell_escape(cmd))"`))
+        run(@windows? cmd : detach(`$shell -c "$(shell_escape(cmd))"`))
     end
     nothing
 end

Then I just set JULIA_SHELL to /bin/bash -i somewhere and I'm back where I started and others will not have the -i passed to their shells. However, I'm concerned that not getting an interactive shell with the ;cmd is a far inferior experience and I want everyone to get the good experience by default without having to change things.

[StefanKarpinski]

I wonder if this is a bash bug or we're doing something wrong with the TTY. @loladiro?

[StefanKarpinski]

This might be relevant: moby/moby#18 (the fix: moby/moby@922a864).

[StefanKarpinski]

Also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663200.

[StefanKarpinski]

85d81b3 commits half of the diff above, but not the parts that remove the -i option. Is the shell not getting a TTY for some reason even though we're in a terminal?

[JeffBezanson]

Our detach uses setsid underneath via libuv's detach option. We probably want to use UV_PROCESS_SETGID instead, which only works on unix, but that's ok in this case.

[JeffBezanson]

How about passing -l instead of -i?

[StefanKarpinski]

That doesn't give you all the niceties of an interactive shell.

[staticfloat]

-l could also print out stuff if users have commands in their ~/.bash_profile. In general, I don't think using bash -l in anything automated is a good idea, as the user has complete control over what gets executed in that case.

[StefanKarpinski]

It doesn't load aliases either, so it doesn't really solve anything. The litmus test here is running something that's an alias and has different behavior when run in an interactive shell. For me, ll fits the bill. It is also one of the things I type into the shell most often.

[mlubin]

I also get this on two different linux machines. Should this be marked for 0.2?

[StefanKarpinski]

I think it probably should.

[JeffBezanson]

I was wrong earlier --- I don't think setgid will do it, setpgid is what's needed.

I just tried another possible solution: remove the detach, and instead add && true to the shell command. So far this seems to work fine for me.