Should we deprecate unixCmd and rename it to shellCmd?
In favor: The latter is more accurate by including non-Unix OSes (in fact, we’ve supported ms-dos commands in Windows for years but still routinely get questions on the forum about it).
Against: Unknown but perhaps high impact on legacy code.
hjh
There are other platform specific names, most notably CmdPeriod class, it would be more consistent to change them all at once, but all are big breaking changes.
I’m cautiously in favor of changing the platform-specific classes, but I would keep the old ones as deprecated indefinitely. The impact on old code will be large IMO.
I’m in favor: if we can deprecate something like Pstutter, I think we ought to be able to deprecate unixCmd as well. I may be wrong about it, but I expect that a future removal of Pstutter is much more likely to break legacy code than a somewhat exotic feature like unixCmd.
Somewhat off-topic: when deprecating something, having a clear message is essential.
Revisiting some old code this morning I was met with the following cryptic message:
WARNING: Called from SfzTester:init, method UnitTest:run is deprecated and will be removed. Use UnitTest:run instead.
This quark uses unixCmd: New quark: LinuxUtils @madskjeldgaard
Processes are working quite differently on Windows vs Unix right?
Platform specific classes might have one advantage: they do the right thing on the specific platform. I would really hesitate to remove unixCmd, just advise people to use shellCmd?