Mac CLI – OS X command line tools for developers(github.com)
github.com
Mac CLI – OS X command line tools for developers
https://github.com/guarinogabriel/mac-cli/
74 comments
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.
Thanks for your comment. I will be updating the code to add modularity in addition of improvements to make it easier to use and extend.
That would be great! I would love to have some mac specific commands, but I don't care for the lamp/magento/git commands.
Is there a way to install only the dependencies that one cares about?
Is there a way to install only the dependencies that one cares about?
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.
Why?
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.
That's true. One of the pending tasks on the script is modularity in addition of a customizable installation process. Stay tuned!
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 agree 100% with you. I am working on a modular version of the script and I will update the code soon. Thanks for your comment!
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!
[deleted]
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.
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.
Without reading the article I assumed this would be some tutorial on official Mac OS tools. Once I read it, it was obviously not the case.
Just anecdotal evidence.
Just anecdotal evidence.
Apple provides support and funding to Mac ports when I last checked.
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.
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?
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?
If you have any suggestion regarding the name, just let me know! I am open to receive suggestions about that. Thanks!
I think you should name it Mac CLI. If you really think it is an issue just call it MaCLI.
What about "macly"? :)
I was going to suggest the same name.
And that is definetely a good suggestion! Thanks
Thanks for your advice! Do you have any suggestion regarding the name? I'd love to hear some ideas.
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.
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.
Thanks for advice, and if you think of anything about the name just let me know!
I just thought of CLImax. Might be to sexually loaded though :(
Yeah... How about "mcl", "A Mac Command-Line tool"?
Already in use (though, pretty niche): http://micans.org/mcl/
Or mctl?
Funny name, but interesting for sure :D
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'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 :)
If MacFoo and WinBar are OK, then surely "Mac Cli" is OK.
Or shorten it to MacCli if you must.
The actual command doesn't have to change.
Or shorten it to MacCli if you must.
The actual command doesn't have to change.
I agree with you, plus the command name is really easy to remember.
i'd just call it maCLI
I do love 'Docker' though.
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.
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.
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.
Apple_$eed
Mackly -- sounds like "Mac CLI", and has personality. tho have not googled for collisions
As an open source library, don't worry about it. If Apple causes a big stink about it (unlikely), then you can rename it.
What you have is a great, simple, direct name for a utility script. Better to ignore the trademark / brand FUD.
What you have is a great, simple, direct name for a utility script. Better to ignore the trademark / brand FUD.
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!
If in doubt click on this sites generate button a bunch and see if anything manifests that you like.
https://www.dotomator.com/web20.html
https://www.dotomator.com/web20.html
You way want to change all occurrences of "OS X" to "macOS" :)
Call it `morc`.
What's so wrong with the regular command line commands for most of this?
I agree. It did inspire me to write this however, which I desperately needed for a long time:
alias eject="hdiutil info | gawk '/^\/dev\/disk([0-9]*)\>/ { system(\"hdiutil detach \" \$1) }'"
alias eject="hdiutil info | gawk '/^\/dev\/disk([0-9]*)\>/ { system(\"hdiutil detach \" \$1) }'"
Most people don't memorize the commands for all of these, and googling for them everytime gets old.
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.
man <command>.
And if people are in the command line often enough, they do memorize the actual commands. They really, really do.
And if people are in the command line often enough, they do memorize the actual commands. They really, really do.
man pages don't really solve the discoverability problem.
Isn't this just layering the discoverability issue? It's another set of commands to learn, when you should be learning the real commands.
Isn't that what apropos is for?
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.
There's already been collaboration among the various *nix operating systems.
Well, would you rather remember: `sudo shutdown -r now` or `mac shutdown`?
Would you rather remember: `pmset sleepnow` or `mac restart`?
Would you rather remember: `pmset sleepnow` or `mac restart`?
Is there complementary `linux shutdown` and `freebsd shutdown` and `solaris shutdown`? If no, then this utility only increases cognitive load.
then this utility only increases cognitive load.
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.
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.
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.
For example: mac ssh:download-folder
For example: mac ssh:download-folder
sudo shutdown -r now.
1) It's already muscle memory.
2) It's not hard.
3) Other *nix OSs use is too.
1) It's already muscle memory.
2) It's not hard.
3) Other *nix OSs use is too.
This project rather reminds me of Joel Spolsky's Law of Leaky Abstractions:
http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...
http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...
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.
That is great! Could you create a Github Issue to move forward with that?
How about 'climate'?
Ha - I just got it. CLImate, right? I like it. I was gonna suggest something like termtool, or just term.
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).
HomeBrew seems like the worst of the three. :-(
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).
HomeBrew seems like the worst of the three. :-(
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.
in contrast, i somehow couldn't manage to efficiently use macports and fink.
I really don't get this... it seems like simply a way to create an environment where you need to prepend 'mac' to every command.