zsh nie może wprowadzać danych do terminala podczas przesyłania strumieniowego stdin i stdout za pomocą zmiennej komendy, która ma wyjście tty

Informacja o systemie:

macOS Sierra 10.12.6
zsh 5.4.2 (x86_64-apple-darwin16.7.0)
GNU bash, version 4.4.12(1)-release (x86_64-apple-darwin16.3.0)

Przewiń do PRZYKŁADÓW u dołu, jeśli chcesz po prostu zagłębić się w uproszczone przykłady, które stworzyłem.

UWAGA: Nie jestem dużym zshużytkownikiem.

Szukałem na fzfskróty klawiszowe dla bashi zsh.

Zwróć uwagę, jak oba uruchamiają zmienne polecenie $(__fzfcmd). __fzfcmddomyślnie wyświetla fzfwyjście na standardowe wyjście, a podstawienie parametru po prostu uruchamia polecenie ( fzf) wynikające z wyjścia.

Jedną różnicą między skryptem bashi zshjest to, że ta bashkolejna potokuje wyjście, $(__fzfcmd)ale zshtylko przechwytuje je w tablicy. Domyślam się, że jest to spowodowane problemem, zshkiedy dalej potokujesz wyjście fzftam, gdzie nie możesz wejść, fzfa proces przekazywany do fzfnie dostaje żadnego standardowego wejścia. Twoim jedynym wyborem jest ^Zlub ^C. ^Cz jakiegoś powodu wydaje się stanowić tło procesu. A może po prostu chcieli go w tablicy, aby mogli na nim biegaćzle vi-fetch-history . bashWersja robi jakaś magia w kluczu wiązania z"\e^": history-expand-line

Teraz fzfnie jest ważne. Wygląda na to, że potrzebujesz tylko programu, który wyświetla polecenie ttywywołania przez podstawienie parametru, aby spowodować ten problem. Pokażę więc kilka prostszych przykładów.

Oto kilka innych poleceń wysyłanych do tych, ttyktóre mogą powodować ten problem zsh:

• vipe (uruchom edytor na środku potoku)
• 'vim -' (spraw, aby vim czytał ze standardowego wejścia. podobny do vipe, ale nie wyświetli na standardowe wyjście)

W poniższych przykładach zastąpić wszystkie wystąpienia vipeze vim -jeśli nie chcesz zrobić oddzielny zainstalować. Pamiętaj tylko, że vim -nie wypisze zawartości edytora na standardowe wyjście, tak jak viperobi.

PRZYKŁADY:

1) echo 1 | vipe | cat            # works in both bash and zsh
2) echo 1 | $(echo vipe) | cat    # works in bash only. zsh problem with no output until I hit `^C`:
   ^C
   zsh: done                    echo 1 | 
   zsh: suspended (tty output)  $(echo vipe) | 
   zsh: interrupt               cat
   # seems like the process is backgrounded. I can still see it in jobs command

3) cat <(echo 1 | $(echo vipe))   # zsh and bash has the problem. I'm guessing because
                                  # the file isn't finished writing and cat is
                                  # blocking vipe's tty output
                                  # both their `^C` output is just:
   ^C # nothing special, as expected

4) cat < <(echo 1 | $(echo vipe)) # works in both bash and zsh
5) echo 1 | $(echo vipe) > >(cat) # works in both bash and zsh

# The following don't have and input pipe to vipe.
# Type something then send EOF with ^D
6) vipe | cat                     # works for both
7) $(echo vipe) | cat             # works for both

Teraz głównie zastanawiam się, dlaczego 2)ma problem z, zshale nie z powodu, bashi dlaczego 4)i 5)rozwiązuje problem zsh.

Wymagania, zshaby ten problem wydawał się być dokładnie tym, co podałem w tytule:

• rura wejściowa
• polecenie uruchamiane przez podstawienie zmiennej / parametru, które ma ttydane wyjściowe
• rura wyjściowa

AKTUALIZACJA

I dodaje inny obejście, które nie powoduje zshmieć tego problemu 5). Jest podobny do, 4)ale zamiast przekierowywać stdoutbezpośrednio do stin, przekierowuję go do pliku, który przekierowuje na stdinstosowanie substytucji procesu.

Uważam, że Twój problem sprowadza się do niewłaściwego cytowania rozszerzeń.

Cytowanie z zsh: 14 Expansion

Polecenie zawarte w nawiasach poprzedzone znakiem dolara $(...), lub cytowane poważnymi akcentami, takimi jak „ ...”, jest zastępowane standardowym wyjściem, a wszelkie końcowe znaki nowej linii są usuwane. Jeśli podstawienie nie jest ujęte w podwójne cudzysłowy, dane wyjściowe są dzielone na słowa przy użyciu parametru IFS. Podstawienie $(cat foo)może zostać zastąpione równoważnym, ale szybszym $(<foo). W obu przypadkach, jeśli ustawiona jest opcja GLOB_SUBST, dane wyjściowe kwalifikują się do wygenerowania nazwy pliku.

Zauważ, że przykład 2 w twoim pytaniu powoduje nieskończone echo wartości NULL z powodu:

Jeśli podstawienie nie jest ujęte w podwójne cudzysłowy, dane wyjściowe są dzielone na słowa przy użyciu parametru IFS.

Innymi słowy, powłoka nieskończenie czeka na echo, ponieważ domyślnym ogranicznikiem jest SPACJA, echo nigdy się nie kończy. Zobacz TLDP: Zmienne wewnętrzne . To pozostawia zawieszoną rurę dla catpolecenia.

Jako przeczucie, uważam, że 4 i 5 działają z powodu przekierowania wyjścia.