pdf2txt.py and pdfdump.py should have a shebang

[fabbox]

Both scripts in tools/ doesn't contain python interpreter line (#!/usr/bin/env python) which prevent their correct execution when packaged and installed.

From https://bugs.archlinux.org/task/65939 :

#!/usr/bin/env python was removed from pdf2txt.py by [1] [2] and from duppdf.py by [3] [4].
The commit messages do not explain the removal while commit [5] notes the need for them.

[1] bc034c8
[2] d93a73f
[3] 6cc78ee
[4] 7aa180d
[5] 0fdebc6

[pietermarsman]

I think I removed some in the past because I did not understood what they are for. Adding them adds another way of interacting with pdfminer.six; using $ pdf2txt.py file.pdf (without prefixing it with python).

I think its a good thing if we introduce them again. Are there shebangs that work for all kinds of python environments (e.g. conda, virtualenv, pipenv, system python, etc.)?

Also see #217

[fabbox]

Yes, it should work with most of python environments even if I'm not sure on the compatibility with Windows. Note that additionnaly I didn't get the opportunity to test with conda.

[pietermarsman]

According to the python docs it is also compatible with windows.

[eli-schwartz]

I think I removed some in the past because I did not understood what they are for.

They define how to run a program on Unix. Since they are installed as command-line executables in

pdfminer.six/setup.py

Lines 31 to 34 in d79bcb7

	scripts=[
	'tools/pdf2txt.py',
	'tools/dumppdf.py',
	],

there is no choice: they must have those shebangs, and to do otherwise is utterly broken. For compatibility with ancient Unix systems, there is a fallback to try (and fail) to execute them as shell scripts.

Are there shebangs that work for all kinds of python environments (e.g. conda, virtualenv, pipenv, system python, etc.)?

#!/usr/bin/env python3 will locate the currently active python, whether that is a venv or the system python.