Command substitution leaks processes if they expect input (command substitutions run in their own process group)

[ghost]

Example: set -l var (cat)

Expected: $var contains value of user input.

Actual: $var contains an empty string, and if you run jobs, a stopped but not reaped cat process lingers unless you run kill -9 on it.

I understand that in this case, I could use read, but this error would still be a thing.

[ridiculousfish]

In bash and zsh, command substitutions run in the process group of the shell. In fish, they run in their own process group. So when they try to read from stdin, they get SIGTTIN or whatever, and stop. Then fish notices they stopped and just continues on, allowing the command substitution to return.

[zanchey]

This has come up on the mailing list regarding fzf.

[dimonomid]

zanchey, thanks for pointing me to this issue.

So yes, as I already stated in the mailing list, I'm unable to use fzf in fish shell, and this makes fish completely out for me (fzf is SO useful)

ridiculousfish, from your message I would assume this behavior can't be changed by definition, like "it's feature, not bug". Am I right? Or, will it be fixed?

[neersighted]

I'd also like to bump this issue. I'm seeing similar problems using the same program (fzf), but this also applies in general to any program that needs to accept input and output to stdout.

/cc @junegunn

[lilyball]

@ridiculousfish What is the reason behind command substitutions running in their own process group?

[ByScripts]

Is there any workaround for this ?

I would like to store the result of a mysql query with set result (mysql -uroot -p -e "...") but since the password is never requested, it does not work.

[zanchey]

fzf recommends a workaround which may be helpful in some instances - see the fzf README for an example.

[paulcarey]

Rather than calling $ vim (git ls-files | peco) which fails for the reason described above, xargs can be used to the same effect.

 $ git ls-files | peco | xargs -I _ fish -c 'vim _ < /dev/tty'

I'd guess that the original issue with set could be worked around with a wrapper function that set a universal variable, but I haven't tried this.

[jcelliott]

Another vote for finding a way to fix this. Is it something that can reasonably be changed?

[ridiculousfish]

Oh sure, we just have to fix it.

[jcelliott]

Any pointers on where to start looking?

[ridiculousfish]

The key change is to run command substitutions in the foreground process group, and to properly handle stopped jobs when doing command substitutions .It would be interesting to investigate how bash handles this - what happens if you stop (e.g. ctrl-Z) a job in a command substitution?

[JoshCheek]

Looks like it just kills it.

[zanchey]

It swallows Ctrl-Z, but running kill -SIGSTOP from another session just queues input until sent SIGCONT.

[tbodt]

@ridiculousfish Any more progress on this since March?

[ridiculousfish]

No, I haven't done any work on this. I guess the first step would be to answer the question of, what should fish do if a command substitution stops instead of exits?

[JoshCheek]

Not 100% sure I understand (and my prev gif seems like its wrong to me right now)

This is what I think you're saying is happening:

• User enters the command $ a (b)
• A process group is created
• B a new process is made to run b
  • Its in the new process group
  • Its standard input is the shell's standard input
  • It runs in the background
• b tries to read from standard input
• b is put to sleep (by the OS) because it's not in the foreground (active?) process group (this is because the process itself is in the background?)
• Fish sees b went to sleep
• Fish continues as if b had exited successfully and printed nothing, invoking a ""
• The world forgets about poor old b... well, except for those of us in this thread

If that's correct, then these are potential solutions? (note that they handle this case, which is probably the common case, but they don't address the general case of a command substitution stopping)

• Give it an empty stream for standard input (looking at fzf, this is probably the wrong answer.)
• Run command substitutions in the foreground (what does that mean, why aren't they run in it currently? I'm guessing separate process groups are used so we can kill it and all its children if we need? If so, do w actually need that? If so, do is there a way to get both? I don't know a lot about process management)
• Somehow ferry stdin to the process? eg if fish's stdin is a tty then run b through a pty, using select to or something similar to detect when its trying to pull from stdin, pulling from the real stdin in fish, and printing it to the b's stdin (seems fragile, but who knows)

[ridiculousfish]

This is really a UI question - what ought fish to do if a command substitution stops without exiting?

Realistically I think we have three options:

1. Wait forever
2. kill the process
3. orphan the process

It looks like bash and zsh use option 1.

[ninjaaron]

seems like a fairly acceptable 90% solution.

[maletor]

+1, wait forever.

Like with this issue.

Just kidding. I love you.

[JoshCheek]

@maletor that probably was intended to be funny, but it comes off as condescending, maybe enjoy the laugh without sharing next time :)

[faho]

This is really a UI question - what ought fish to do if a command substitution stops without exiting?

@ridiculousfish: Honestly, the UI question comes later. The first thing we ought to do is remove the reason these things are stopping in the first place - because they got SIGTTOU, because we don't allow that they use the terminal. That's the most common reason for stopping, so if we remove that, 99% of use for that UI disappears.

Note also that currently echo (cat | string trim) will hang with no obvious way out because we wait on that forever.

I'll PR a possible fix for this now.

[JoshCheek]

I hit this issue again both yesterday and today. I didn't reread the thread, the last comment makes it look like this might be a known deficiency, but I reported it here as it seems like a regression. After some debugging, I was able to identify that the issue occurs when I pipe bash -i into a function. SS included to make it easier to read, source included to make it easier to reproduce.

# ===== Demo the issue =====

# hangs (I'll press C-c)
$ bash -i -c 'echo hello >&2' | grep whatever
Job 3, '$ bash -i -c 'echo hello >&2' |…' has stopped

# works (use the command instead of the function)
$ bash -i -c 'echo hello >&2' | command grep whatever
hello

# works (remove the -i flag)
$ bash -c 'echo hello >&2' | grep whatever
hello


# ===== Other potentially useful info =====

# the grep function
$ type grep
grep is a function with definition
function grep
    command grep --color=auto $argv
end

# the fish version
$ fish --version
fish, version 2.7.1

# this is as up-to-date as is installable
$ brew upgrade fish
Error: fish 2.7.1 already installed

[JoshCheek]

Oh. One other maybe relevant thing: I pressed C-c, but it really stopped the process. ps shows a "T" (I assume this is SIGSTOP) both before and after I press C-c. After I fg, it prints "hello" and exits normally.

This kind of implies to me that it could be a different issue (b/c it resumes when I foreground it, but the the original had to be SIGKILLed, I believe). Let me know if you want me to post this as its own issue.

[faho]

This kind of implies to me that it could be a different issue

Very much a different issue - this one is explicitly about command substitutions - echo (this stuff).

The problem with bash -i seems to be that it grabs the terminal for itself - strace -e ioctl shows it doing one with TIOCSPGRP - which is the underlying syscall for tcsetpgrp on linux.

[JoshCheek]

Very much a different issue - this one is explicitly about command substitutions - echo (this stuff).

Okay, made a new issue for it here