# Revision history [back]

Aha! That's the issue. The suggestion (which seems to only have come through email and not through the interface here) to use tshark -G folders to examine the folders gave a clue as to why the binary seemed to be ignored. The Python file is terminated with Windows newlines (\r\n) and it seems that when that's the case, the shebang isn't parsed properly by Wireshark, even though it's parsed properly by my shell. I converted the Python file to Unix newlines and now tshark -G folders no longer shows an error (even though it _still_ doesn't show ~/.config/wireshark/extcap), and Wireshark now displays the Sniffer when present.

I think there may be some defects underlying this trouble I encountered. In particular, I'd recommend:

• Wireshark should provide a debug mode or troubleshooting UI for processing extcap (log each one as its loaded and any errors encountered).
• tshark -G folders should probably present the same values as what's in the UI.

Aha! That's the issue. The suggestion (which seems to only have come through email and not through the interface here) to use tshark -G folders to examine the folders gave a clue as to why the binary seemed to be ignored. The Python file is terminated with Windows newlines (\r\n) and it seems that when that's the case, the shebang isn't parsed properly by Wireshark, even though it's parsed properly by my shell. I converted the Python file to Unix newlines and now tshark -G folders no longer shows an error (even though it _still_ doesn't show ~/.config/wireshark/extcap), and Wireshark now displays the Sniffer when present.

I think there may be some defects underlying this trouble I encountered. In particular, I'd recommend:

• Wireshark should provide a debug mode or troubleshooting UI for processing extcap (log each one as its loaded and any errors encountered).
• tshark -G folders should probably present the same values as what's in the UI.
• Wireshark should honor Windows newlines when parsing a shebang even on Unix.