I would advise finding another name for the tool. 'mac' is an obvious trademark infringement and it's only a matter of time before Apple lawyers come knocking on your door. Honestly I find it uncool to piggyback on someone else's brand in this way. The protagonists are different but it's the same fundamental issue as the "Ubuntu vs OVH" and "Let's Encrypt vs Comodo" stories we've seen recently.
There is other non-Apple software that has been happily using "mac" in its name for a long time, no?
Everybody knows MacPorts, and there's Mactracker and MacCleanse on the App Store itself, and the infamous Mackeeper (which may very well be malware; Apple should go after them first) and companies: MacPhun and MacPaw.
But I guess people may confuse "Mac CLI" as being an official part of macOS.
i think the difference is that this is an open source command line utility for mac, so the naming convention is essentially mac command line utility. I think you are correct that it could cause issues, but nowhere near the same thing as Commodo wherein they intentionally are trying to undermine a competitors offering by intimidation and coercion.
Not sure what a better name would be, but it may need to be changed. I should add though, I had no illusions this wasn't an official apple offering.
I agree the circumstances are very different, and obviously don't think there was any nefarious intentions. But the underlying fundamental issue - brand recognition and the value of having your work recognized under a name you control - is still the same.
In this case, I think the author of this tool has the most to lose, because he is building brand equity for someone else. If next year his tool takes off and he is forced to rename, he has to start over.
But let's assume this tool becomes so successful that he gets away with the "name hack", then it sets the wrong example for other aspiring toolmakers: "don't bother picking your own name, surf on on someone else's and if you succeed fast enough, you might get away with it". That is the same calculation which leads less scrupulous people like Comodo and OVH to "ask for forgiveness rather than permission". I think that is dangerous for innovation because it makes it less rewarding to try something new under your own name. Why bother if someone else will reap the rewards in the end?
I don't have any suggestions, but will be happy to send them if I think of anything.
The sooner you change, the better. Otherwise that is wasted brand equity for you. If you're going to work hard to build a great tool, the recognition for that should flow to a name of your own.
Off the top of my head, I think "MacFoo" and "WinBar" are well-accepted conventions for tools built for the mac and windows respectively. Maybe look for something short and sweet in that vein? Or just something short and easy to memorize.
I'm really terrible at choosing names, so I'm sorry for criticizing more than I'm suggesting.
I wish you lots of success, the world needs more easy to use development tools. Don't let armchair quarterbacks like me demotivate you :)
I do too, but I didn't choose it :) It was an internal codename picked by one of the early engineers on the project. In fact I firmly intended to change the name before launch - but we accidentally launched ahead of schedule and people loved it. The rest is history.
A good example of my ineptitude at identifying good names.
That is why asking is always a good idea. I've met entrepreneurs that have the mindset that everything has to be an idea of themselves. I think that ego is a big player on their mindset.
The great thing about open-source is that everything is created through collaborarion. The best of everyone is contributed to a project in benefit of the entire community.
I think that the name is not a problem but it's great to receive suggestions since a good idea could be suggested by someone from the community. Thanks for your comment!
As a seasoned dev on OS X I'm not sure if I see the benefits here. You get the same set of instructions but lose (or rather, don't gain, as a beginner) the chance to use google-fu.
Not only that, by abstracting cross platform commands for things like git you give up the knowledge which allows you to go to other platforms and work there. Unless this mac thing would be ported to linux, windows, etc.
I'm quite unfond of this command suite pattern that seems to be popular in cli apps lately. It's a very git thing to do. Why not just mac-whatever1 mac-whatever2? It has less coupling, basic autocompletion out of the box, and generic autocompletion very easily generatable in a context-free fashion, but less coupling alone should be enough of a reason.
I appreciate your appreciating my jibe. Good luck with your suite and sorry for the little bit of negativity. Command line apps are my favorite type of apps.
No problem! I am glad that you enjoy command line apps as much as I do. Sometimes negativity brings energy to change what needs to be changed. If you see that you have ideas to contribute to the project, I look forward to your contributions!
So instead of not remembering "tar xfz", you can not remember "mac tar:extract"? Either way, I guess you'll just end up asking google and google will tell you to use tar.
Exactly. In addition to that, this is a chance to collaborate to build more and better commands. It's the first step to what could be a powerful and very useful developer tool.
how in the world does it 'increase cognitive load'? Seems like its just your opinion. I know how to shut down a generic linux box. But mac shutdoown or mac reboot is still easier to type and remember.
FWIW, I was installing Ubuntu and had an issue with Unity, so had to use tty to update and hadn't ever shut down from the command line before. It just took me one try of 'shutdown' and a quick look at the man page to figure out what options were needed.
I see this as either being used frequently enough to be easily memorized, or infrequently enough that a quick check of the man page is fine. The real benefit is that it's a very general solution that works on basically any system, and for a wide variety of commands. As another commentor pointed out, the apropos command makes this strategy even more powerful.
Why not just do `man shutdown` to figure out the option you should use, and then either set it up with an alias or just learn it permanently with repetition?
Exactly, that is the point. Also, some commands require several parameters and it's much better having the script asking for those parameters in an interactive way.
Please, everyone, stop forcing HomeBrew as a dependency.
HomeBrew screws with your systems file permissions and installs directly into the standard system directories.
MacPorts (https://www.macports.org/) is at least a good, and it installs into the /opt tree, staying out of the way of anything Apple or Darwin wants to do when updating or patching your system.
Don't like MacPorts? There's always Fink (http://www.finkproject.org/), which installs into /sw and looks like Debian (i.e. apt-get).
i've been using homebrew since, like, lion and never had major issues. it also always worked across major and minor mac os upgrades. the things it does in /usr/local don't interfere with mac os.
in contrast, i somehow couldn't manage to efficiently use macports and fink.
Looks like a nice collection of tools, but unfortunately the installation process assumes you want to install Homebrew (as if you haven't already), install pip, and install git, pv, and python through Homebrew. I don't want to perform those steps. I already have Homebrew, pip, and git installed, and I have pv and python installed using Nix.
I would suggest another command. Instead of "XXX:extract" I use my little shell script, which runs correct unarchiver basing on the file name (or series of unarchivers for common cases like .tar.gz). So you don't have to memorise every command out there. Another useful functionality is to create a separate directory, if archive contains multiple "root" files, so the current directory won't be polluted by the bad archive.
