FastScripts MacOSX app: strange stdin behavior when calling subprocessed Python scripts

Question

Summary. Why does the FastScripts application do the following, is it purposeful, and can I or FastScripts developers somehow fix/change the behavior to not do this? (I otherwise find FastScripts to be a superb application. I'm running MacOS 10.9.5.)

Details.

FastScripts 2.6.8 appears to copy the content of the current script its running to stdin for any subprocess that runs in said script, as demonstrated by the command-line session below. Not only is this just plain weird, it can cause significant confusion when developing software triggered by FastScripts directives.

I've not tested similar behavior with non-Python scripts, but multiple independent Python programs I've written all behave the same way. I'll be emailing a link to this question to the FastScripts developers/technical support.

The following demonstrates the scripts running properly:

$ cat test_subprocess_stdin.py 
#!/usr/bin/env python
import subprocess
cmd1 = '/tmp/reprint_stdin.py            >/tmp/cmd1out.txt'
cmd2 = '/tmp/reprint_stdin.py </dev/null >/tmp/cmd2out.txt'
subprocess.Popen(cmd1, shell=True)
subprocess.Popen(cmd2, shell=True)
$ cat /tmp/reprint_stdin.py 
#!/usr/bin/env python
# -*- coding: utf-8 -*-
import sys
# from http://stackoverflow.com/a/17735803/605356
stdin_content_present = not sys.stdin.isatty()
if stdin_content_present:
    for line in sys.stdin:
        sys.stdout.write('stdin: ' + line)
$ ./test_subprocess_stdin.py 
$ cat /tmp/cmd1out.txt
$ cat /tmp/cmd2out.txt
$

However, strange stuff happens when running the above script(s) from FastScripts:

$ # <now running test_subprocess_stdin.py from FastScripts keyboard shortcut>
$ 
$ cat /tmp/cmd1out.txt 
stdin: #!/usr/bin/env python
stdin: import subprocess
stdin: cmd1 = '/tmp/reprint_stdin.py            >/tmp/cmd1out.txt'
stdin: cmd2 = '/tmp/reprint_stdin.py </dev/null >/tmp/cmd2out.txt'
stdin: subprocess.Popen(cmd1, shell=True)
stdin: subprocess.Popen(cmd2, shell=True)
$ cat /tmp/cmd2out.txt 
$ 
$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.9.5
BuildVersion:   13F1077
$ 

Note that calling os.system() in place of subprocess.Popen() causes same, anomalous behavior.

For some reason, FastScripts and only FastScripts seems to direct the content of the script it's running (in the above case, test_subprocess_stdin.py) to the stdin of any (sub) script that gets called within the toplevel script/program. (The </dev/null directs the called subscript to ignore stdin.) This is strange, and because of this, it took a lot of my development+debugging time to discover why my FastScript-called programs were breaking.

Answer 1

thanks for raising this interesting question. I have downloaded and confirmed the same behavior that you see, and am currently trying to make sense of it.

The way FastScripts runs shell scripts is to interpret from the #! (shebang) line in the script the name of the tool to run, and then simply running that tool, providing the content of the script file as standard input to the tool being run. So for example in your example, it would be running:

/usr/bin/env python

With the contents of the file as the standard input.

As far as I know this is a pretty conventional way to invoke a shell tool for running arbitrary script-based commands. So why does FastScripts behave differently than e.g. running the tool from the command line? I don't know.

It is apparently well-documented that child processes do inherit their parent process's e.g. stdin (https://unix.stackexchange.com/questions/58252/what-sets-a-childs-stderr-stdout-and-stdin), so it's not mysterious that when env runs python and in turn python runs the subprocess call, the standard input should remain active.

The question to my mind is what is happening differently in the case of running the script directly from the command line? I don't know if the standard implementation of shell script execution does something special to prevent propagating stdin to the script itself. I'll have to look into this.