Fix issue with homebrew-installed nc taking precedence in $PATH

[vangie]

This commit addresses a problem where the nc command installed via homebrew was being used preferentially over the intended version due to its higher precedence in the $PATH environment variable. Adjustments have been made to ensure the script selects the correct nc executable, avoiding conflicts and ensuring consistent behavior across different setups.

$ which nc
/opt/homebrew/bin/nc

Standards checklist:

• The PR title is descriptive.
• The PR doesn't replicate another PR which is already open.
• I have read the contribution guide and followed all the instructions.
• The code follows the code style guide detailed in the wiki.
• The code is mine or it's from somewhere with an MIT-compatible license.
• The code is efficient, to the best of my ability, and does not waste computer resources.
• The code is stable and I have tested it myself, to the best of my abilities.
• If the code introduces new aliases, I provide a valid use case for all plugin users down below.

Changes:

• [...]

Other comments:

...

[ohmyzsh]

Bleep bloop. I determined that these users own the modified files: @septs.

[septs]

hardcoded paths are bad code.

Suggested change

	if sys.platform == 'darwin':
	# 'nc' in $PATH may be installed by homebrew, if without path
	yield "/usr/bin/nc"
	else:
	yield "nc"
	yield os.environ.get("SHELLPROXY_NETCAT_PROGRAM", "nc")

References

• https://docs.python.org/3/library/os.html#os.environ
• https://docs.python.org/3/library/stdtypes.html#dict.get

[vangie]

/usr/bin/nc is the BSD version pre-installed in MacOS，If users need to configure the system using SHELLPROXY_NETCAT_PROGRAM, then it might require debugging to identify the issue.

[septs]

plz split to a new pr, a pull request should only handle one thing.

[vangie]

/usr/bin/nc is the BSD version pre-installed in macos, which need need use the same config as linux and cygwin. Therefore, it's all about addressing the issue of macOS not being ready to use out of the box.

[carlosala]

@septs what do you think about it?

[septs]

@septs what do you think about it?

The author wants to use it out of the box and hard-coded paths for macOS platform

[carlosala]

Wouldn't it be a better solution to properly set $PATH to take the nc you prefer? @vangie
Hardcoding path doesn't seem the way to go.

[vangie]

@carlosala @septs Let me explain, I am a homebrew and oh-my-zsh user. Initially, my machine only had the BSD version of the nc command that comes with the Mac system.

which -a nc
/usr/bin/nc

shell-proxy is one of my favorite plugins, and I use it almost every day. One day, I installed a Homebrew version of nc.Because the Homebrew command in the PATH has a higher priority than the system default path, most of the time, it meets expectations to use the GNU version of commands.

which -a nc
/opt/homebrew/bin/nc
/usr/bin/nc

After some time, I discovered that shell-proxy was no longer working, but I did not realize that it was due to the previous Homebrew installation. with no choice, I became someone who manually exports the HTTP_PROXY setting. Until I could no longer tolerate it, I began to read the source code of shell-proxy, and after painstakingly debugging step by step, I discovered the aforementioned issue.

Setting the environment variable indeed solves my problem, but users similar to me might not infer from the error messages that the issue stems from having two versions of nc , specifically the differences between the BSD and GNU versions, causing the problem.

Of course, if you still believe that setting an environment variable is more appropriate, I can revise this PR (Pull Request) according to the previous suggestions. At the very least, the next time the plugin updates, I won't have to resolve conflicts locally.

[septs]

I still can only accept

yield os.environ.get("SHELLPROXY_NETCAT_PROGRAM", "nc")

[carlosala]

I agree with @septs, we shouldn't pollute with particular OS cases.